Introducing Multichain Wallets

When we first launched the Dfns wallet infrastructure, each wallet was scoped to a specific blockchain. This decision gave us clear account boundaries, simplified indexing, and ensured a consistent developer experience. Developers used the network field to specify the target chain for every wallet they created. It was clean and predictable.

But as the multichain ecosystem matured, and our clients began operating across dozens of networks, this approach started to show its limits. Teams wanted to reduce address sprawl, offer their users a unified identity, and stop juggling logic across fragmented onchain accounts. Essentially, they wanted what MetaMask was offering in the Ethereum world: one key, many chains.

Applications being built today are not just multi-account, they are multichain by default. And the friction introduced by managing dozens (or even hundreds) of wallets per user is no longer tolerable. Developers building on Dfns began to ask: Can I just use one wallet across chains? Today the answer is yes. 

We’re excited to introduce Multichain Wallets, a step up in how developers interact with keys, wallets, and blockchains through Dfns. They introduce a powerful abstraction: one key can now back multiple wallets across multiple blockchains, as long as those blockchains share the same cryptographic curve. This isn't just an EVM convenience; it's a fundamental design shift ranging across non-EVM chains too. Indeed, one key now gives you a unified experience across any ECDSA chain (like Ethereum, Polygon, BNB Chain, Avalanche…) and EdDSA chain (like Solana, Stellar, TON, Sui, Mina…).

This post will walk through what changed, why it matters, and how developers can start using Multichain Wallets today.

From wallets-as-accounts to wallets-as-key-based views

Once again, the original Dfns wallet model was simple: one wallet equals one onchain account, scoped to one chain. The network field in the API defined the chain context for each wallet. If you wanted support for five chains, you created five wallets, each mapped to a separate address. This design gave us strict abstractions, but it came with tradeoffs. Developers had to orchestrate complex logic to correlate wallets across blockchains. Users ended up with multiple addresses that were functionally tied to the same identity, but operationally separate.

We considered modifying the existing wallet object to include a network[] array. But that would have introduced significant ambiguity and complexity. A single walletId would have then referenced multiple accounts across chains. Every API call would have required a network parameter. Indexing and policy enforcement would get murky. And we risked breaking assumptions that developers had already baked into production systems. So, no.

Instead, we opted for a “key-centric model.” Multichain Wallets inverted everything: the wallet is no longer just an account wrapper; it’s actually a cryptographic abstraction over a key (aka a public-private key pair). The key becomes the foundational unit, and wallets become views of that key on different chains. One key can now create multiple wallets, each on a different chain. Each wallet remains a clean, chain-specific account, but all are unified by the same private key. This approach gives us the best of both worlds: (1) backwards compatibility, (2) clear account boundaries, and (3) a powerful abstraction over keys.

For instance, to create a new wallet on Polygon using an existing key that already powers an Ethereum wallet, the API call is now:

POST /wallets
{
  "network": "Polygon",
  "signingKey": {
    "id": "key-001"
  }
}

If key-001 already sits behind a wallet on Ethereum, then the snippet above creates a second wallet on Polygon. Same key, different chain. The benefit: one key, one address scheme, one set of policies, but interoperable across multiple networks. 

Curve-based, not chain-based object models

This is where the Multichain Wallet upgrade goes beyond just EVM compatibility. Multichain Wallets are not just a convenience layer for Ethereum-like chains. They represent a deeper cryptographic unification. If two blockchains share the same signature scheme, such as secp256k1 (ECDSA), then you can derive wallets for both from the same signing key. Same goes for EdDSA chains like Solana or TON. This means that a single ECDSA key can now sit behind wallets on Ethereum, Base, Polygon, BNB Chain, and TRON. A single EdDSA key could back wallets across Solana, Stellar and TON for example.

The implication is profound: developers no longer need to treat blockchain support as a complex backend that’s creating messy, unmanageable build-outs. A single key becomes a universal primitive, spanning any curve-compatible chain. From a developer’s perspective, this means fewer keys to manage, fewer policies and permission sets to configure, and a more coherent identity model across your multichain application.

