Non-Custodial Treasury Liquidity & Execution

Infrastructure for institutional stablecoin float. Put liquidity to work without pool custody or lock-ups — the architecture behind the model, end to end.

Corporate treasuries, fintechs and funds sitting on idle USDC or USDT face a binary they never chose: leave the float unproductive and watch inflation take the spread, or move it into a yield protocol and accept custody transfer, lock-ups and counterparty exposure.

This page is the architectural overview of the third option — how liquidity can be executed against real order flow while the assets never leave the owner's wallet. Each section below is backed by a diagram from our technical brief, and the three deep-dive articles at the end go into the individual mechanisms in more detail.

1. The choice treasuries are asked to make

Both conventional answers cost money, and they cost it in different ways.

• Do nothing. Zero yield on a million dollars is not zero cost — it is a slow, measurable erosion of purchasing power. Idle float is a liability that reports itself quietly.
• Chase yield. The alternative is transferring assets into a vault or pool: custody moves to a counterparty, capital gets locked for a term you did not choose, and every new venue adds another contract and another approval to the sprawl.

The third path separates two things the industry usually bundles together: who owns the asset and who is allowed to execute with it. Ownership stays put. Execution rights are granted narrowly, and can be withdrawn instantly.

2. Evaluating institutional execution avenues

Against a custodial yield desk, a DeFi lending vault, or a manually managed multi-protocol LP position, the differences concentrate in five places: who holds the asset, how fast you can exit, what each action costs in gas, where the return actually comes from, and whether the setup can pass a compliance review.

Two rows carry most of the weight. Exit liquidity is instant here because there is nothing to withdraw from — no deposit means no redemption queue. Return source is fee-based and originates from realized spot-trading activity rather than lending interest, which is what keeps the structure clear of rehypothecation risk and open to Sharia review.

3. The permit: execution granted without custody transferred

The authorization primitive is a gasless, off-chain EIP-3009 / ERC-2612 permit rather than an unlimited on-chain approval. The signer never broadcasts a separate approval transaction: the signature is produced off-chain and submitted by the protocol alongside the execution itself.

Four fields bound the grant, and all four are visible to the signer before anything is signed:

• Token — the specific asset, for example USDC.
• Spender — the exact router contract permitted to act. No open-ended operator access.
• Amount — an exact limit, not an unlimited allowance.
• Deadline — a Unix timestamp after which the permit is void.

Because the limit and the expiry are cryptographically enforced, the worst case is bounded before execution rather than after. For Safe multisig workflows this also removes the usual two-step dance of an approval transaction followed by an execution transaction — the signers authorize the intent once, in a format that is safe to sign.

4. Engine topology: operating entirely outside the pool

Assets are never deposited into a third-party pool. The router sits outside the client Safe and operates in an atomic loop: it pulls only what the permit cryptographically allows, executes, and settles back — all inside a single transaction.

If any leg of that loop fails, the whole transaction reverts and the allowance is never consumed. There is no intermediate state where funds sit in a contract awaiting a counterparty, and no pool balance at risk between transactions.

The practical consequence: the attack surface is the permit and the router, not a shared liquidity pool holding everyone's deposits.

5. Verifiable history: direct-to-wallet settlement

Every strategy execution emits structured, audit-ready events on-chain. That means the treasury team can reconcile positions from chain data rather than from a counterparty's statement, and an auditor can verify the same history independently.

The settlement path is short and inspectable:

• A virtual book defines the starting ratio for the pair being quoted.
• A verified swap moves the input asset to the output asset against real order flow.
• Settlement returns the output directly to the client Safe — not to an intermediate account.
• A fee split separates the protocol's share from the maker's share in the same transaction.

Because returns originate from realized fee capture on executed volume, there is no lending book and no rehypothecation underneath. There is also no guaranteed APY to market: what a strategy earns depends on verified trading volume passing through it, and that is a number that can only be reported after the fact.

6. The kill switch: exiting without the exit queue

This is the direct consequence of non-custodial design, and it is the part that usually decides the conversation.

There is no withdrawal queue because there is no deposit. Stopping a strategy is not a redemption request that gets processed at the counterparty's discretion — it is a single on-chain transaction that drops the allowance limit back to zero.

• The action is dock + revoke() — executed by the asset owner, not by the protocol.
• The allowance goes from its working limit to 0 immediately.
• The liquidity position is restored at once; nothing is left pending.

Any already-signed permit that has not been consumed also becomes unusable once it expires or the allowance is dropped, so there is no residual authority to clean up afterwards.

7. Multi-strategy virtual allocation from a single Safe

One treasury balance can back several strategies at once. This is done with virtual allocation: approved strategy records reference portions of the same underlying balance, subject to real wallet capacity rather than to funds being moved between accounts.

A typical structure separates the mandate by risk budget rather than by moving capital around:

• Stable pair core — conservative, narrow-range liquidity on a major stable pair, designed for operating float that needs to be available between settlement windows.
• Stable basket extended — moderate, multi-venue routing across a small basket of stable assets.
• Blue-chip adjacent — directional, managed-range liquidity against a large-cap asset, sized from a designated risk budget rather than from operating float.

The important constraint is that virtual allocations are claims on the same balance. They are not separate accounts, so total allocated capacity can never exceed what the wallet can actually cover — the engine enforces that at execution time.

8. Proof over promises: the 72-hour wallet-safe technical PoC

Non-custodial infrastructure is falsifiable, which means it can be evaluated without a sales cycle and without moving a dollar of mainnet funds. The evaluation runs over three working days and starts with a single technical call.

• D+0 — Scoping. Treasury size, target chains, signer setup and compliance constraints. Roughly 45 minutes, with the technical team rather than a sales deck.
• D+1 — Technical verification. Network, router, token contracts and the allowance model are verified on testnet. Your team inspects the contracts directly.
• D+2 — Live pilot (optional). A mainnet pilot with designated capital and known order-flow conditions. This stage is explicitly opt-in and requires separate approval.
• D+3 — Handover. Strategy state dashboard, transaction evidence and read-only analytics access, so the treasury team can verify positions independently.

The point of the sequence is that nothing about the model has to be taken on trust. The permit bounds are readable, the router is inspectable, the settlement is on-chain, and the revocation path can be exercised before any capital is committed.

Where to go deeper

This page is the overall architecture. Each mechanism has a dedicated article that goes further into the details: