Transfers
Move tokens, force a transfer as custodian, and manage transfer pre-approvals for a compliance-restricted asset.
Transfers covers three separate controls that all touch token movement, and each one answers a different question. Ordinary transfer moves the active participant's available holdings from its selected executor wallet to any eligible recipient. Forced transfer moves tokens out of a holder's address without that holder's consent, and only a custodian can do it. Transfer approval and revocation do not move tokens at all; they pre-authorise a specific future transfer that a compliance rule would otherwise block, or cancel that authorisation before it is used. All three live in the same "Manage Asset" menu. Check the requirements for the control you need.
Pause and freeze, covered on their own page, hold tokens in place: pause stops ordinary transfers across the asset, and a partial freeze holds back a stated amount at one address while everything else keeps moving. Forced transfer does the opposite. It moves tokens somewhere else, and it is the only control in this family the Console states cannot be undone. Its guard is also narrower than pause and freeze's. Only the custodian role gates it. Pausing the asset does not stop it the way pausing stops an ordinary transfer. The Console's own disabling of the control while the asset shows paused is a safeguard the Console adds, not a limit the token enforces on its own. 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. A partial freeze blocks an ordinary transfer that exceeds the available balance; it does not protect that address from a forced one.
Transfer approval and revocation only appear on an asset that carries a transfer-approval compliance module, and most assets do not. When one is configured, an ordinary transfer between two identities is blocked until a configured approval authority pre-approves it, for whatever amount and expiry the module allows. Approving and revoking that pre-approval are compliance decisions, not movements; they act on the compliance module, not on the token itself. That is also why both controls stay available while the asset is paused, unlike almost everything else on this page. Pausing stops a transfer from executing, but it has no bearing on the approval record that transfer will need once the asset unpauses. A compliance authority can pre-approve or withdraw approval throughout a halt, one of the few interventions this family still allows during one.
Steps
Select the control
Open "All assets", select the asset, and open "Manage Asset". Choose "Transfer tokens" to move the active participant's holdings, "Forced transfer" to move a holder's tokens without their consent, or "Approve Transfer" and "Revoke Transfer Approval" to manage a compliance pre-approval instead of moving anything.
Pick "Transfer tokens" for the routine case: sending the active participant's available balance somewhere it needs to go. Reach for "Forced transfer" only when tokens must move regardless of who holds them or whether they consent, since the Console states the result cannot be undone. Use "Approve Transfer" or "Revoke Transfer Approval" when the asset's compliance configuration requires pre-authorisation for a transfer that has not happened yet; neither one touches a balance.
Screen equivalent: "Manage Asset" lists "Transfer tokens" for accounts with transfer permission. Custodian-enabled assets also list "Forced transfer", disabled without the custodian role. An asset with transfer approval shows "Approve Transfer" and "Revoke Transfer Approval" to its configured approval authority.
Enter and review the instruction
For "Transfer tokens", enter the recipient wallet address and amount, then review sender, recipient, and amount in the summary before confirming.
For "Forced transfer", enter the address to seize from, the recipient address, and the amount. The same recipient-eligibility check that gates an ordinary transfer applies here too, so an ineligible recipient entered by hand is caught before you submit rather than after the transfer reverts on-chain. 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 same label the ordinary control uses, so the review screen's heading and warning styling are what tell the two controls apart, not the button.
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 rather than affecting the nearest approval instead.
Submit the transaction
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". That bypass is real, not a caution about risk: a forced transfer skips the sender-side compliance and registration checks that gate an ordinary transfer, moving tokens even from a sender the token would normally refuse to transfer from. Only the recipient's registration is still checked.
Once the transaction confirms on-chain, the tokens have moved from the source address, and no control anywhere in the Console reverses it. A new, separate transfer or forced transfer back is the only way to restore the position, and it needs its own authorisation like any other movement.
Approving a transfer creates a record the compliance module will honour later; its confirmation note states, "This will approve the transfer of the specified amount from the sender to the recipient. The approval can be revoked before the transfer is executed". Revoking is final for that specific approval: its own confirmation note states, "This will permanently revoke the transfer approval. The transfer will no longer be allowed to proceed unless re-approved". Revoking is not in the same class as forced transfer, though: nothing has moved, so the position is unaffected, and a fresh approval can follow if the transfer is still wanted.
Only one path answers to every guard the token defines. Forced transfer skips transfer-path compliance and the sender's registration check at the contract level, though the Console still refuses to run it while the asset is paused.
Troubleshooting
Transfer tokens is missing
Signal: "Transfer tokens" does not appear in "Manage Asset" at all. Cause: your account lacks transfer permission on this asset, or no executor wallet is available. Fix: ask an administrator to grant transfer permission, or confirm an executor wallet is available for the active participant.
Transfer tokens cannot be selected
Signal: "Transfer tokens" is visible but greyed out. Cause: either the asset is paused, or the executor wallet holds no available balance in this token; the menu's own message names which one applies. Fix: unpause only when the approved intervention permits transfers to resume. If balance is the issue, confirm the selected participant and executor before moving funds.
Forced transfer is missing or cannot be selected
Signal: "Forced transfer" is absent from the menu, or present but disabled. Cause: absent means the asset does not carry the custodian capability at all, the same one freeze and unfreeze need. Present but disabled means either the asset is paused or your account lacks the custodian role on this specific asset, and the menu's message states which. Fix: confirm the asset's configured capabilities if the control is missing outright. Ask an administrator for the custodian role, scoped to this asset, if that is the named reason. If pause is the named reason, keep the halt in place until an unpause is authorized. An approved contract-level custodian operation can proceed through a separate path; the Console control remains disabled.
An address's frozen amount drops after a forced transfer
Signal: after a forced transfer, an address's frozen amount is lower than before, even though nobody ran "Unfreeze partial balance". Cause: when the requested amount exceeds what was free at that address, forced transfer automatically unfreezes exactly enough of the frozen balance to cover the shortfall before moving the tokens. A partial freeze does not protect an address from a forced transfer. Fix: nothing to fix, this is expected. Check "Holders" for the current frozen amount and record the forced transfer as the operation that moved the tokens.
A forced transfer is rejected before confirmation
Signal: forced transfer fails before you reach the confirmation screen, naming the recipient. Cause: the same recipient-eligibility check as an ordinary transfer applies here; a manually entered address that is not registered or not eligible for this token is caught before submission. Fix: confirm the recipient's identity registration and eligibility for this token the same way you would for an ordinary transfer; forced transfer waives the sender's checks, never the recipient's.
Approve Transfer or Revoke Transfer Approval do not appear
Signal: neither control shows in "Manage Asset", even though the asset moves tokens under compliance rules. Cause: both need the asset to carry a transfer-approval compliance module, which most assets do not, and your account's identity to be one of that module's configured approval authorities specifically. Lacking either keeps both controls out of the menu entirely, with no disabled state to explain why. Fix: confirm the asset's compliance module configuration, then confirm your identity is listed as an approval authority on that specific module; authority is granted per module, not by an account-wide role.
A pre-approved transfer still reverts
Signal: a transfer between two identities fails compliance even though someone approved it earlier. Cause: three separate things end an approval early. An approval can expire, since every module configuration sets an expiry capped at 365 days. An approval can already be consumed, since some of the module's modes release a single transfer and mark the approval used. Or the identity that granted it can have since been removed from the authority list, which invalidates the approval even though it was valid when created. Fix: open the "Compliance" tab's "Transfer Approvals" table and check the row's status and expiry before assuming the transfer itself is wrong; a pending status does not by itself prove that an approval is usable. Also inspect other compliance checks, which a transfer approval does not waive.
Revoke Transfer Approval fails
Signal: revocation fails immediately, before wallet confirmation. Cause: no active, unconsumed approval exists for the exact sender, recipient, and, depending on the module's configured mode, amount you entered; a mistake in any one of the three matches nothing rather than the nearest approval. Fix: open the "Compliance" tab's "Transfer Approvals" table, copy the sender, recipient, and amount directly from the "Pending" row you intend to cancel, or use that row's own inline "Revoke" control instead of re-entering the values by hand.
Frequently asked questions
Do I need to be a configured approval authority to see the Transfer Approvals table?
No. The table lives on the asset's "Compliance" tab and lists every pending, consumed, and revoked approval to anyone who can view that tab. Only the inline "Revoke" control on a "Pending" row is gated to a configured approval authority; a viewer without that standing sees the same rows but has no way to act on them from there.
Why doesn't a new approval or revocation show up right away?
The table reads from indexed compliance events rather than a live contract call, so a submitted approval or revocation needs a moment to reach the indexer before its row appears or its status changes. A successful wallet confirmation means the change is on its way, not that it has landed on the table yet. Refresh the "Compliance" tab after a short wait before assuming something went wrong.
Does an expired approval show a different status than a pending one?
No. Status changes only on an on-chain event: creation sets it to "Pending", consumption sets it to "Consumed", and revocation sets it to "Revoked". Passing the expiry date fires no event, so an approval nobody used or revoked keeps showing "Pending" indefinitely. Compare the row's "Expires" column yourself instead of trusting the status badge to reflect expiry.
Does a forced transfer charge the same fee as an ordinary transfer?
No. A transaction fee feature configured on the asset exempts every forced transfer and recovery from the fee split, so the move delivers the exact amount you enter with nothing withheld. The recipient of a forced transfer gets the full amount; the configured fee still applies to an ordinary transfer through "Transfer tokens". A confirmation screen that previews a fee on a forced transfer is showing a preview the transfer itself will not charge.
Where do I configure who can act as an approval authority?
Not here. "Manage Asset" only uses a transfer-approval module that already exists; naming its approval authorities, and setting the expiry window and approval mode the module enforces, happens when the asset's compliance modules are configured, covered on Compliance modules. Arriving on this page looking for that setting means you want the asset's compliance configuration, not "Manage Asset".