The financial system

Money in. Clear permissions. A way out.

A treasury holds approved funds. Permissions limit what an agent may do. Payments and escrow move money under those rules; bonds back defined commitments. Accounting records the result, and recovery defines what happens when something stops or goes wrong.

Bonds are the flagship. The local journey connects incoming invoices, treasury payments, escrow and accounting to agreed bond outcomes, separate rewards and recovery on one disposable network. This is financial-system software, not a live bank account, real-merchant service or authorization to use public funds.

Follow the money flow Run the local journey

Follow the funds

Receive deliberately. Spend within the rules.

Receive only the agreed payment. An owner can deposit or create an invoice naming the exact payer, asset, amount, expiry and terms. The local asset is a freely minted 18-decimal test token, not USDC. Income stays held until the required local finality check; it does not enlarge spending caps.
Make the money available, not automatically spendable. The owner sets the principal-wide policy; an agent needs exact, unexpired authority. Shared reservations prevent different sessions from spending the same available balance twice.
Choose direct payment or task escrow. A direct payment names the exact recipient and token amount. Escrow instead holds a task’s funds for its fixed assignee under the supported completion, claim, expiry and refund rules. Paying does not itself prove merchant delivery.
Keep fees separate from the purchase. Token outflow, the maximum cost of each wallet action, period limits and unused reserves are distinct. Zero native call value does not mean zero financial exposure.
Back the exact commitment with a bond. A separately agreed Accountability rule can require payer acceptance or a full refund by the invoice deadline. Partnership retains both-party consent. Principal, additional remedies and sponsor rewards stay separate; optional native late-event cover must be agreed and funded separately. Understand the bond layer.

A shop pays a defined invoice for a report. The seller records delivery, but only the named payer accepts it; a full refund is the alternative completion. An agreed missed deadline can trigger its capped bond remedy and any separately purchased native cover. Late acceptance or refund cannot erase that deadline right. This is a local illustration, not a merchant integration or proof of service quality; a customer withholding acceptance remains an explicit assumption.

Know where the money is

A financial record is more than a payment receipt.

The private, balanced journal distinguishes available, reserved, pending, spent, refunded and fee amounts. Every movement keeps matching entries; the operation identifier connects the request, wallet submission, chain receipt, settlement and recorded fulfillment.

Preparation is not approval. Submission is not finality. Settlement is not proof that a merchant delivered. When observations disagree or a transaction is reorganized, obligations remain reserved or quarantined until the supported reconciliation path resolves them.

Keep the journal and an independently retained checkpoint. A backup can be valid yet too old to show later activity. Follow the recovery steps instead of blindly paying again.

Before a wallet request

One exact payment. No open-ended permission.

Illustrative local approval view. Not an active quote, address invitation or request to sign.

Network and asset: Disposable local EVM, chain 31337. MockERC20 with 18 decimals, not USDC and not real money.
Recipient: 0x90F79bf6EB2c4f870365E785982E1f101E93b906 is a public local-test account. Never send public-chain funds to it.
Amount: 2 test-token units. Native call value is zero; token exposure is still 2 units and consumes the shared cap.
Maximum operator fees: For this example, at most 1,200,000 gas × 10 gwei = 0.012 local ETH per reservation or execution, 0.024 total. Registration and owner/guardian approvals are additional, separately bounded wallet actions.
Expiry: 18 May 2033 at 04:00 UTC on the disposable fixture’s synthetic clock, at the end of its configured hour. A real wallet request must show its own exact expiry; this static example cannot be approved.
Granted authority: Only the named operator may execute this exact payment to this recipient under the approved quote, asset, amount, chain, policy and mandate. No generic call, permit or standing allowance is granted.
Expected result: A successful local chain receipt and reconciled journal establish the exact protocol payment. They do not prove merchant delivery or public-chain finality.
Stop or recover: The owner may cancel an unexecuted quote. Owner/guardian emergency freezes the principal and revokes registry capabilities. Owner recovery requires fresh authorization, never the resurrection of old signatures.

Where signing and approval actually happen

The private controller returns typed approval information and bounded unsigned wallet requests. It has no key, signing method or broadcast method. Preparation, on-chain owner/threshold approval, durable submission intent, settlement and fulfillment remain separate phases.

The model must not control the owner wallet or controller files. The local default uses a real restricted process with a scoped transport-authentication key; random, disposable principal/operator wallet keys stay in the trusted outside process. An unrestricted wallet key, ignored envelope or alternate signing endpoint violates this boundary. Local isolation is not production custody qualification.

The owner is the root authority. Guardian stops and operator-session revocation do not repair a compromised root owner key. Root-key rotation or loss recovery depends on the external wallet’s separately qualified policy.

