DFNS now supports accepting inbound assets through a single operation, AcceptInboundAsset, across five networks: Stellar, XRPL, Algorand, Hedera, and Canton. On these chains, a wallet cannot receive or hold a given asset until it has explicitly opted in to it at the protocol level. Each chain implements that opt-in differently. DFNS abstracts all of them behind one operation, so an institution holds stablecoins and tokenized assets across these networks through one consistent interface, governed by the same policies and signed through the same key management as any other transaction.
On many chains, a wallet must opt in before it can hold an asset
On a number of networks, holding a non-native asset is not automatic. The account has to declare, on chain, that it is willing to hold a specific asset before any of that asset can land in it. Send the asset to a wallet that has not opted in, and the transfer fails.
This is a deliberate design across these chains. It protects accounts from receiving unwanted assets, it lets issuers control who can hold their token, and it keeps each network clean. But every chain expresses the opt-in differently, with its own transaction type, its own parameters, and its own name:
| Network | Mechanism | What it is |
|---|---|---|
| Stellar | ChangeTrust | A trustline to an asset and its issuer |
| XRPL | TrustSet | A trust line to an issued (IOU) currency |
| Algorand | Asset opt-in | A zero-amount self-transfer of the ASA |
| Hedera | TokenAssociate | Associating an HTS token with the account |
| Canton | Transfer preapproval | A preapproval to receive the asset |
For an institution operating across these chains, that is five different mechanisms to implement and maintain, just to let wallets hold assets. Before this release, each one had to be handled separately.
One operation: “AcceptInboundAsset”
DFNS unifies the opt-in step into a single transaction kind. You submit one operation, AcceptInboundAsset, with the identifier appropriate to the asset, and DFNS constructs the correct underlying transaction for that network, signs it, and broadcasts it.
Under the hood, the operation maps to the right primitive on each chain. You do not have to encode any of that per chain. The differences are handled for you, while the per-chain rules are still validated correctly behind the scenes.
For trustline-based chains, DFNS opts in without a holding cap by default, so the wallet can hold any amount of the asset. On Stellar the trustline is created at the maximum supported limit, and on XRPL the trust line is set to the maximum IOU value.
How DFNS supports it
AcceptInboundAsset is a kind on the existing broadcast transaction endpoint, so it flows through the same construct, sign, and broadcast lifecycle as every other transaction, and through the same Policy Engine and approval controls.
You provide the asset identifier for the target chain:
- Stellar:
issuer(G-address) andassetCode(1 to 12 character code) - XRPL:
issuer(r-address) andcurrency(IOU currency code) - Algorand:
assetId(the ASA id) - Hedera:
tokenId(the token entity id, for example0.0.456858)
For example, to let a Stellar wallet hold USDC:
POST /wallets/{walletId}/transactions
{ "kind": "AcceptInboundAsset", "issuer": "GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN", "assetCode": "USDC"}The same kind, with assetId instead, opts an Algorand wallet in to an ASA:
POST /wallets/{walletId}/transactions
{ "kind": "AcceptInboundAsset", "assetId": "10458941"}Two things matter to institutions here.
Governed like any other transaction. Opting a wallet into an asset is a state change, and DFNS treats it as one. It runs through signing, policy, and approval, so which assets a wallet is allowed to hold becomes a controlled, auditable decision rather than an unmanaged side step. Every request also accepts an externalId as an idempotency key.
One model across chains. The opt-in on each network has a small on-chain cost the wallet must cover: on Stellar, each trustline increases the account’s minimum balance by 0.5 XLM; on Algorand, roughly 0.1 ALGO per opted-in asset; on Hedera, around $0.05 in HBAR per association; and on XRPL, an increase to the account’s owner reserve. DFNS handles the mechanics consistently, so you reason about one operation rather than five.
What this unlocks
- Hold stablecoins across more chains. Let wallets hold and receive USDC and other issued assets on Stellar, XRPL, Algorand, and Hedera, through DFNS-managed wallets.
- Receive payments that would otherwise fail. On opt-in chains, a wallet cannot be paid in an asset it has not accepted. This operation is the prerequisite that makes inbound payments and distributions land.
- Tokenized assets. Opt in to hold any issued token on these networks, from stablecoins to tokenized instruments, within the same governed infrastructure.
- One integration instead of five. Manage asset opt-in across Stellar, XRPL, Algorand, Hedera, and Canton through a single operation rather than a different mechanism per chain.
- Compliance-aware holding. Because opt-in is an explicit, policy-governed transaction, which wallets can hold which assets is controlled and auditable.
Get started
- Learn more about onchain core banking: dfns.co
- Explore the platform and documentation: docs.dfns.co
- Start building today on DFNS: app.dfns.io/get-started
- Talk to our team: sales@dfns.co
Get started on DFNS: app.dfns.io