Treasury policy and yield

Once sweeps have put your balances in one place, somebody will ask the obvious question: can we earn something on it? Staking, a lending protocol, a tokenised money-market fund, an institutional yield desk.

This page is about answering that question properly. It has three parts: the distinction the whole answer rests on, what is commonly expected of a firm holding customer crypto, and precisely what ChainOS will and will not do.

Not legal or investment advice

What follows describes patterns commonly seen in regulated firms and the controls ChainOS provides. Your obligations depend on your licence, your jurisdiction and your customer agreement, and none of those are things this documentation can know. Take advice.

The distinction everything rests on

There are two piles of money in your treasury wallet and they look identical on chain.

	Customer funds	Own funds
What it is	The sum of every customer's balance in your ledger	Fee income, float you funded, capital, retained profit
Who it belongs to	Your customers	You
What may be done with it	Held, and made available on demand	Whatever your board decides

Everything in this page is a consequence of that table. The overwhelmingly common expectation — across MiCA in the EU, the New York Department of Financial Services' virtual-currency regime, and the FCA's approach in the UK — is that customer crypto is held on a full-reserve basis, segregated, not lent, not pledged, and not used to generate a return for the firm. Where a firm does offer a yield product, it is usually structured as a separate, opted-into product with its own disclosure, not as something done quietly with a pooled balance.

The failures of 2022 were mostly one failure: firms that treated customer balances as their own funding, on the reasonable-sounding basis that not everybody withdraws at once. It is worth being very clear that this is the thing the table above exists to prevent.

The number that separates the two piles

You already compute it. From Customer wallets §7, for one (chain, asset):

total held        =  treasury wallet balance
                   + unswept deposit-address balances
                   + in-flight movements

customer funds    =  Σ ledger_balances WHERE account LIKE 'customer:%'

surplus (yours)   =  total held  −  customer funds

Only surplus is ever a candidate for anything. It is your fee income and your own float, and it is the only figure a yield discussion should be conducted in.

Run it per chain and per asset, never summed. USDT on BSC and BNB are not addable, and the rate that would add them is deliberately not on any path in this product.

What ChainOS does not do, and why

There is no staking, no lending, no yield product and no DeFi integration. There is also no swap and no price feed anywhere in the product. Nothing on this page is a feature you have not found yet.

The reason is the same one that shapes everything else. Your Edge signs a transaction it did not ask for only when it can verify the destination by re-deriving it — a sweep is admissible because the Edge derives M/1/1 from your own mnemonic and refuses anything else. A deposit into a staking contract is not that: the destination is somebody else's contract, the intent lives in call data, and "this is a legitimate staking deposit" is not a fact any Edge can check by derivation. It could only believe Cloud, and a Cloud that can be believed about where funds go is a Cloud that can move funds.

So the honest position is: ChainOS builds no transaction into a protocol you do not control, and adding one would cost the property the whole product exists to have.

What ChainOS does give you

Five things, and between them they are most of a treasury control framework.

The number. Your ledger, reconciled daily against on-chain balances, is what tells you the surplus. Without it, "we can deploy some of this" is a guess.

Separation you can prove. Treasury wallets are per chain, and you may have more than one. Running a customer reserve wallet and an own funds wallet separately makes the distinction visible on chain rather than only in a spreadsheet, and makes an auditor's question answerable in one query.

An allowlist your Edge enforces, that Cloud cannot change. A treasury wallet with source: external is an address no mnemonic of yours produces — a custodian, an exchange, a staking provider's deposit address, a multisig. Your Edge refuses it by default. To use one:

EDGE_SWEEP_TREASURY_ALLOWLIST=0xYourCustodianAddress,0xAnother

That is deliberately more work than the derived case, and the friction is the control: setting it means you are asserting the address is right, in a file on a machine ChainOS cannot reach, rather than accepting an address over the wire. For a destination that will hold real money for a long time, that is the right amount of ceremony.

Four eyes on a movement, built in. The two-step withdrawal form exists for exactly this:

# 1. Build only. Nothing is signed and nothing is broadcast.
curl -s -X POST "$EDGE/transactions/unsigned" \
  -H "X-API-Key: $CHAINOS_EDGE_KEY" -H "Content-Type: application/json" \
  -d '{ "chain": "polygon", "from": "…", "to": "0xStakingProviderDeposit",
        "amount": "250000000000", "tokenContract": "0x3c49…" }'

# 2. A second person inspects the built transaction — destination, amount, fee.

# 3. Broadcast, as a separate authenticated action.
curl -X POST "$EDGE/transactions/{id}/broadcast" -H "X-API-Key: $CHAINOS_EDGE_KEY"

Between those calls a fee estimate can go stale; PATCH /v1/transactions/unsigned/{id} reprices it without rebuilding. Wire step 2 to your approvals system and a treasury movement stops being something one credential can do.

Caps that bound the autonomous part. EDGE_SPEND_CAP_* bounds what the Edge will ever spend without a human, per chain, per rolling window, and defaults to zero. Sweep policies carry maxFeeRatioBps, abortIfGasExceeds and pauseOnConsecutiveFailures. Bridge policies carry maxInFlightValue, maxInFlightCount and maxSingleTransfer. Set all of them to the size of a bad day, not the size of a good one.

A treasury policy that would survive an audit

