Transfers

Transfer tokens moves the available holdings of the participant you are working as, from that participant's executor wallet, to an eligible recipient. The same “Actions” menu holds these other controls:

• Forced transfer moves tokens out of a holder's address without that holder's consent.
• Approve transfer and “Revoke transfer approval” pre-authorise a transfer that a compliance rule would otherwise block, or cancel that authorisation.
• Two recovery controls move units that their owner cannot move.

The Transfer pre-check tab tests a transfer without submitting it.

Emergency halt and freeze hold tokens in place. Forced transfer moves them, and the Console states that it cannot be undone, as it does for the two recovery controls. Halting the asset does not stop it: the token lets a custodian's forced transfer through while it is halted, and the Console keeps Forced transfer available to a Custodian during a halt. A partial freeze does not stop a forced transfer either. One that needs more than an address's free balance unfreezes exactly enough to cover the shortfall first, then moves the tokens.

ENEnglishARArabic

, opens the full size screenshot

The step shows “Recipient” with the chosen account, then “Amount” with the transferable balance and “Max” under it, then “Add recipient”, then the “Total” against the transferable balance. Review moves to the next step.

Steps#

Open the transfer control#

Open “All assets”, select the asset, and open Actions. Each action opens on its own page under the asset, with a breadcrumb back to the asset, and “Cancel” returns you to where you came from. Choose one of these:

• Transfer tokens moves the active participant's holdings.
• Forced transfer moves a holder's tokens without their consent.
• Approve transfer and “Revoke transfer approval” manage a compliance pre-approval instead of moving anything.

ENEnglishARArabic

, opens the full size screenshot

“Transfer tokens” is unavailable here, because the signed-in wallet holds none of the token. “Approve transfer” and “Revoke transfer approval” appear only on an asset whose compliance requires transfer approval, and only to its configured approval authority.

Enter the recipient, amount or approval values#

For “Transfer tokens”, choose or enter the address under “Recipient” and the number of tokens under Amount. The line under the amount shows how much is transferable, and “Max” fills in all of it. Under that, a line shows its fiat equivalent at the token's price, for example “≈ $2,000.00”. When the token has no price, the line says that no price is set for the token, so there is no fiat equivalent.

Add recipient adds another recipient row, and the total under the rows sums them. Select “Review” and check the recipients and amounts before confirming. The recipient field refuses the zero address and the asset's own contract address, and warns when the recipient is the wallet the tokens come from: an address that can only lose the tokens never reaches the summary.

The review step also runs the Pre-trade compliance check for each recipient with an amount. When every recipient clears, one panel reads “Transfer will clear”. Otherwise a panel shows for each recipient that would not clear, labelled with its address when there are several. It reads “Transfer will revert” in red, or “Waiting for approval” in amber when the only thing holding the transfer is the transfer-approval rule: the transfer is valid and waits for an approval authority. A wallet with the System manager, Identity manager, Verification issuer or Compliance manager role on the organisation's system, or the Custodian role on the asset, sees each blocker the check can establish under “Resolvable by you”, “Requires operator action”, “Held for approval” or “Cannot be resolved”. “Resolvable by you” lists only what the wallet you act as can fix itself: a blocker on the other side of the transfer reads “Resolvable by the sender” or “Resolvable by the recipient”, and carries no button to issue a claim for it. Other wallets see a frozen address, a short balance or a halted asset by name, and anything else as one “Cannot be resolved” entry.

“Confirm transfer” stays disabled while the check runs and when any recipient would revert. A transfer that is only “Waiting for approval” can still be confirmed. Beside the button the review names the failed checks, for example “The pre-trade compliance check says this transfer will fail. Failed checks: Block addresses. Change the recipient or the amount.” When the check cannot run, the review says “Compliance could not be verified right now. The transfer will still be checked on-chain.”, and you can still confirm, because the chain refuses an ordinary transfer that breaks a rule.

For “Forced transfer”, enter the address to seize from, the recipient address, and the amount. A Pre-check panel checks the three inputs as you type:

• Sender balance reads “Holds only” with the balance when the sender holds less than the amount. When the sender's balance drops while the form is open, the platform refuses the amount above the buttons, and the panel reads the sender's balance again, so this line and the amount's available figure show the balance the platform checked.
• Recipient reads “Passes the identity checks” or “Fails the identity checks”. For a recipient address frozen on the token as a whole, it reads “The address is blocked. Unblock it first.” and the forced transfer cannot be submitted on any asset. The DALP 3.2 token contract refuses it too. A token on an older implementation does not check it, so a forced transfer sent straight to such a contract can still deliver units into a frozen address. The Console requires the recipient to be registered and verified for the token, and the chain applies the same identity check to a forced transfer.
• Compliance rules names the rules that would block a normal transfer and says “The forced transfer overrides this.”

When the address to seize from is a DALP escrow, the platform refuses the transfer above the buttons and names the escrow, because a token forced transfer would leave the escrow's balances and locks wrong. Move an escrow's units from Escrows instead.

A failing recipient, an amount greater than the sender's balance, or the same address on both sides keeps “Continue” from going ahead. The confirmation screen is styled as a warning and names the same three fields. Read it before you continue. The button that submits it reads Transfer tokens, the name of the ordinary transfer's menu item, so check the review screen's heading and warning styling before you select it.

For Approve transfer or “Revoke transfer approval”, enter the sender wallet, the recipient wallet, and the exact token amount. Revoking needs the same three values as the approval you are cancelling. The module keys each approval on that identity pair and, in one of its configured modes, the exact amount, so entering the wrong amount for the right pair matches nothing and fails. It never touches the nearest approval.

Confirm with wallet verification#

Confirm with wallet verification, the same as any other Console admin change.

An ordinary transfer that fails a check reverts. Nothing moves and nothing needs undoing. Forced transfer is different. Its confirmation screen states plainly, “This will forcibly transfer tokens from the source address to the recipient”, then adds, “This action bypasses standard transfer restrictions and cannot be undone”. The bypass is real. A forced transfer skips the compliance rules, the sender's address freeze, the halt and the units another feature holds for a pending move, so it moves tokens even from a sender the token would refuse. The chain still checks the recipient's identity and refuses a recipient whose address is frozen on the token. A token feature that refuses forced moves, such as Booked movements, still refuses it.