A custody gateway swaps coins for custody receipts on deposit and back on withdrawal, and its escrow holds whatever waits for a decision.
Each client has one gateway per network, and its address is the client's deposit address. The gateway mints custody receipts only against coins it has received and pays coins out only in the same step that burns the receipts.
Every deposit and every withdrawal is its own record with its own stage, and the stage is the status the client sees.
A gateway runs on the organisation's custody gateway add-on, so settings, roles and approvals are shared across all gateways of the organisation.
What a gateway does
A custody gateway gives one client a single place on one network to hand coins to custody and to get them back. The client deposits coins and receives custody receipts, ordinary DALP assets that stand for those coins. The client later returns receipts and receives the coins. The gateway runs both legs in one transaction, so a client who deposits or withdraws through it never loses a receipt without getting the coins. Three roles on the receipt act outside the gateway. The custodian role can force-transfer receipts to any wallet with a verified identity in the receipt's identity registry. The supply management role can mint receipts with no coins behind them, and can burn a client's receipts without paying out coins. The governance role can remove the compliance rule that keeps receipts in the loop.
One gateway holds several coins. An organisation enables the custody gateway add-on once, a single deployment of the gateway contracts for its system. Each client identity, the client's on-chain identity record, then gets its own gateway from the add-on. The gateway's address is fixed before the gateway exists.
Every gateway runs the implementation the add-on factory points to. A holder of the system manager role, or the add-on registry, can point the factory at a new implementation, which changes the code of every gateway of the organisation at once. No client and no gateway manager approves that change.
How a deposit moves
A deposit starts when coins reach the gateway, either because the client calls the gateway or because the client sends a plain transfer that the keeper then reports. The keeper and the screener are service wallets of the organisation, and the gateway managers are people, as Who acts at each step sets out. The gateway counts a plain transfer only once and only if the coins are still unclaimed by any other record. The keeper names the sender, and the gateway checks the coins itself.
A deposit that passes every check settles at once, and one that needs a decision rests in one of three stages until it settles, returns or is recovered.
A deposit has a stage from the first moment: there is no separate received stage. The gateway runs the steps in one transaction for as long as each can decide on chain, and stops at the first one that needs an answer from outside.
The screening mode decides which deposits wait.
- Always quarantine, the default: every deposit rests in quarantine and mints nothing until the screener acts.
- Credit approved sources: a direct deposit from an approved source settles at once. A plain transfer is recorded before anyone has confirmed its sender, so it rests in quarantine like a deposit from any other source.
- Off: every deposit settles at once while the gateway is not paused.
A paused gateway refuses direct deposits but still records reported transfers, each in quarantine whatever the mode, and none of them can be cleared until the gateway is unpaused. A client can leave a gateway that stays paused past the coin's time limit, as How a withdrawal moves explains.
The client can pull a quarantined deposit back to its confirmed sender after a stored wait. The screener can clear or refuse it. A frozen quarantined deposit keeps its stage and cannot be cleared, refused or pulled back until the freeze ends. The gateway managers can still return or recover it.
A deposit rests as mint refused when its receipts cannot be minted, for example because the custody receipt's compliance rules reject the receiving wallet. A direct deposit that reaches the mint in that case fails and leaves no record, since the client is present to see the failure. With always-quarantine screening the deposit waits in quarantine first, and a refused mint at the screener's clear moves it to mint refused. While the receiving wallet is frozen, the clear itself fails and the deposit stays in quarantine. A reported transfer that reaches the mint never reverts. When the mint is refused, the deposit rests as mint refused, even when the receiving wallet is frozen, and waits for the gateway managers to fix the cause or send the coins back.
Awaiting custody exists because some custodians screen incoming coins themselves and can decline them after they arrive. When the gateway is set to wait for custody, which needs the custody receipt to carry the hold feature, the same transaction that mints also places a hold on the minted receipts in the client's wallet. The hold releases when the keeper confirms the custodian accepted the coins. If the custodian sends them back instead, the gateway managers return the deposit, which burns the held receipts and pays the coins back to the confirmed sender. The setting suits destinations such as a Fireblocks vault.
A deposit ends in one of three ways. It settles, or it is returned to its confirmed sender with a record of who returned it, or the gateway managers recover it to an address they name in the recovery call, with the approvals the add-on checker requires for recovery. Recovery applies to a frozen quarantined deposit or a mint-refused deposit whether or not its sender is confirmed, and to coins a custodian sent back for a deposit whose sender was never confirmed.
How a withdrawal moves
A withdrawal starts when the client returns custody receipts to the gateway and names the approved payout address that receives the coins. The receipts move into the escrow and stay locked for that request until it is paid or the receipts go back.
A withdrawal moves from request to payout through review and funding, and a request that stops short returns its receipts to the client.
A request the client makes directly fails at once if the payout address is not approved, the amount is below the minimum, or the client's total for the day would pass the daily maximum. Receipts sent by plain transfer cannot fail that way: with no approved default payout address the request waits as awaiting payout, and the receipts stay locked until the client names an address. When the coin sets a time limit for naming a payout address and the client names none within it, the receipts go back. A request that passes takes the fee, gas ceiling and time limits in force at that moment, and keeps them for its whole life.
Review applies when screening or the travel rule covers the coin, or when the request reaches the instant limit. The screener clears screening. A request at or above the instant limit also needs the gateway managers' approval. With no instant limit set, the limit reads zero, so every request needs that approval. A gateway manager gives it with the withdrawal's approve transition, or Approve on the request in the Console. The call is checked: when the add-on's checker asks for approvals, the first attempt answers with the call to propose through the add-on approval routes, and sending the transition again once the proposal is approved runs it. A frozen request, or one whose client has a revoked or expired compliance claim, cannot be approved until that clears. Each requirement clears on its own, so a request that needs both stays in review until the screener and the managers have both acted. Approval never pays: once nothing is outstanding the request moves to awaiting funds.
The keeper pays waiting requests of a coin in the order they started waiting for funds. A request is paid in full or not at all, and the queue stops at the first request that funding cannot cover.
Only confirmed funding pays. Funding that a listed funding source sends by calling the gateway counts at once, and a plain transfer from a funding source counts after the screener confirms who sent it.
A claimable request has coins set aside for it, and its receipts wait for the coins to be collected. With auto-claim on, which is the default, the step that makes the request claimable also tries to burn the receipts and pay the payout address. If the payment fails, for example because the payout address was suspended after the request opened, the request stays claimable with its receipts unburned and the queue moves on.
With auto-claim off, the request becomes claimable and the client claims it. A claim pays the stored payout address, less the fee and any gas recharge when the gateway deducts fees. In accounting-only mode the full amount is paid and the fee is recorded as owed.
The keeper quotes the gas recharge from the price of the chain's native coin, which the deployment sets for each network and coin and which expires after an hour by default (Custody gateway keeper gas price). With no price, or a stale one, the request carries no gas recharge and the organisation pays the keeper's gas. The quote never passes the gas ceiling stored on the gateway.
A client can cancel while a request is in review or waiting for a payout address, or after it has waited for funds longer than the cancel time limit. The limit is the one the gateway held when the request was made, so a later settings change does not move it. With no cancel time limit set, a request waiting for funds cannot be cancelled. A claimable request can be cancelled once the screener or a gateway manager has suspended its payout address, or a gateway manager has removed it: the cancel releases the coins reserved for the request and returns the receipts. While the payout address stays approved, the request cannot be cancelled and is paid by a claim. A frozen request leaves the queue while younger requests go ahead, and rejoins at the back when its freeze ends. Receipts returning to a frozen client wallet wait as return pending until the wallet is unfrozen.
A client can also leave a gateway, for a deposit or a withdrawal, once it has stayed paused for the time limit set for the coin, counted from the earlier of the gateway's own pause and the add-on-wide pause. A quarantined deposit goes back to its confirmed sender. A request that is waiting for a payout address, in review or waiting for funds gets its receipts back, and a claimable request is paid to its stored payout address, or gets its receipts back when that address is no longer approved. A frozen deposit or request cannot exit.
A corporate action re-bases a queued request
A stock split, bonus issue or other action that changes every holder's units by a ratio also changes the receipts a request holds. The gateway does not change every queued request when the action runs. It re-bases a request the next time anything touches it: a review decision, funding, a claim, a cancel or the keeper's queue. The request then holds the shares a direct holder of those receipts would hold after the action, rounded the way the action rounds. The keeper's queue and the totals in review and waiting for funds move with it.
Between the action's record date and the moment its step lands, the gateway's escrow is frozen for the receipt token. In that window a client cannot open a new request or claim one, and an ordinary return is refused. The refusal names the token and the action. A return caused by the action itself, for a request it rounds to zero, still goes through. A request that was already queued stays queued, and it re-bases the first time it is touched after the step lands.
A claimable request that a corporate action changes goes back to waiting for funds on the new amount. Its set-aside coins are released, a freeze on it stays in place, and its cancel time limit counts again from the moment it went back to wait. A request the action rounds to zero ends as returned, with the reason “Returned by a corporate action”. It holds no receipts after the action, so nothing is paid out and nothing goes back to the client. The pending and claimable amounts a client reads for a request already show it on the new basis, before anything touches it: a claimable request the action changed reads as waiting again, and one rounded to zero reads 0.
What waits in the escrow
Each gateway has its own escrow, an on-chain contract that holds tokens under one controller, created in the same step as the gateway. The escrow holds the coins of deposits that wait in quarantine or rest as mint refused, the gateway's confirmed funding, the coins reserved for claimable requests, and the custody receipts locked for open withdrawal requests. A deposit that settles at once and is forwarded to a separate destination never enters the escrow. On a gateway without a separate destination, the coins of a settled deposit move into the escrow as funding for withdrawals.
The gateway's records and the escrow's records agree while the coin moves only by transfers. The gateway manager attests to that when enabling the coin. What the escrow owes the gateway equals the sum of seven kinds of coin: quarantined, held, provisional, funding, reserved, unallocated and returning. Provisional coins are funding reports still waiting for the screener to confirm the sender. The gateway's own address holds the coins of unsupported transfers and of arrivals the keeper has not reported. A forced transfer, burn or negative rebase applied to the escrow's balance of the coin breaks the equality, as Escrow explains. Coins that match no deposit, withdrawal or funding sit in an unallocated balance. Only the gateway managers can recover that balance, to an address they name, and recovery never touches funding or anything a record is waiting on.
The optional treasury
A treasury lets a coin pay withdrawals at once instead of waiting for funding. The add-on can link one treasury to a coin. The treasury is the organisation's own wallet or vault. The add-on stores its address and never holds coins.
Only a gateway without its own destination for forwarded coins draws from the treasury, and only below its instant limit. Each client still has its own gateway and escrow, so a draw never mixes clients' coins. A draw goes from the treasury straight into that gateway's escrow, set aside for one request. A treasury that cannot pay leaves the request waiting for funding. A gateway manager turns the treasury off alone, because turning it off only removes a way to pay, while linking a treasury needs approval.
Who acts at each step
Four roles act across both flows: the client, the keeper, the screener and the gateway managers. Gateway managers are people, and the keeper and the screener are service wallets of the organisation. A gateway permission manager, a system role the organisation admin grants on the permissions screen, does not act on deposits or withdrawals. It grants the manager, keeper and screener roles once for the whole add-on and sets how many approvals each checked action needs.
A frozen record blocks the steps that move that record forward, and no other record. Reports of facts still go through: the keeper can report a custodian's return of coins for a frozen deposit that is awaiting custody, and the report records the amount without ending the freeze. The screener or a gateway manager freezes it, and the freeze ends at its expiry unless renewed. Once the gateway managers mark a frozen record as reported, the freeze no longer expires and the record leaves only by a return or a recovery.
A gateway manager can set a gateway's own screener key, with the add-on checker's approval. That key then answers screening for that gateway in place of every screener role holder.
Profiles and settings
Settings resolve at read time from three layers: the gateway's own value, else the value on the profile it points to, else the add-on default for the coin. A profile is a named record on the add-on holding values per coin, such as time limits, fees, auto-claim and who answers screening. An administrator assigns a profile to a gateway, and changing the assignment is one change instead of many.
A request in progress keeps the terms stored with it, so a later change reaches new requests only. Lists, the destination for forwarded coins, pause and approval counts are read live. Removing a profile that a gateway uses is declined.
Approvals through the add-on checker
The add-on checker is the approval mechanism for the gateway's sensitive actions, run by the add-on's own access manager contract. A gateway manager proposes an action, a set number of other gateway managers approve it, and the proposer then makes the call with the same parameters. The access manager counts the approvals on chain, so a change that needs approval takes effect only once that number of other gateway managers have approved it. Pending approvals appear in Actions.
The number of approvals is set per action. Actions that only tighten, such as a pause, a freeze or a stricter setting, apply at once. Actions that loosen or move value, such as linking a treasury, moving a gateway to another profile or returning a deposit, need one other approver by default. Enabling a coin, creating or removing a profile, and creating a gateway without a profile need only the gateway manager role and no approval, whatever the counts say. A gateway permission manager can change that count for every gateway or for one gateway, alone and at once, because the count change needs no approval of its own. A count of zero lets one gateway manager act alone, so treat the count as part of the control.
The add-on checker is separate from the Approvals settings in General. One wallet counts as one approval, so several people behind one approval need a multisig smart wallet as the role holder.
Running the add-on through its API
Deposit and withdrawal stages lists every stage a record can be in, who moves it and the time limit behind it, and the custody gateway API how-to walks a deposit and a withdrawal through the routes.
An organisation owner or platform administrator reads and changes the add-on at /. The reads answer from indexed chain data, so a read made just after a write can lag. They answer 404 while the organisation's system has no custody gateway add-on on the network.
The gateway routes belong to the “Self-custody” licensed module, which the features.custodyOps setting switches on for the deployment and which is on by default. A deployment that sets it to false serves none of these routes. An organisation that switched the module off for itself keeps its reads, and every write route answers 403 Forbidden with platform.module.DISABLED (DALP-20531).
GET …/answers the add-on's factory, fee account, pause switch and access manager, andfactory GET …/,tokens …/profilesand…/gatewayslist the coins with the receipt each mints, the profiles and the gateways.GET …/answers one gateway with its client identity, country, profile, pause state, client wallet and payout address.gateways/ {gateway Address} POST …/enables a coin with its custody receipt. The call must carry the coin'stokens freeze-expiryandpaused-exit-afterin the samedefaultslist, because they are the only settings a coin needs to be enabled. A list that omits one, repeats a name, or gives a value the setting cannot hold answers 422, an already enabled coin answers 409, and nothing is queued. Enablement refuses a receipt whose decimals differ from the coin, a receipt without the own-custody-gateway rule bound to this factory, and a freeze expiry or paused-too-long limit that is missing or zero. The gateway manager attests that the coin's balances change only by transfers. The treasury is set after enablement.POST …/creates a profile from a name and the claim topic a client must hold, andprofiles POST …/withprofiles/ {profile Id}/ transitions {"transition":"remove"}removes one. A profile that gateways use answers 409.POST …/creates the gateway of a client identity under a profile. A client identity that already has a gateway answers 409.gateways PATCH …/,tokens/ {token Address}/ settings …/andprofiles/ {profile Id}/ settings …/change settings at one level, up to 20 in one request, and agateways/ {gateway Address}/ settings nullclears that level's own value so the level below applies. Switching wait for custody on, or changing where coins go while it applies, needs coins-go-to to resolve to a wallet of one of the organisation's Fireblocks custody providers, at the changed level and every level below it.PATCH …/moves a gateway to another profile, andgateways/ {gateway Address} PATCH …/binds its client wallet. The signing administrator must be a gateway manager, and a wallet that is not the client's answers 422.gateways/ {gateway Address}/ client- wallet POST …/andgateways/ {gateway Address}/ approved- sources …/approved-payoutsadd an approved source or payout address, and their…/{address}/transitionsremove one or suspend and reinstate a payout address.POST …/adds a wallet whose transfers of the coin fund withdrawals, and itsgateways/ {gateway Address}/ tokens/ {token Address}/ funding- sources …/removes it.{source Address}/ transitions
The administrator's own wallet signs each write. Each write asks for a wallet step-up and an Idempotency-Key. It answers 200 once the transaction settles inside the request's preference window, and 202 with the transaction to poll otherwise. Before anything is queued, the platform tries each call against the chain from the administrator's wallet. A call the add-on's checker wants approved answers 422 with the exact calls to propose and their hashes, and the same request is queued once the checkers have approved it. A call the add-on refuses answers 422 with the name of its revert, and a coin whose custody receipt cannot hold deposits answers 422 when wait for custody is switched on.
A gateway binds no client wallet when it is created, because a client identity can hold several wallets. Until a manager binds one, that client's own routes answer 404, and each mint reads the bound wallet and checks again that it belongs to the client identity.
Roles and the two service wallets
The add-on keeps its own access manager, so one grant covers every gateway of the add-on. A gateway permission manager grants and revokes the manager, keeper and screener roles at GET /api/ and POST /api/ and at POST …/ with {"transition":"revoke"}. The organisation owner, a platform administrator and a member whose wallet holds the gateway permission manager role on the system may call these routes, and anyone else answers 403. The chain still decides: a wallet without that system role answers 422 and nothing is queued.
An add-on with no access manager answers GET …/ with an empty page. On such an add-on the first grant queues two calls in one write: ensureAccessManager() on the factory, then grantRole on the access manager that call creates. A revocation before then answers 404 GATEWAY_. Revoking the keeper or screener role from a wallet that the platform still signs with answers 409 GATEWAY_SIGNER_IN_USE, so rotate the signer first.
In the Console the same roles are on Organisation settings › Roles and permissions › Add-on roles, where a permission manager grants or revokes a holder with one PIN, and for everyone else those controls are off and say why.
A grant does not activate a signer. The keeper and screener wallets are set up at /, which lists every wallet of both roles with its state, its last observed native balance and whether that balance is below the role's threshold.
Both role-member writes require a Console-issued session as well as wallet verification. A Portal-issued session, an anonymous session or one with no recorded issuing app answers 403 Forbidden with WALLET_ (DALP-200384) and starts no write. Sign in to the Console and retry. These routes do not accept API keys. The gateway permission manager check and the on-chain role check still apply.
POST …/sets up a role's wallet from one of the organisation's custody provider configurations and tops it up with gas unlesssigners fundingisskip. Sending it again before the grant answers the same wallet.POST …/withsigners/ {role}/ transitions {"transition":"rotate"}mints the role's next wallet. The current wallet keeps signing until the new one is granted.PATCH …/sets or clears the low-balance threshold of every live wallet of the role.signers/ {role}
A scheduled pass every minute switches each granted wallet to active and retires the one it replaces, so a new wallet signs nothing until a gateway permission manager grants it the role on chain.
Reading a gateway's records
A deposit and a withdrawal are each one record with a stable identifier and one history row for every stage it entered, in the order the chain logged them. A deposit that settles inside its recording call has one history row. The record keeps what an auditor needs: for a deposit the receipts minted, the fee, the address the coins were forwarded to, the held amount and the custodian's answer, and for a withdrawal the reserved and paid coins, the payout address, the fee, the return reason and any failed auto-pay.
GET …/ answers the gateway that serves the signed-in client wallet. GET …/, …/withdrawals and …/unsupported list the records, filterable by text, and the deposits list also takes filter[source] as txHash:logIndex. GET …/ and …/ answer one record with its stage history, and each withdrawal carries needsScreening and needsApproval, the review steps it still owes. An operator, the gateway's client wallet and a wallet holding the screener role may read a gateway, and anyone else gets 404.
The client's own writes are POST …/ and POST …/. When the wallet's allowance of the coin or the receipt is short, the approval is queued first in the same request.
A record moves by one transition at a time.
A transition the record's stage does not allow answers 409 with the stage and the transition, and nothing is queued. The cancel of a claimable request whose payout address is still approved answers the same 409. A transition that needs the screener or keeper role answers 403 when the wallet does not hold it. One that needs the add-on's checker approval answers 422 with the calls to propose, and one the contract refuses answers 422 with the name of its revert. Confirming that the custodian accepted a deposit is the keeper's alone and has no transition of its own.
An organisation owner or platform administrator also reads what the client never sees: the gateway's review queue with each item's off-chain notes, nearest deadline first, the notes an operator appends to a deposit, the screening answers of each linked provider with its reference, verdict and score, and every setting the add-on knows for a coin with its effective value and the level it comes from.
The Console shows the same records on the gateway's Deposits, Withdrawals and Unsupported tabs, newest first with search and stage filters, and each row opens to its facts and stage history with the decisions its stage allows. The Investor portal lists them on the Transfers tab of Portfolio, with open records under In progress and the rest under History, newest first in client wording.
Closing a gateway, and following a client to a new wallet
Closing needs the approvals the add-on checker requires for it, and is refused while any deposit or request has not ended, any receipt the gateway minted is unburned, or the gateway's escrow still owes it coins. Recover the unallocated coins first. A closed gateway refuses deposits, withdrawal requests and funding reports, and closing cannot be undone. A close that is blocked stays disabled in the Console and names what blocks it.
After closure is indexed, the Console shows Closed in the gateway list and detail header, even if the gateway was paused when it closed. The Overview tab shows the closure date and time, and removes the Pause, Unpause, Close and client freeze controls. You can still read the gateway's records and history. Gateway list and detail API responses include closedAt, which is null until closure is indexed and then contains the closing block's timestamp.
When the identity registry recovers a client's lost wallet to a new wallet under a new identity, the gateway follows the client there. Anyone can rebind the gateway, naming the new wallet: the gateway follows the registry's recovery links back from that wallet, at most eight hops, to its current client identity, and a wallet with no such link is refused. A holder of the identity manager role records that recovery link alone, so that role decides which wallet takes over the client's gateway, escrow and open requests. The rebind keeps the gateway's address, escrow, records and settings, moves the add-on's one-gateway-per-identity map to the new identity and makes the new wallet the client wallet. A new identity that already has a gateway of its own is refused, and rebinding to a wallet of the current client changes nothing. The new wallet cancels and claims the requests the lost wallet opened, and the lost wallet can no longer act. The Console's identity recovery makes this rebind for you: after it moves the user's token balances, it rebinds the gateway of the lost identity, current or former client, to the replacement wallet and to the replacement smart wallet, and moves the holds of every lost wallet of the client or a former client, also when the identity did not change. If the issuer's forced token recovery has not moved the receipts held for custody, the gateway refuses the rebind and the recovery stops with that reason. Execute the recovery again once the token recovery finishes.
A gateway manager can also freeze every wallet of a client on every custody receipt the add-on enabled, from the detail of an open gateway. Before it signs, the dialog names the wallets, the receipts and the open records the freeze reaches. It records a reason for each wallet and receipt. Frozen wallets cannot move receipts until a gateway manager unfreezes them.
When a client's claim is revoked or expires
When a compliance claim the gateway's client must hold is revoked or expires, the client is flagged. The flag freezes what the client could move: the revocation fan-out freezes the client's open deposits and withdrawals and suspends its payout addresses. No withdrawal can be requested, and the transitions that pay or credit the client wait until the flag clears. Those transitions are clearing or retrying a deposit, and clearing, collecting or exiting a withdrawal with its coins. A write that would move value while the flag stands is refused with GATEWAY_CLIENT_FLAGGED (DALP-13995).
GET …/ answers whether the flag stands, the open flags first with what raised each of them, and what the flags and payout-address hits did on the gateway. The provider issuing the claim again, or renewing it, clears the flag on its own. A screener clears reviewed flags with POST …/ and {"transition":"clear","trigger, naming the open flags they reviewed. A flag raised after the screener looked stays open and the response shows it. Once no flag stands, the fan-out unfreezes what it froze. A payout address the flag suspended stays suspended until it is reinstated.
The gateway's Console panel names the open flag and links each frozen record, with when each freeze ends and renewal where the freeze lapsed.
Whitelisted addresses against the approved lists
GET …/ lists the client's whitelist entries that matter to the gateway: proved and active addresses, and revoked ones that are still an approved source. Each row carries when the address was proved, whether it is an approved source or payout address, and the proposal still to raise: add a source for an active entry that is missing from the sources, remove a source for a revoked entry that remains in them, and add a payout address for a proved or active entry that is missing from the payout addresses. The list reads the participant that owns the gateway in your organisation. A gateway whose client has none lists nothing.
The gateway overview shows the same list as the Whitelist panel. Each button raises the proposal through the existing approved-source and approved-payout routes and asks for your wallet verification. Nothing is raised unattended, and the direct routes are unchanged.
Frequently asked questions
Does a client need the keeper to leave a gateway?
No. Cancelling a withdrawal, pulling back a quarantined deposit and leaving a gateway that has stayed paused for the time limit set for the coin are calls the client's own wallet sends. None of them depends on the keeper, so a client can leave when the keeper is not running.
Can a deposit mint receipts for a coin the gateway does not accept?
No. A direct deposit of a coin the add-on does not accept fails. A plain transfer of such a coin is recorded as unsupported and waits for the gateway managers, who return it, enable the coin and turn it into a deposit, recover it or mark it ignored.
Why does a deposit rest in awaiting custody instead of settling?
Some custodians accept incoming coins only after their own screening. The gateway mints the receipts and holds them in the client's wallet in the same transaction, so the client sees the deposit, and the hold releases only when the custodian accepts the coins.