Incoming deposits
Money that arrives at a wallet's address without this platform sending it: how it is observed, when it is credited, what happens when the chain changes its mind, and what a spend is authorised against.
A deposit no operation of this platform is behind
A wallet publishes a deposit route: an exact network, asset representation and address. Anybody can pay that address from anywhere — another product, an exchange, a person's own wallet — and no operation of this platform stands behind that transfer.
Those funds are credited. A durable observer per chain family watches the deposit routes the deployment has published, attributes each inbound transfer to a wallet and to a declared asset representation, and produces the same deposit operation, with the same ledger posting, as a credit this platform originated itself. origin: test_funding marks a credit the deployment granted: the grant an account receives when it is provisioned, and the one a faucet of the deployment gives on request. It appears outside production only, and a deposit the observer credited on its own omits it, so a Partner reads the field to tell a granted credit from an inbound payment. On Bitcoin coins come from outside this platform, so a grant from the deployment's faucet credits a confirmed output the address already holds, for the value the chain gives it, and names that transfer under deposit the way any observed credit does.
Every credit is idempotent on the chain's own identity for the transfer — the network, the transaction, the index of the transfer inside that transaction, and the asset, which on Cardano tells apart the ada and the native assets one output carries under a single index. An observer re-reads a range after a restart, after a provider failover or after a backfill, and each component keeps the single credit it already has.
When a deposit is credited
Every network this deployment observes declares how deep a transfer must be before it is credited, and the deployment states that threshold rather than leaving it to be inferred from how long a credit happened to take.
A transfer that has not reached its network's threshold is money the wallet holds and this platform has not accepted yet. It is reported as pending incoming, it is never counted as available for a spend this platform authorises, and it is credited by the same transfer becoming deep enough — never by a second transfer, and never by a provider notification on its own.
A transfer the chain drops before the threshold is reached is abandoned rather than credited, and it ends explicitly rather than by going quiet.
What is observed, family by family
| Family | Observed for credit |
|---|---|
| EVM | The network's native coin, and the ERC-20 representations the deployment's manifest declares |
| Bitcoin | The outputs paying a watched address |
| Cardano | ada only |
Roadmap Crediting a Cardano native asset. One Cardano output carries ada together with any number of native assets, and the identity a credit is idempotent on does not tell them apart — an identity cannot be invented now and corrected later, because changing it makes a re-read credit everything a second time. Nothing is hidden by the exclusion: the balance still reports what the chain says the address holds, and the output is recorded as an unattributed deposit.
Unattributed deposits
A transfer arriving at a watched address that cannot be attributed to a wallet and to a declared asset representation is recorded with everything the chain said about it — the network, the transaction, the transfer index, the address, the asset as the chain names it, and the amount in that asset's base units.
It credits nothing. It is never dropped, never attributed by resemblance, and never credited to the wallet that owns the address under an asset the deployment did not declare, and it is readable on the deployment's operational surface. An empty list of them means nothing arrived unattributed; it never means nothing was looked at.
When the chain changes its mind
A threshold is a policy, not a proof. Where the deployment's reader for a network can prove that a credited transfer is gone — a reader that answers about a named transfer, on this network, in this transaction, at this index — the credit is undone as an accounting event: compensating postings bring the ledger's projection back to what the chain says.
The ledger is append-only, and the deposit operation that recorded the credit stays exactly as it settled. The reversal is a record of its own, carrying the transfer it reverses and the reason, so the fact that a credit existed is never erased.
Where the reader can only enumerate what an address holds now, an absence proves nothing: an output missing from that enumeration was rolled back by the chain, or was spent, or fell outside the part of the chain the read covered, and those three are the same silence. Reading that silence as a rollback would reverse every deposit a wallet ever spent. A reader that cannot prove an absence declares the point from which its answer is complete and never turns an absence into a reversal — there the finality threshold is the whole of the protection, and a rollback after a credit stays visible as the chain's figure disagreeing with the ledger rather than as a correction this platform makes on its own.
What a spend is authorised against
Since 2026-09-06 a spend is authorised against the chain's figure, and not against the ledger's projection.
The projection is what reconciliation compares against, and it is reported beside the balance under its own name. It is not the answer to what a wallet holds. Authorising against it denied a person the use of money their address held, for the sole reason that this platform had not originated the transfer that brought it. The projection keeps every other job it had — accounting, provenance and reconciliation — and stops being the gate.
POST /v1/transfers refuses with CHAIN_NOT_READ when the chain that authorises this spend is one this deployment reads and could not reach on this request. A balance surface may report a figure it did not verify and say so; an authorisation may not, because moving money against an unverified figure is how it moves money that is no longer there. The refusal is retryable: the same request succeeds once the chain answers, and a retry of a transfer that was already accepted answers with the operation it created rather than reading the chain again.
A separate refusal covers the deposit that is real but not yet deep enough. It carries what is required, what the chain says is spendable, what the ledger has available and the address that was read, because the difference between the two readings is what tells a sender to wait rather than to add funds.
Availability
Available today Observation and crediting run on the networks a deployment enables, and were exercised end to end on a public test network: an address this platform does not control paid a wallet's deposit route with an ordinary token transfer, the observer credited the ledger unasked, and a transfer out of that wallet then settled.
Declared limitation On the deployed public test networks, a deposit of an EVM network's own coin from an external address is not yet credited; token deposits are. Until it is, such a deposit shows in the balance observed on chain and not in the available balance.
Roadmap Networks where the funds are real. Each of them needs its finality depth chosen first, and a deposit on a network whose depth nobody has chosen is not credited.