14 · Chains, abstracted
Deposits, funds and payments settled on-chain while the customer sees an ordinary account. The ledger, the controls and the redemption path built so nobody has to care which chain it ran on.
Tokenized settlement has become the live institutional question, not a research topic. Banks are building tokenized deposit networks to keep programmable money inside the regulated perimeter, and fintechs are settling on stablecoins because the alternative clears in days. Both are solving the same problem, moving value on a rail that runs at software speed, and both create the same engineering obligation: the on-chain position and the ledger must never disagree.
The work is almost never the chain. It is the abstraction around it. A customer should see a balance, a payment and a statement; they should not see a wallet, a gas fee, a block confirmation or a bridge. That means custody and key management, a ledger that treats the chain as a settlement venue, not a source of truth, reconciliation that runs continuously against on-chain state, and a redemption path that behaves when everyone uses it at once.
We build both sides of the choice. Tokenized deposits keep the funds as a bank liability inside the regulated perimeter; stablecoin settlement reaches counterparties a bank network does not. Which is right depends on who you need to pay and what you are allowed to hold. And the honest answer for most institutions is that they will run both, which makes the abstraction layer the thing that actually has to be right.
Common questions
What is the difference between a tokenized deposit and a stablecoin?
A tokenized deposit is a commercial bank deposit recorded on a distributed ledger. It remains a claim on the issuing bank, stays inside the regulated perimeter, and carries that bank's credit. A payment stablecoin is a separate instrument backed by a reserve held by its issuer. The practical consequence is who you are exposed to and what happens in stress: a tokenized deposit behaves like the bank behind it, a stablecoin behaves like its reserve and its redemption process.
Do customers need a wallet to use tokenized settlement?
No, and in most institutional products they should not have one. The chain is a settlement venue underneath the product, not a surface the customer touches. They see an account, a balance and a payment. Custody, keys, gas and confirmations are handled by the platform. Exposing a wallet to a retail or corporate customer imports a set of failure modes, from lost keys to failed transactions, that the institution then has to support.
How do you keep an on-chain balance and a core ledger in agreement?
By making the ledger authoritative for what is owed and the chain authoritative for what has settled, then reconciling the two continuously rather than at end of day. Every on-chain movement produces a ledger posting and every posting expects a settlement event; unmatched items on either side are exceptions raised immediately. Treating the chain itself as the ledger is the common mistake. Reorganisations, failed transactions and pending states all mean the chain is not a reliable record of intent.
Which chain should an institution settle on?
Fewer than the roadmap suggests, chosen for where the counterparties already are rather than for throughput benchmarks. Each additional chain multiplies custody surface, reconciliation, monitoring and redemption paths while demand rarely multiplies with it. Most institutions are better served by one chain done properly, with the architecture written so a second can be added without changing the ledger.
Next capability
Local agentic systems
Bring us the hard part.
Forty-five minutes with the people who would actually run the build.