The Account-to-Treasury Lifecycle Behind an Onchain Financial Product

Onchain financial products are often assembled as disconnected components: custody, stablecoin rails, wallets, tokenized assets, and sources of return. Each is real, each works, and none of them individually knows whose money it is holding.

That is the gap the article is about. An institutional product has to connect those components to account ownership, reconciliation, customer balances, exception handling, and treasury policy — and the requirement can be stated in four lines. Every movement needs an account state. Every settlement needs a defined purpose. Every return needs evidence. Every distribution needs a governed destination. A component stack that cannot satisfy all four is a set of capabilities, not a product a regulated institution can operate.

The lifecycle the article specifies runs: operating account, settlement, documented return, treasury distribution.

The operating account establishes ownership, with the institution's core ledger as the source of truth. The design point is that the institution keeps its interface, brand, and customer relationship — USDC is the movement layer, and the bank remains the customer experience. Settlement then connects that ledger to onchain execution: batches record source accounts, purpose, amount, authorization state, and destination, with screening, sanctions controls, and whitelisting applied before release, so every movement stays connected to its originating account events and control history.

The third stage is the one that distinguishes this from a payment rail. On completion, a proof-of-return record is generated and linked back to the original settlement batch, carrying the batch reference, deployed capital, destination, network, transaction identifiers, completion dates, gross return, variance, approval trail, and ledger postings. Operations and finance receive a reconciliation statement rather than reconstructing what happened from a block explorer — which is the difference between an auditable product and an interesting one.

Exception handling is treated as part of the lifecycle rather than as failure. Failed settlements, delayed transactions, stuck batches, depegs, and reconciliation variances enter named states, and the customer's available balance reflects the last confirmed account event while unresolved capital remains visible as pending. Financial truth is preserved through the exception instead of being suspended until someone resolves it.

Treasury distribution then applies the institution's own rules: customer principal and earned return to designated accounts, institutional revenue posted separately, the same accountable path every cycle.

The boundary is explicit throughout. Sagitta orchestrates the lifecycle alongside the institution's existing banking environment; the institution retains the regulated customer relationship, the custody structure, and compliance responsibility. Sagitta does not take custody or hold customer funds.

Sagitta Banking is In Development. The article describes the specified control surface and the two engagement paths — an architecture and diligence engagement, and a pilot — not a delivered integration. The full article is published on LinkedIn.