Transfer digital assets to one or more recipients

Send tokens you hold to one or more recipients from the DALP console, with per-recipient amounts, a live compliance verdict, and a balance preview before you submit.

Transferring assets in the DALP console moves tokens from your own wallet to one or more recipient wallets in a single submission.

Use this guide when you send tokens you hold from the web interface, whether you are an investor moving your own position or a transfer agent distributing to several holders at once. You build a list of recipients, set an amount for each, and the console checks every recipient and the total against your balance before you confirm. You authorize the transfer with your own wallet, so it is the everyday path for moving a balance you control. To move tokens from another holder without their signature, use forced transfer instead, which is a custodian-only exception workflow. To pre-authorize a counterparty and amount under a TransferApproval rule, see the transfer-approval workflow in the asset detail workspace.

If you automate transfers, use the Platform API for token holders and transfers, which accepts the same one-or-many recipient shape.

Prerequisites

A connected wallet that holds a transferable balance of the asset. The transfer action stays hidden until a wallet is connected, and it is disabled with a no-balance message when that wallet holds nothing transferable.
An eligible recipient for each address you send to. Each recipient must hold an active, registered identity for the asset.
The asset must not be paused. A paused asset disables the transfer action until it is unpaused.
The transfer action permission for the asset. The action appears in Manage Asset only when your role on the asset includes this permission. The permission is separate from the asset management role: a holder who has the transfer action can move their own balance even without supply-management or governance roles.

How a transfer works

A transfer debits your connected wallet and credits each recipient you list. The console validates the whole request before it lets you continue, so most problems surface in the form instead of reverting on-chain after you submit. It also runs a live compliance verdict for each recipient, so you see whether the transfer will clear before you sign.

Step in the form	What the console checks
Recipient address	Each recipient is an eligible, registered holder for the asset.
Distinct recipients	The same address cannot appear on two rows in one transfer.
Amount per recipient	Each row needs a positive amount.
Total against balance	The sum of all rows must stay within your connected wallet's available balance.
Fee readiness	When the asset charges a transfer fee paid by the sender, your wallet must hold enough of the fee token.
Compliance verdict	A live simulation reports whether each recipient will clear or will revert under the asset's rules.

The available balance is the balance of the connected wallet, after frozen amounts. If the same identity holds the asset in more than one wallet, switch to the wallet that holds the balance you want to move.

Steps

Open the transfer action

Go to Asset Management, select the asset, then choose Manage Asset > Transfer tokens.

If the action is missing, connect the wallet that holds the asset. If it is greyed out, the asset is paused, or the connected wallet has no transferable balance of the asset.

Add one or more recipients

Each recipient is one row with an address and an amount. To send to several wallets in one submission, select Add recipient for each extra row, then set that row's amount.

For each row, set the recipient address in one of two ways:

Search suggests eligible holder accounts for the asset. It lists participants and saved contacts whose wallet is registered for the asset.
Enter manually lets you type any address directly. Use it when the recipient is not in the suggestions, or when you need to target a contract identity. Toggle back with the search option.

Then enter the Amount for that recipient. The row footer shows how much you can transfer in total, and the form keeps a running Total against your Current available balance below the list.

Let the eligibility and distinctness checks settle

The console keeps each recipient distinct: once an address is chosen on one row, the search picker hides it on the other rows, and a manually typed duplicate shows an inline error until you change it.

As you set each recipient, the console runs a recipient eligibility pre-check against the asset. If an address is not an eligible recipient, the form keeps you from continuing and marks that recipient as ineligible, so the problem is caught before submission instead of reverting on-chain. The picker already limits suggestions to eligible holders, so this pre-check matters most for an address you enter by hand. The pre-check confirms the recipient is registered and eligible for the asset. It is a fast gate on recipient identity, not a full compliance verdict: the next step runs the transfer against the live compliance engine and tells you whether the whole transfer will clear. For the same eligibility check in an integration, see Recipient eligibility check.

Read the compliance verdict

Once each row has a sender, a recipient, and a positive amount, the console runs a live pre-trade compliance simulation for that recipient and shows a verdict before you submit:

Will clear means the transfer passes every compliance rule on the asset as of right now, so submitting it should go through.
Will revert means at least one rule blocks the transfer. The console lists every blocking rule for that recipient instead of stopping at the first one, so you see the full picture in one pass.

In a transfer to several recipients, the console checks each recipient and labels the result by address. If any recipient would revert, treat the batch as not ready until you resolve that recipient or remove the row.

The verdict reflects the asset's live compliance state, so it never serves a stale result. A freeze, a blocklist change, or a new claim since your last check appears the next time the verdict runs. The verdict is advisory and does not block the submit button. The asset still enforces every rule on-chain when the transaction executes, so a "will revert" verdict marks the same transfer the chain would reject.

If the compliance engine cannot be reached, the console says the check could not run rather than showing a false "will clear". When that happens, you can still submit, but you lose the pre-flight signal, so the on-chain result is the first confirmation you get.

Why a transfer would revert

When the verdict is "will revert", each blocking rule is sorted by who can resolve it, so you know your next move at a glance:

Who resolves it	What it means	What to do
The holder	A party is missing a required claim, such as a verification or accreditation claim. The console names the exact claim topics that would unblock the transfer.	Have the party obtain the named claim. When more than one claim path is shown, satisfying any one of them clears that rule.
An operator	A party is frozen, on a blocklist, or has an unregistered identity, which only a compliance operator can change.	Route the transfer to a compliance operator. They can act on it in the compliance pre-check console.
No standard fix	A rule blocks the transfer with no standard self-serve or operator workflow to clear it, such as a structural restriction on the asset.	Review the asset's compliance design with whoever administers it before retrying.

The transfer form presents these as guidance for the holder making the transfer. To work a blocker directly, with operator controls and claim issuance in one place, an operator uses the compliance pre-check console.

Review and confirm

The review screen lists the sending wallet, each recipient with its amount, your current available balance, and the balance remaining after the transfer. When the asset charges a transfer fee, the review shows the net amount each recipient receives after the fee. Confirm with the required wallet verification, then submit.

After you submit

A transfer is a queued write operation. After you submit, the asset activity and the recipient balances update once the transaction settles. If the console loses the response, treat the transfer as pending until the asset activity or the recipient's balance proves it landed, rather than resubmitting blind.

For an integration that retries a submission, reuse the same idempotency context for a network retry so a repeat call reattaches to the accepted operation instead of sending the tokens twice. For the wider retry model, see Replay, idempotency, and mint controls.

Troubleshooting

Issue	What to check
Transfer action missing	Connect the wallet that holds the asset. The action appears once a connected wallet can transfer.
Transfer action disabled	The asset is paused, or the connected wallet has no transferable balance of the asset. Unpause the asset, or switch to the wallet that holds the balance.
Balance is held by a different wallet	The asset is held under the same identity but in another wallet. Switch wallets to the one holding the balance you want to move.
Recipient marked ineligible	The address is not an eligible recipient for the asset. The form blocks Continue until every recipient passes the eligibility pre-check. Confirm the recipient has a registered, active identity for the asset.
Address already added	Each recipient must be distinct within one transfer. Remove the duplicate row and put that recipient's full amount on its single row.
Recipient not in the search list	The picker suggests eligible holder accounts only. Use Enter manually to type the recipient address directly.
Total exceeds available	The sum of all rows is larger than your connected wallet's available balance, after frozen amounts. Lower an amount or remove a recipient.
Not enough fee token	The asset charges a sender-paid transfer fee and your wallet lacks enough of the fee token or allowance. Top up the fee token before you submit.
Verdict shows will revert	A compliance rule blocks the transfer for that recipient. Open the blocker list to see which rule and who can resolve it: have the holder obtain a named claim, route a freeze or blocklist change to a compliance operator, or review a structural restriction with the asset's administrator.
Verdict could not run	The compliance engine could not be reached for the pre-flight check. You can still submit, but without the pre-flight signal the on-chain result is your first confirmation. Retry to get the verdict before you sign.

Mint assets in the console - Issue new units to one or more eligible recipients
Compliance pre-check console - Simulate a transfer and work each blocker with operator controls and claim issuance
Forced transfer - Move tokens from another holder under a custodian exception
Asset detail workspace - The operating view for an asset, including transfer approvals and recipient eligibility checks
Token holders and transfers - Query holders and execute transfers through the Platform API

Transfer assets in the console