Introduction
ChainOS lets a fintech manage customer accounts on blockchain the way a core banking system manages fiat accounts — address issuance, balance enquiry, transaction monitoring, settlement and event notification — across ten chains through one API.
It does that without ever holding your private keys, and without Ziklag being able to move your customers' funds.
The one thing to understand
The BIP-39 mnemonic that derives every one of your keys exists only inside the Edge container you run, on your own infrastructure. Ziklag Cloud receives extended public keys and one Ed25519 public identity key, and nothing else.
From an extended public key you can derive every receive address on a chain — which is exactly what monitoring needs. You cannot derive a single private key — which is exactly what spending needs. That asymmetry is a property of BIP-32, not a policy Ziklag has adopted and could quietly drop.
Every design decision in this product follows from that split, and several of them look strange until you hold it in mind: why there is a container to run at all, why Solana and Stellar work differently from the other seven chains, why a changed mnemonic pages your account owner, and why nobody can help you recover a lost one.
There is no reset flow, no support escalation and no key escrow. Any of those would mean Ziklag held something that could reconstruct your keys, which is the property the whole product is built to deny. Back the mnemonic up before you issue a single address, and read Mnemonic management first.
The shape of it
Two sides, and only one of them can spend.
Your application talks to the Edge on localhost:8787. The Edge talks to Cloud. Cloud
talks to the chains.
Every connection is dialled outbound by the Edge. Cloud never initiates a connection to your infrastructure, so the Edge needs no inbound port, no public ingress and no DNS record. That single property is what usually gets this product through an infrastructure review.
The Edge exposes the same API surface Cloud does, on the same paths. An integration
written against http://localhost:8787/v1 can be pointed at
https://api.chainos.cloud/v1 without a code change — though in practice you want
the Edge, because that is the endpoint your application holds a credential for.
What you get
| Chains | Bitcoin, Ethereum, BSC, Polygon, Avalanche, Base, TRON, Solana, XRP, Stellar |
| Addresses | One per customer per chain, derived from your own extended public keys |
| Balances | Native and token, in the chain's smallest unit, as decimal strings |
| Transactions | Inbound monitoring with per-chain confirmation thresholds; outbound built by Cloud, signed by your Edge, broadcast by Cloud |
| Events | Nine webhook events, HMAC-signed, at-least-once, durably queued with a retry ladder and a replayable dead-letter queue |
| Environments | Live and sandbox, separated by API key prefix and immutable per process |
| Packaging | A cloud subscription. You run one container — the Edge — and nothing else |
Where to start
If you are integrating, read the Quickstart — it goes from nothing to a derived deposit address, then to a simulated confirmed deposit, without touching a chain. Then Deposits, Webhooks and Idempotency, in that order. The third one is where integrations actually go wrong.
If you are reviewing this for security, read What Ziklag can and cannot do. It states the residual risks alongside the guarantees, which is usually where a review starts anyway.
If you are the one operating it, read Monitoring and Edge liveness. There is one metric that matters more than all the others and it is named on the first of those pages.
If you are moving an existing wallet across, you almost certainly already hold keys and have issued addresses to your own customers. Start at Mnemonic management — an existing recovery phrase can become your Edge's phrase, in which case your addresses simply are ChainOS addresses and there is nothing to migrate.
If you are picking a plan, Bands and tiers and What is billed.
The console is at app.chainos.cloud and the generated API reference at api.chainos.cloud/api-reference/. Both are absolute: each surface is served from its own hostname, so a root-relative link from here would resolve against the documentation host and 404.
Conventions in these docs
Paths are written as they appear on the wire: POST /v1/addresses. Chain slugs are
lowercase — eth, not ETH — because that is what the API accepts and returns; see
API conventions.
Monetary amounts are always strings in the chain's smallest unit. "1000000" with
"decimals": 6 is one USDT, and it is a string because 10^18 wei does not survive a
JavaScript double.
Where this build deviates from the technical specification, the page says so and says why. Where a figure is a current network parameter rather than a protocol invariant — XRP's reserve, Solana's rent minimum, Stellar's base reserve — the page says that too, because those change by amendment or validator vote, and a document that presents them as fixed will eventually be wrong.