Dfns is now a signing provider for Canton Wallet Gateway.
Institutional wallet infrastructure for the Canton Network just got a lot easier to wire up. As of this week, the Dfns signing driver is officially merged into the Canton Wallet Gateway, giving any CIP-103 compliant dApp on Canton a direct, standardized path to Dfns-secured keys.
If you're already running on Dfns, this means your existing wallets (same private keys, same policies, same approval flows), now plug straight into Canton's reference wallet infrastructure with zero custom glue code. If you're a Canton dApp builder, your users can now sign with Dfns the same way they'd sign with any other Gateway-supported provider.
Here's what shipped, what it actually does, and why it matters.
What is the Canton Wallet Gateway?
The Wallet Gateway is the Canton Network's official, vendor-neutral middleware layer for wallets. Its job is to sit between three things that historically didn't have a clean way to talk to each other:
- dApps that want to request transactions from a user
- Validator nodes that submit those transactions to the Canton ledger
- Signing providers that hold the keys and authorize the signatures
Before the Gateway, every wallet provider, every custodian, and every dApp had to negotiate their own bespoke integrations. The Gateway replaces that with a single standardized interface, the CIP-103 dApp API, so a dApp written once works across any conforming wallet, and a signing provider integrated once works across any conforming dApp.
The architecture looks roughly like this:
The key idea: identity, ledger submission, and key custody are deliberately separated. The Gateway handles topology and transaction submission against the validator. The signing provider handles secure key storage and the human-in-the-loop signing flow. Neither one has to know how the other is implemented.
How Dfns supports it
The new Dfns signing driver is a first-class implementation of the Gateway's signing provider interface. When a dApp asks the Gateway to authorize a transaction for a user whose keys live with Dfns, the Gateway routes that request to the Dfns driver, which:
- Resolves the right key. The driver was refactored during review to operate on a key model rather than a wallet model, meaning it speaks the same primitive the Gateway speaks, without forcing Canton-specific abstractions onto Dfns wallets.
- Triggers the Dfns signing flow. That includes any policies you've configured: approval thresholds, amount caps, time locks, KYT checks, passkey or WebAuthn authentication, and whatever other guardrails your organization has set up.
- Returns the signature to the Gateway, which then submits the signed transaction to the validator it's connected to.
Crucially, and this came up explicitly in the PR review, the Dfns driver does not try to take over the validator side of the equation. Topology transactions, validator submission, and party registration stay where they belong: with the Wallet Gateway and the validator.
This is a clean architectural fit, and it complements the work we already shipped earlier this year on Bring Your Own Validator (BYOV) for Canton. If you bring your own validator to Dfns and run it behind your own Wallet Gateway, you now have a fully Dfns-secured Canton stack (keys, policies, approvals, and validator) managed from one place.
What this means for clients
If you're a financial institution, custodian, or fintech building on Canton, the practical changes are:
- For teams already using Dfns on the Canton network. Your existing wallets work. The Gateway becomes another way to use them, particularly useful if you're building or integrating with dApps in the Canton ecosystem that expect to talk to a CIP-103 wallet. No migration, no key rotation, no new operational model.
- For teams building Canton dApps. You can now target Dfns users without writing a Dfns-specific integration. Implementing against the Gateway's dApp SDK and Dfns is one of the signing options on the other side, alongside other supported providers. Your dApp doesn't need to know whether the user's keys are in MPC, in an HSM, or co-controlled across both.
- For teams evaluating Canton. The barrier to onboarding institutional clients just dropped. Instead of asking a prospect to adopt a wallet vendor that may or may not match their existing custody setup, you can point them at the Gateway and let them bring whichever Gateway-supported provider they already trust. Increasingly, that's Dfns.
- For everyone. The separation of concerns matters more than it sounds. When key custody, ledger access, and dApp logic are decoupled, and each speaks a standardized interface, you stop having to rebuild the same plumbing for every new application. That's how ecosystems actually scale.
What's next on the Canton roadmap
The driver is merged and live in the Wallet Gateway main branch. We'll be working with early dApp partners over the coming weeks to validate end-to-end flows in production, and we'll continue contributing to the Gateway as the CIP-103 spec and the broader Splice Wallet Kernel evolve.
If you want to talk through how this fits into your Canton roadmap, reach out at sales@dfns.co.
Authors
Noah Cornwell
As Chief Technology Officer, Noah heads the engineers team at Dfns. Before joining Dfns, Noah spent over 15 years of his life in technical and engineering leadership roles at crypto exchange and bank Gemini as well as trading firms like MIK Funds and Boston Technologies. He holds an MSc in finance from Northeastern and BSc degree in Economics from the University of Oregon.
