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?
| If you are… | Start here |
|---|---|
| A fintech holding balances for your own customers | Customer wallets |
| Collecting one stablecoin across several chains and wanting one balance | One asset, many chains |
| A shop that will run its own Edge and take crypto on its own checkout | Merchant acceptance |
| A fintech taking payments for shops, on a page we host | Payment gateway |
| The same, but the page must be entirely yours | White-label gateway |
| Sending someone a URL and getting paid once | One-time payment links |
| Raising money from many people | Donation pages |
| Already running your own wallet infrastructure | Migrating a book |
| Letting customers withdraw to a network their balance is not on | Cross-network withdrawals |
| Deciding what may be done with a pooled treasury | Treasury policy and yield |
| Crediting a token that is not in the catalogue | Custom tokens |
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 consolidation cannot yet be signed; 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.