Deposit funding instructions
How an operator chooses which tokens investors can deposit and how the instructions API tells an investor where to send them.
An investor who opens a deposit screen needs to know two things: which wallet address to send funds to, and which token to send. A DALP InstanceA DALP Instance is one self-contained copy of the platform, deployed inside a boundary you choose and connected to ledger networks you approve.Read the concept answers both through one API read, which any front end built on the platform API can call to show the investor the same instructions. The Investor portal shows the same addresses in the Deposit dialog on the portfolio page, from the watch route's answer; the Console does not read them yet.
The read lists one entry for each of the investor's active custody wallets and each token the organization accepts, once the platform watches that wallet for that token. Every wallet address belongs to that investor alone, so the address identifies the deposit and no separate reference is needed. The list is empty until the organization accepts at least one token.
Which tokens are accepted
A token is accepted for deposits in one of two ways.
| Source | Who sets it | What it covers |
|---|---|---|
Deployment setting custodyOps.depositAssets (environment variable CUSTODY_OPS_DEPOSIT_ASSETS) | The operator of the deployment | A JSON list of network and token address pairs. Only a token the indexer holds under the organization's own system is offered, so the setting can never expose a token that belongs to another organization. |
| Registered external token | An organization member with the tokenManager role | A token from outside the platform that the organization registered by hand on the network and has not dismissed. It is offered to that organization only, and only once the platform indexes the token's transfers, because a deposit of an unindexed token could not be credited. A token the platform detected automatically is not offered until someone registers it by hand. |
A token that qualifies both ways is listed once, with the details the indexer holds.
The feature is part of the custody operations surface and stays off until features.custodyOps is on for the deployment. A transfer to an investor's wallet is credited only while the platform watches that wallet, and the platform starts watching when the investor opens Deposit (see Start the watch). A transfer sent before the watch exists is not credited.
Register an external token
Deposit instructions offer the organization's own external-token registry; custody operations keeps no token list of its own. Register a token on the External tokens page or with the external-token registration route in the generated API reference. Registration records the token in the on-chain registry and reads its name, symbol, and decimals from the contract; those are the details investors see. Registering a token the platform detected automatically accepts it without a new registration. Dismissing a token stops it from being offered, and registering it by hand again offers it again.
Read the instructions
An investor reads their own instructions with the deposit instructions route in the generated API reference. It also answers on a network where the organization has no system deployed yet, offering only its registered external tokens there. Each wallet is the investor's custody account on the requested network, and an account with a smart wallet lists the smart wallet rather than its signer. Each entry names the network, the wallet that receives the transfer, and the token to send with its address, name, symbol, and decimals. Send only the listed token on the listed network: a transfer of any other token to the wallet address is not credited as an accepted deposit.
The read lists an address only after its watch exists, so it never offers an address that nobody watches. Start the watch first (see Start the watch); until then, the read leaves the wallet and token out.
Create the deposit wallet
An investor with no custody account on the current network opens Deposit and sees "Create deposit wallet". The wallet is created only when the investor chooses it and passes wallet verification. It is a managed custody wallet, one per investor per network. The name the custody provider records for it is an opaque identifier and carries no personal data.
Start the watch
The Investor portal registers the investor's wallets by calling POST /api/v2/custody-ops/deposit-watches. The route registers each wallet and accepted token as a deposit target and starts the deposit detector for it. It returns one entry for each wallet and accepted token. An empty list means the organization accepts no token yet. Calling it again starts nothing new. A target that is already watched for a different wallet, investor, or reset epoch is refused with DEPOSIT_WATCH_CONFLICT.
Each entry in this route's response has a state. A watching target carries the wallet address, and the instructions read lists it from then on. A registered external token on a wallet the indexer does not record transfers for yet answers preparing, with no address, and the route starts no detector for it. A new wallet becomes ready after the custody watch-list sync opens its watch and the indexer passes the watch's first block. Call the route again to start the target then.
A new target starts at the network's current head, so history before the watch is not credited. The portal therefore reads only this route, and shows the address as a QR code, as text, and with a copy button only after the route answers watching. While the route runs, the dialog shows "Preparing your deposit address". A transfer to a watched address is credited to the investor once and held until it clears.
Fireblocks policy
The Fireblocks policy rules each DALP vault needs with account abstraction off and on, and the limits DALP enforces where a Fireblocks rule cannot see them.
Observability
The OpenTelemetry pipeline a DALP instance exports by default: traces, metrics, and logs, and how the admin debug bundle auto-wires to an in-cluster stack.