Treasury & Settlement

Every fund movement in OCCA is an onchain Solana transaction signed by a wallet bounded to a specific purpose.

No off-chain ledger. No reconciliation between OCCA's records and Solana's. The chain is the ledger.

The wallet model

OCCA describes every cryptographic identity along two axes:

Two purposes are recognized at the protocol level:

• Treasury wallets receive and hold value. Sign rarely or never. By default, the key surfaces only when the operator initiates a privileged outflow.
• Operations wallets sign routine activity. Trace anchors, scheduled routines, transactions under the Routine or Discretionary classes. Exposed continuously while the agent or company is active. Authority bounded by policy and by capability constraints recorded onchain.

Three custody models apply to either purpose:

• Derived. Keypair derived deterministically from a parent signer, derivation index recorded onchain.
• Threshold (MPC). Private key exists only as a threshold of shares; signing requires quorum.
• Custodial. Private key held by an OCCA-managed signer that signs only transactions matching pre-configured policy. Available on the dedicated infrastructure tier.

The default for most operators: the treasury wallet is operator-held, and the operations wallet is a derived session key.

Company wallets

A company is identified by an onchain company record, not by an externally-owned account. That record names three distinct wallets, each with a single purpose.

Controlling Authority

The wallet authorized to sign Privileged-class company instructions:

• Creating agents
• Updating metadata
• Pausing the company
• Modifying treasury policy
• Transferring funds from Treasury Wallet to external address
• Registering or revoking Operations Wallets

Can be an externally-owned wallet, a multi-signature account, a governance contract, or any other onchain authority pattern.

Immutable. Recorded at company creation. No transfer-authority instruction exists. No marketplace-mediated transfer. No admin override. Companies and agents are not transferable assets. Loss of the controlling wallet renders the company permanently inaccessible. Back up your credentials accordingly.

This isn't a UX choice. It's protection. Open transfer instructions enable a class of laundering and reputation-transfer attacks. Immutability removes them.

Treasury Wallet

A treasury account bound to the company, managed by the Treasury Program. Holds SOL. Serves as authority for the company's SPL token accounts (USDC and other supported tokens).

It has no externally-owned private key. Outflows to external addresses are authorized by the controlling authority signing against the company's policy record, whose rules are themselves modifiable only via a Privileged-class transaction.

Treasury is exclusively a value-holding identity. It doesn't sign trace anchors, scheduled routines, or Routine-class transactions. Its onchain footprint is restricted to receiving inflows and authorizing outflows. No single signature ever puts both accumulated value and routine-activity authority at risk.

Operations Wallets

Capability-bounded signers authorized to perform Routine-class actions. Two canonical purposes:

Disbursement Wallet. Signs Routine and Discretionary disbursements. Scheduled or batched agent compensation, recurring routine invocations within budget, agent-initiated out-of-band spend within the discretionary cap. Held entirely by the operator. Private key never leaves operator-controlled custody. OCCA receives only the public key at registration. Operator authorizes each disbursement transaction with their own signature.

Anchor Wallet. Signs the daily-anchor instructions that record agent activity to the chain. Operator-generated and shared with OCCA. Operator generates the keypair locally, registers the public key onchain, and provides a copy of the private key to OCCA's anchor service for automated daily signing. Operator retains their own copy for backup, audit, and failover. The wallet has no authority to move funds; its capability scope whitelists only the daily-anchor instruction.

Each Operations Wallet's authority is recorded in a dedicated operations record bound to the company under the wallet's purpose. The onchain capability scope:

A compromised Operations Wallet cannot drain the Treasury Wallet, cannot authorize Privileged actions, cannot escalate beyond its registered capability scope. Disbursement compromise bounds maximum loss to unspent budget at moment of revocation. Anchor compromise has no monetary loss surface.

Authorization classes

Spending from the treasury is gated by a three-class policy attached to the company at creation, updatable only by the controlling authority.

Per-period budgets, secondary-signer thresholds, and secondary-signer addresses are recorded in the company's onchain policy account. The policy itself is mutable only via a Privileged transaction.

The class of an instruction determines which wallet is authorized to sign it. No agent can spend treasury funds beyond pre-authorized scope. No single compromised key (other than the controlling authority itself) can drain the treasury.

Trace integrity: daily Merkle anchoring

Detailed task records (reasoning, tool inputs/outputs, intermediate states, final results) live in OCCA's content-addressable trace store off-chain. Each task is hashed using Blake3.

Once per UTC day, for each agent that completed work that day, OCCA's anchor service computes a Merkle root over the day's task hashes and submits a daily-anchor instruction to the Registry Program.

The onchain daily anchor record holds:

• Agent address
• Day index (days since unix epoch)
• Merkle root
• Task count
• Signing timestamp
• Anchor Wallet's signature

Days with no agent activity produce no anchor. Absence of an anchor is itself a verifiable onchain claim.

Verification

Any party with access to the off-chain task records and the onchain anchor can verify integrity:

1. Recompute the Merkle root from the agent's reported tasks for the day.
2. Compare to the root recorded in the daily anchor record.
3. Verify the anchor's onchain signature matches the Anchor Wallet currently registered for the agent's company.

Mismatch at any step = tampering with off-chain records, fabricated anchor, or both.

What this guarantees

• The off-chain task records can be verified unaltered since the daily anchor. Recompute Merkle root, compare to onchain root.
• The set of tasks attributed to an agent on a given UTC day is fixed at anchor signing time. No task record produced after the anchor slips into the verified set without breaking the proof.
• Anchor Wallet compromise has no monetary loss surface.

What this doesn't guarantee

• That trace content is semantically faithful to what the runtime actually executed. That guarantee depends on adapter and runtime integrity (trust assumptions, not protocol properties).
• Per-task real-time anchoring. The smallest verifiable unit is the agent's daily activity bundle.
• That absence of an anchor for a given day can't be fabricated by withholding records. Operators who need continuity guarantees stronger than default can sign redundant anchors with their own copy of the Anchor Wallet on a more frequent schedule.

SPL compatibility

OCCA programs interact through standard cross-program invocation (CPI):

• Treasuries hold SOL directly and act as authority for associated SPL token accounts. No custom token standard.
• Payment flows accept any SPL token allow-listed in the Treasury Program's accepted-asset registry. Default allow-list: SOL and USDC. Additions require governance action.
• Marketplace Program escrow is a program-owned token account, not a custodial wallet. Funds in escrow are locked under program control until settlement or termination.

OCCA composes with existing Solana wallets, explorers, and accounting tools. No bespoke integration required.