A self-service guide for teams who want to integrate with Loop Wallet, and, where needed, get a DAML archive (DAR) reviewed and deployed on a Five North validator.

Welcome

We built Loop to be the easiest way for a dApp to reach Canton Network wallet users, and we want serious, ambitious builders integrating with it. This guide gets you as far as possible on your own: read the docs, know what your integration actually needs, and know what a DAR review looks like before you ever have to wait on us.

Deploying a third-party DAR on our validator is a hosting decision with real regulatory, reputational, and network-standing exposure, so we review every request with real diligence. Real diligence is what keeps the pipeline healthy for the builders we most want to work with.

Step 1: Read the SDK docs

• Package: @fivenorth/loop-sdk on npm (server variant: @fivenorth/loop-sdk/server)
• Repo: github.com/fivenorth-io/loop-sdk
• API reference: loop-sdk/docs/api-reference.md
• Published docs: Loop SDK overview on docs.fivenorth.io

Any time a Loop Wallet user needs to sign a DAML transaction (create, exercise, or create-and-exercise), your dApp routes that request through the LoopSDK so it can be authorized from inside the wallet. Get comfortable with that signing flow first; it shapes everything else here.

<aside> ⚠️

Does your integration need a custom DAR?

Many don't. If you only read on-ledger state, or only need users to sign against contracts that already exist (the standard Splice and Utility app DARs Loop already runs), you can likely build entirely on the SDK and skip Steps 2 and 3. You only need those if your own DAML templates must be hosted on the validator, typically because a wallet user is a signatory, choice controller, or an actively-notified observer on one of your templates.

</aside>

Not sure which camp you're in? Confirm before investing time in a submission; see Contact below.

Step 2: Design for the smallest footprint that works (optional for DAR review)

• Split by concern. Only ship templates the on-ledger workflow actually needs; keep onboarding, trading, and settlement logic in separate packages.
• Prefer propose-and-accept over full delegation. The Propose-Accept pattern (or an interface-based equivalent) usually avoids deploying your entire application stack.
• Keep the validator off your contracts unless it has to be there. Don't add it as a signatory or observer out of convenience.
• Name your DAR like it's permanent, because it is. Use <your-org>-<product>-<module>. Generic names (app.dar, wallet.dar) and anything resembling network infrastructure (splice-, da-, canton-, cantonloop-, digital-asset-) will block review. Version belongs in daml.yaml, not the filename.
• Know where your dependencies come from. SPLICE and Digital Asset packages are the easy path; third-party packages, forks, or hash-only pins get flagged; unverifiable or deprecated sources block.