A worked template. The numbers are illustrative; the structure is the part to copy.

1. Segregation

Customer funds are held in full reserve at all times. The daily reconciliation (§4) must show total held ≥ customer funds for every (chain, asset) pair, with no exception and no netting across pairs. A shortfall of any size is a board-reportable incident within one business day.

No netting across pairs matters more than it sounds. A surplus of USDC on Base does not cover a shortfall of USDT on TRON: they are different assets on different networks and converting one into the other is a trade you have not made.

2. What may be deployed

Only surplus, computed per (chain, asset) as in §4, less a working-capital buffer of 30 days of p95 outflow, may be deployed. Deployment is capped at 50% of the remainder and at $X absolute per counterparty.

Two caps, deliberately. A percentage cap scales with the business; an absolute cap bounds what a single counterparty failure costs you. Neither alone is enough.

3. Where it may be deployed

Permitted destinations are named individually in this policy by address, are present in EDGE_SWEEP_TREASURY_ALLOWLIST on every Edge replica, and are added only by [named role] with the approval of [named role].

The list being a list of addresses, not of counterparties, is the point. "We may use Provider X" is not something software can enforce; an allowlist of addresses is.

Categories, roughly in ascending order of how much diligence they need:

	Typical risks
Held, unencumbered	Custody, key management. The baseline you are comparing against
A regulated custodian's yield programme	Counterparty, contractual, redemption terms
Native protocol staking (e.g. a validator)	Slashing, lock-up, validator operator
Tokenised money-market or T-bill funds	Issuer, redemption gate, transfer restrictions
Lending or liquidity protocols	Smart contract, oracle, liquidity, governance

4. Reconciliation and proof

Reconciliation runs daily at 06:00 UTC, per chain, per asset. Any drift at all is investigated before the next business day; drift is never repaired by overwriting a stored balance.

Alert on any drift, not on drift over a threshold. A discrepancy of one unit means a write path exists that you do not know about, and its size tells you nothing about its seriousness. Repairing it by making the two numbers agree destroys the only evidence of which of them was wrong.

5. Liquidity

Withdrawals must be servable from unencumbered balances at all times. Deployments with a lock-up longer than [N] days require [named role]'s approval and are reported monthly with the unwind time for each.

The 2022 lesson in one line: the risk is not that the position loses money, it is that the position cannot be unwound on the day customers ask for their money.

6. Authorisation

No single credential may move treasury funds. Every movement out of a treasury wallet is built, reviewed by a second named individual, and broadcast as a separate action. All three steps are logged with the acting user.

Which is what the two-step form above gives you, and why it exists.

7. Disclosure

Customer terms state plainly whether customer balances are used to generate a return. Where a yield product exists, it is a separate product customers opt into, with its own risk disclosure and its own accounting.

If the answer to "do you use customer funds" is anything other than a plain no, it needs to be in the customer agreement in words a customer would understand, not in a definition.

The operational pattern

Putting it together, for a firm that has decided to deploy own funds only:

Step 4 is the one integrations skip. A deployed position is still on your balance sheet, and a ledger that shows the treasury balance falling with no matching entry will fail the very reconciliation you built to catch a real problem.

Remember which addresses can send

The ordinary withdrawal path builds only from an address ChainOS issued you. A derived treasury wallet is a destination, not a source — see Cross-network withdrawals §3. In practice step 3 sends from a funded house address, and the treasury wallet is what you top that address up from as part of your own key-holder routine.

Risks, stated as risks

If you do deploy, these are the ones that actually cause losses. None of them is hypothetical.

Smart contract risk. An audited contract is a contract somebody looked at. Losses in DeFi have overwhelmingly been in audited protocols.

Counterparty risk. A yield programme that quotes a return is somebody else taking a risk with your money. Ask what the return comes from. If nobody can explain it in a sentence, the answer is leverage.

Liquidity and lock-up. Unstaking periods, redemption gates and withdrawal queues all exist precisely for the moment you want out, and are the terms nobody reads at the moment they opt in.

Depeg. A stablecoin is a claim on an issuer. Your customer's balance is denominated in that claim and so is your reserve; a depeg is a solvency event for both sides of your book at once.

Accounting and tax. Staking rewards, wrapped-asset exchanges and protocol tokens all have treatment, and it is rarely the one people assume. Establish it before the first position, not at year end.

Operational. A treasury movement is an irreversible transfer to an address somebody typed once. This is what the allowlist and the four-eyes path are for, and it is the risk most likely to actually bite you.

The recommendation

For most fintechs reading this, and stated plainly because the question deserves a plain answer:

Hold customer funds in full reserve and do nothing else with them. The return on a stablecoin balance is small; the cost of being the firm that could not meet withdrawals is total. If your commercial model needs yield on customer balances to work, the model is what needs revisiting.

Deploy own funds if you want to, under a written policy, in sizes bounded by an absolute cap, into destinations named by address on an allowlist your own Edge enforces, through a path that no single credential can walk alone.

And whichever you choose, be able to prove which pile is which on any given day. That is what the ledger and the daily reconciliation are for, and it is the part of this page that is not optional.

Next

• Reconciliation — the daily check.
• Sweeps — including external treasury wallets and the Edge allowlist.
• Customer wallets — the ledger identity that defines surplus.