More granular delegations and policies as a result

Keys are now first-class resources. They can be delegated, permissioned, or delayed in assignment. Wallets created from delegated keys inherit the same ownership, keeping policy enforcement consistent. Access controls are fine-grained: a user can be allowed to use a wallet without having access to the underlying key. New permission scopes are being introduced for key operations. If a key is used to sign on behalf of a wallet, the policy engine still verifies that signature against wallet-specific constraints.

Better developer experience, and user experience too

If you’re already using the Dfns Wallets API, the good news is that nothing breaks. The same endpoints work, and the network field becomes optional unless you’re targeting multiple chains. You don’t need to rewrite your integrations.

• Use existing wallet APIs to create wallets tied to new networks from the same key.
• Get all wallets derived from a given key with GET /keys/{keyId}.
• Use POST /keys/{keyId}/signatures to sign messages for any chain, including ones Dfns does not natively integrate with.

The Dfns Signature APIs have been slightly updated. Policies still apply at the wallet level, but now they’re aware of their originating key. For example, a signing request is made like this:

POST /keys/{keyId}/signatures
{
  "blockchainKind": "Evm",
  "kind": "Message",
  "message": "0xdeadbeef"
}

The same key can now produce valid signatures for multiple chains, each represented by a corresponding wallet derived from that key. Exporting the key will now archive all associated wallets.

And the dashboard experience is evolving too. You’ll soon be able to:

• View all keys in your org.
• Search keys by curve, name, or scheme.
• Create wallets from either a key or wallet context.
• See wallet groups by key for better auditability and resource management.

For end-users, the result is elegant: one address across all EVM chains. Rather than managing one address per chain, users receive a single identity that they can use for holding assets, signing transactions, and interacting with applications across supported blockchains. This unlocks powerful UX improvements, including seamless onboarding across networks, unified history views, and address consistency for identity and recovery purposes. No more multiple seed phrases. Just one identity, fully abstracted. 

This unlocks better onboarding, recovery, support, and personalization. It's a foundational improvement, especially for consumer applications, neobanks, or cross-chain trading for example. As more applications adopt multichain architectures, this consistency becomes critical. Not only for users, but also for security, compliance, and auditability.

The next step is making chain-specific friction disappear

Multichain Wallets are part of a broader effort at Dfns to abstract away the blockchain layer entirely. We’re actively working on:

• Cross-chain protocols: We’re integrating with messaging layers like LayerZero, Wormhole, and Axelar to enable messages, assets, and instructions to move freely across chains. Multichain Wallets make this possible by unifying identity across networks and reducing fragility in these integrations.
• Canonical bridges and smart contracts: We’re collaborating with Aori, Aave, Stargate, and others to enable cross-chain interactions from a single wallet. Whether you’re supplying collateral on Ethereum and borrowing on Arbitrum, or swapping assets via a DEX, the experience should feel seamless.
• Native support for account abstraction: With key-based modeling, we support smart contract wallets as first-class objects. For example, TON uses contract-based accounts backed by signing keys. Our model lets a single key deploy and manage contracts across TON—and soon, ERC-7702 wallets on Ethereum.
• Delegation and permissions: Multichain Wallets prompted a redesign of delegation. Keys are now ownable resources with scoped permissions. When a delegated key creates wallets, they inherit the same ownership, keeping policy enforcement consistent and scalable.
• Fee sponsored transactions: We’ve added fee sponsorship for Solana and are expanding to Ethereum, Tron, and other chains where protocol support exists.

Multichain Wallets aren’t just a product update, they’re a new design primitive for infrastructure. They simplify development, unify logic, and hide blockchain complexity behind the scenes. 

• For developers: faster builds, fewer edge cases, and less fragmentation.
• For users: fewer addresses, less confusion, and a smoother cross-chain experience.

Start with a single key and scale from there. If you're building cross-chain products or supporting assets across Ethereum, Base, Solana, or others, we’d love to connect.

‍