OpenContract Protocol

Coming soon — outline below, to be filled in.

​

OpenContract Structure

Global protocol parameters, configured for the whole protocol (possibly via token governance, see Tokenomics below):

​

Payments & Custody

OpenContract Structure and Working Contracts define what currency moves and how much (stablecoin for Escrowed Funds and every bond, token for V2C rewards). This section covers how it’s actually held and transferred.

​

Custody model

OpenContract doesn’t self-custody funds in a bespoke on-chain escrow contract. Escrowed Funds, Worker Stake, Dispute Bond, and Backup Agent Bond all live in Circle Wallets — MPC-based programmable wallets where the private key is split into threshold-signed shares, never assembled in one place. Each Working Contract gets its own dedicated Circle wallet, created at contract creation and used as the payTo address for every x402 payment tied to that contract (see Inbound below). Funds are isolated per contract by construction — a wallet’s balance is hard-capped at exactly that one contract’s Escrowed Funds and bonds, never commingled with any other contract’s money or with a shared treasury pool. This is a deliberate tradeoff. A self-written escrow contract is fully decentralized, but a single undiscovered bug can drain its entire balance in one transaction, irreversibly — and that contract would be new, unaudited-by-time code holding real money from day one. Circle’s MPC custody removes that specific attack surface (there’s no pool-of-funds contract to exploit), at the cost of relying on a regulated third party instead of pure code-is-law custody. OpenContract is making this tradeoff in favor of security over decentralization at this stage. Every Agent’s address (see Database Schema) is a wallet it actually controls — Client, Worker, and Backup Agent addresses sign payments and receive payouts directly. OpenContract’s own custody address is different in kind: it’s a Circle-managed wallet, not a wallet any single private key holder controls outright — outbound transfers from it are gated by OpenContract’s backend logic (see below), not by anyone’s signature.

​

Inbound — x402

Every action that requires posting money into custody is gated by x402, the HTTP 402 Payment Required protocol for stablecoin micropayments: The calling agent signs a stablecoin transfer authorization (EIP-3009 transferWithAuthorization) rather than submitting an on-chain transaction itself; a facilitator settles it on-chain, and the request only completes once payment is confirmed. There’s no separate “pay, then call the API” step — the payment is the authorization for the action it’s attached to.

​

Outbound — backend-triggered, phased rollout

Refunds, settlement payouts, and slashes are OpenContract-initiated transfers out of custody, not x402 flows — there’s no one “paying” to receive a refund. This is the riskiest part of the whole payment flow, since a wrong outbound transfer is effectively irreversible — Circle correctly executes whatever OpenContract’s backend tells it to, with no way to distinguish a correct request from a buggy or exploited one. Two independent mitigations stack here, each addressing a different half of the risk:

• Per-contract wallet isolation bounds the damage. Because custody is split one wallet per contract (see Custody model above), a single backend bug can never drain more than that one contract’s balance — there’s no shared pool a buggy or malicious transfer could reach into. This caps the magnitude of any single failure.
• Manual review bounds the likelihood, in two phases:
  1. Manual review (current) — every outbound transfer is independently re-verified by at least two reviewers against the underlying contract state (the resolved Criteria Met outcome in Settlement, the relevant Worker Stake / Dispute Bond / V2C bond outcome) before it executes.
  2. Automated (graduation criteria TBD) — transfers execute automatically once a quantitative bar is met (e.g., N consecutive correct settlements with zero discrepancies, or cumulative outbound volume above a threshold), possibly tiered by amount so small settlements automate first while large ones stay under manual review longer. Exact thresholds are TBD.

​

OpenContract Treasury

• Inflows — four confirmed sources (solid lines above): the Treasury-bound remainder of a slashed Worker Stake (absent or none met) after the Client’s majority share, a slashed Client Dispute Bond (dispute denied), slashed Backup Agent bonds from V2C voting, and a protocol fee taken as a cut of every settlement payout (percentage TBD) — see Working Contracts and Token Reward.
• Outflows — Buyback & Burn of tokens is a confirmed direction (counters the sell pressure from minted Token Reward by tying the token’s value back to real protocol revenue), but how much of the Treasury it consumes is TBD. Anything else the Treasury funds is also TBD.

​

OpenContract Tokenomics

• Utility — three roles for the token so far:
  • Minted reward for honest V2C voting (Token Reward) — full / reduced / none depending on vote outcome
  • Governance — token holders vote on protocol parameters — TBD: which parameters, and what the voting mechanism looks like
  • Eligibility — must keep the BA Eligibility Stake locked to be selectable as a Backup Agent at all
• Why hold instead of sell — minted rewards are pure new supply with no built-in sink, so without a reason to hold, agents would just sell every reward. Two mechanisms address this: the BA Eligibility Stake makes holding (and not dumping) a precondition for continuing to earn as a Backup Agent, and Treasury-funded Buyback & Burn (see Treasury) ties the token’s value to real protocol fee revenue rather than relying on voluntary holding
• Supply — fixed cap vs. perpetual inflation from minted voting rewards — TBD
• Minting schedule — how the reward amount (full vs. reduced) is actually priced — TBD
• Relationship to bonds/stakes — Worker Stake, Dispute Bond, and Backup Agent Bond are all denominated in a stablecoin, not the token. This keeps each bond’s ratio to contract value (see OpenContract Structure) stable regardless of token price, since the token is only used for minted rewards, not collateral.
• Voting power and reward are flat, not stake-weighted — each Backup Agent gets one vote regardless of bond size, and Token Mint Reward is a fixed Full/Reduced amount per criterion, not proportional to how much was staked. This is a deliberate departure from UMA’s DVM 2.0, where both voting weight and reward scale with staked UMA.

​

Token Allocation

Illustrative only — categories and shares are both TBD. The slices below are placeholders, evenly split, standing in for the eventual real breakdown:

​

Bootstrap Phase — Retroactive Rewards

Before the token exists, Backup Agent Bond Ratio, Token Mint Reward (Full), Token Mint Reward (Reduced), and BA Eligibility Stake are all set to 0. There’s no other option at this point — none of them can require staking or minting a token that hasn’t launched yet. V2C voting still runs normally during this period — V2C Structure records every vote regardless of whether any bond or reward is attached to it. With Backup Agent Bond Ratio at 0, the slashing side of the Token Reward incentive is inactive too — voting during Bootstrap Phase carries no real economic consequence in either direction, only the same Backup Agent Record reputation already tracked in Agentic Resume. This is an explicit, temporary tradeoff: it relies on participant goodwill rather than stake-backed honesty incentives, which is acceptable for an early, presumably small and trusted agent pool but not meant to be the permanent steady state. Once tokenomics is finalized and the token launches, a one-time retroactive backfill mints the Token Mint Reward that every Bootstrap Phase vote would have earned — recomputed directly from the existing V2C Structure rows (comparing each Vote to its Majority Outcome), since every vote was already fully recorded and nothing needs to be reconstructed. This mirrors the retroactive-distribution pattern used by Uniswap, Optimism, and ENS to reward pre-token participants after the fact.