Use-case guides
The rest of this documentation is organised by component: deposits, sweeps, bridges, payments, migration. That is the right shape for looking something up and the wrong shape for starting. Nobody arrives wanting to configure a sweep policy. They arrive wanting to hold customer balances, or take card-free payments for four hundred shops, or move a book of two hundred thousand addresses without a customer noticing.
These pages are the other axis. Each one is a whole job, start to finish, in the order you would actually do it, linking down into the reference pages for the detail.
Which one are you?
A fintech holding balances for your own customers
Collecting one stablecoin across several chains and wanting one balance
A shop that will run its own Edge and take crypto on its own checkout
A fintech taking payments for shops, on a page we host
The same, but the page must be entirely yours
Sending someone a URL and getting paid once
Raising money from many people
Already running your own wallet infrastructure
Letting customers withdraw to a network their balance is not on
Deciding what may be done with a pooled treasury
Crediting a token that is not in the catalogue
Several of them compose. A gateway (4) that collects on five chains wants 2 underneath it and 10 on top of it. A fintech doing 1 hits 9 the first week a customer pastes an exchange address.
What every one of them assumes
Three things, stated once here rather than at the top of each page.
Your Edge holds the keys and Cloud does not. Every flow below is built so that a completely compromised Ziklag can delay your money, cost you a fee, or tell you something untrue — and cannot move a customer's funds. Where a page describes a control that looks like unnecessary friction, that is usually the control doing its job. See Non-custodial.
Your ledger is yours. ChainOS records what happened on chain. It does not know what a customer is owed, what an order is worth, or what your commission is. Every page here that touches money has a section on the records you keep, because that is the half that decides whether the integration is correct.
Read API conventions first if you have not. The envelope,
error.code, smallest-unit string amounts and the three credential planes are assumed
throughout and are not re-explained.
A note on what is not built
These guides name gaps where they exist, in the place you would hit them, rather than collecting them in a footnote nobody reads. Bitcoin cannot yet be consolidated out of an address book you migrated in; some bridge routes do not exist and are refused with a reason; there is no swap and no price feed anywhere in the product. Each is stated where it matters.
Where ChainOS refuses a chain or a path rather than guessing at it, that is the design and not an omission — a stub that produced a plausible-looking answer about somebody's money would be worse than a refusal that ends the question.