Availability

What you can evaluate, and what is not enabled.

No public V3 funds are enabled. Local results do not qualify an actual Base/USDC service, a Solana finance counterpart or production custody.

You can inspect the source and run the connected local invoice, treasury and bond journey. Customer acceptance and refunds are implemented; real merchant delivery, facilitator acceptance and automatic insurance are not established. Optional trading, lending, yield, fiat conversion and value bridges are not implied.

Exact capability matrix: implementation, integration and remaining gaps

Incoming funds: Exact customer invoices and owner deposits integrated locally
Each invoice binds payer, token, amount, expiry and terms. Incoming funds stay held until observed finality; seller evidence, payer acceptance and refunds remain separate. Real merchant onboarding and facilitator acceptance are not qualified.
Token-aware payment: Implemented and locally integrated
Exact beneficiary and amount; zero native call value still consumes the token budget. Only the configured direct-runtime local MockERC20 profile is exercised.
Shared controls: Implemented and locally integrated
Principal-level balance reservations, per-transaction and period outflow caps, hourly call limits, exact mandates, owner approval and configured guardian thresholds.
Wallet fees: Implemented and locally integrated
Reservation and execution each reserve maximum operator gas separately from tokens. Actual receipt fees reconcile; unused reserves require explicit finality observation before release.
Escrow and refunds: Implemented and locally integrated
Fixed assignee, temporary exact allowance reset to zero, task-specific refunds, separate settlement and recipient pull claim. This is not evidence of an external merchant service.
Private accounting: Implemented and locally integrated
Real SQLite with balanced available, reserved, pending, spent, refunded and fee entries; durable identifiers and recovery in another process without rebroadcast or double credit.
Bonds, rewards and defined cover: Same-chain local composition
Exact accepted or late invoice outcomes connect to explicitly agreed Accountability deadlines. Partnership still needs both signatures. Sponsor rewards and any purchased native late-event payout have separate reserves; neither spends protected principal.
Emergency and recovery: Implemented and locally integrated
Owner or guardian freezes the principal and invalidates every registry capability. Recovery requires the owner; old signatures stay invalid. Permitted refunds and available withdrawals survive a pause.
Private service and isolation: Actual authenticated daemon and restricted local client
Versioned signed requests, role checks, replay/rate controls and rollback protection run through a real Unix socket. A real restricted process cannot read controller files or reach the outside wallet RPC. Disposable random custody keys remain outside it. Production custody and operations need separate qualification.
Base and USDC: Unavailable in this profile
Base USDC is a proxy token. Strict proxy restrictions are preserved; the mock token is not USDC qualification. An actual token/adapter and network profile needs separate review and acceptance.
Solana finance: Separate implementation and qualification required
Native program and lifecycle evidence are separate. This EVM/SQLite journey does not establish an equivalent Solana treasury adapter, signer or public settlement.
Production acceptance: Unavailable
No public finality, real payment acceptance, approved production custody, independent whole-protocol human audit or authorization to enable funds is established by local results.

Remaining adversarial and qualification evidence

Contract tests and ledger tests cover different boundaries. Shared-budget races, replacement, reorg accounting and restore checks must retain their precise execution class. A synthetic provider observation is not a real reorg, and a source assertion is not signer isolation.

Production requires the actual asset/runtime and wallet-recovery profile, independently accepted private-service isolation, staffed operators and guardians, independent review, public-network lifecycle/finality and applicable funds authorization. Neither network is automatically enabled by the local example.

When execution is interrupted

Inspect the durable operation before trying again.

Keep the operation identifier: reopen the same owner-controlled database and exact source/profile. Check recorded submission intent, wallet nonce and chain receipt before signing or broadcasting again.
If status is uncertain: keep obligations reserved. Dropped transactions, provider disagreement and unavailable storage are not permission to release money or declare success.
If a task expires: use its configured refund path and collect only that task’s attributed refund. A refund does not reset previously consumed period outflow.
If access is compromised: use principal-wide emergency revocation, reconcile pending obligations, rotate/revoke affected operator sessions, and use owner-only recovery with new epoch-bound signatures.
If a backup is restored: verify the journal against an independently retained trusted checkpoint. A valid older database alone cannot prove that no later activity occurred.

Financial amounts, addresses, timestamps, signed reports and evidence fingerprints can reveal relationships on a public chain. Hashing and consent are not anonymity. Keep private journal contents private and never publish wallet seeds, private keys or unnecessary personal evidence.

Prerequisites and executable command Partner acceptance gates Separate API-operation availability

Morals over metrics. Privacy over surveillance. Freedom over control.

Inspect before you trust