Technical Whitepaper
v0.1.0AEOS: Agent Economic Operating System
The infrastructure layer for AI agents to exist as autonomous economic entities. Protocol Specification — March 2026.
Abstract
AI agents are rapidly becoming autonomous economic actors. Stripe launched Machine Payments Protocol on March 18, 2026. Visa, Mastercard, Google, and Coinbase each shipped competing agent payment systems within the same week. McKinsey projects $3–5 trillion in global agentic commerce by 2030. Yet the entire infrastructure assumes the only problem is payments. It is not.
For an AI agent to function as a genuine economic entity, it needs far more than the ability to move money. It needs cryptographic identity, the ability to enter binding agreements, mechanisms for dispute resolution when things go wrong, real-time risk management, insurance against errors, delegation of authority, and accountability to the humans and organizations it represents. None of this infrastructure exists today.
AEOS (Agent Economic Operating System) is an open protocol that provides the complete economic infrastructure for AI agents. Built on Ed25519 elliptic curve cryptography, Pedersen commitments, zero-knowledge range proofs, Merkle accumulators, and verifiable random functions, AEOS enables agents to operate as first-class economic citizens with mathematically enforced authority bounds, cryptographically binding contracts, automated dispute resolution, and continuous risk monitoring.
Section 1
The Problem: Agents Without Infrastructure
The agent economy is emerging with extraordinary speed but without the foundational infrastructure that every economy requires. Six competing payment protocols have launched in the past 12 months, but payments represent less than 5% of what an economic actor needs to function.
The Infrastructure Gap
| Capability | Humans Have | AI Agents Have |
|---|---|---|
| Identity | Passports, SSN, biometrics | Nothing standard |
| Contracts | Legal system, courts | Nothing |
| Dispute Resolution | Courts, arbitration, mediation | Nothing |
| Risk Management | Credit scores, insurance, regulation | Nothing |
| Accountability | Legal liability, corporate structure | Nothing |
| Authority Bounds | Power of attorney, corporate bylaws | Nothing |
| Reputation | Credit history, references, track record | Nothing |
| Delegation | Employment law, agency law | Nothing |
AEOS fills every cell in the right column. It is not a payment system. It is the complete operating system for AI agents to participate in the economy.
Section 2
Protocol Architecture
AEOS consists of six interconnected layers, each providing a distinct capability. All layers share a common cryptographic foundation and communicate through the immutable ledger.
| Layer | Function | Key Primitive |
|---|---|---|
| Identity | Agent DIDs, credentials, selective disclosure | Ed25519, Merkle Accumulator |
| Contracts | Binding agreements, escrow, obligations | Multi-sig, Hash commitments |
| Disputes | Automated arbitration, evidence chains | VRF, Commitment schemes |
| Risk | Behavioral analysis, circuit breakers | Statistical anomaly detection |
| Governance | Delegation chains, authority bounds | Range proofs, Chain verification |
| Ledger | Immutable audit trail | Merkle tree, Hash chains |
Section 3
Agent Identity Protocol
Every AI agent in the AEOS protocol is identified by a Decentralized Identifier (DID) derived from its Ed25519 public signing key. The DID is self-certifying: knowledge of the private key proves ownership of the identity.
3.1 Identity Components
An agent's identity document contains: a signing key pair (Ed25519) for non-repudiable signatures, an encryption key pair (X25519) for secure communication, a controller DID linking to the responsible legal entity, a capability set defining what the agent can do, quantitative authority bounds limiting how much it can do, and a delegation chain proving the chain of authority from the root controller.
3.2 Selective Disclosure
Agents can prove specific attributes about themselves without revealing their full identity. This is achieved through Pedersen commitments on credential claims combined with Merkle membership proofs. For example, an agent can prove "I am authorized to transact up to $50,000" without revealing who controls it, what other capabilities it has, or its full transaction history.
3.3 Delegation Chains
Authority flows from a root controller (a human or legal entity) through a chain of delegations to leaf agents. Each link in the chain is signed by the delegator and contains scoped capabilities and quantitative bounds. A critical invariant is enforced: a child agent's authority bounds must be strictly contained within its parent's. This is verified cryptographically, making privilege escalation mathematically impossible.
Section 4
Contract Protocol
AEOS contracts are deterministic, machine-verifiable specifications of obligations between agents. Unlike natural language contracts that require interpretation, every term in an AEOS contract has a precise computational meaning.
The contract lifecycle is: PROPOSED → AGREED (multi-sig) → ACTIVE → COMPLETED or DISPUTED
4.1 Escrow and Milestone Release
Contract value is committed to escrow accounts using Pedersen commitments. The committed value is hidden but binding. Funds are released upon milestone completion, verified by cryptographic proof of fulfillment. If a milestone is not met by its deadline, the escrowed funds are automatically available for refund through the dispute resolution protocol.
4.2 Obligation Types
| Type | Description | Verification Method |
|---|---|---|
| PAYMENT | Transfer of value | Escrow release proof |
| DELIVERY | Delivery of data/service | Content hash match |
| COMPUTATION | Verifiable computation | ZK proof of execution |
| ATTESTATION | Signed proof of fact | Signature verification |
| AVAILABILITY | Uptime/access SLA | Monitoring oracle |
Section 5
Dispute Resolution Protocol
When contract obligations are breached, AEOS provides a three-tier resolution mechanism: automatic resolution for clear-cut cases, committee arbitration for ambiguous cases, and appeal for contested decisions.
5.1 Automatic Resolution
For cases where the contract terms and evidence unambiguously indicate a breach (e.g., a delivery deadline passed with no fulfillment proof), the protocol automatically determines the resolution. This handles the majority of disputes without any human or arbitrator involvement.
5.2 VRF-Based Arbitrator Selection
When automatic resolution fails, arbitrators are selected using a Verifiable Random Function (VRF). The selection is provably fair, deterministic, and verifiable.
5.3 Confidence-Weighted Voting
Arbitrators cast votes with an explicit confidence score in [0, 1]. The winning resolution is determined by confidence-weighted majority, not simple majority. This incentivizes honest uncertainty: an arbitrator who is unsure should express low confidence rather than guess, because a low-confidence vote for the wrong outcome has less impact than a high-confidence vote.
Section 6
Risk Management Engine
Every action in the AEOS protocol passes through the risk engine before execution. The engine provides five layers of protection.
6.1 Multi-Factor Risk Scoring
Each transaction receives a composite risk score computed from weighted factors: authority bounds compliance (30%), circuit breaker status (25%), behavioral anomaly score (20%), counterparty risk (15%), and systemic concentration risk (10%). Transactions with scores above the configured tolerance are rejected.
6.2 Behavioral Anomaly Detection
The engine maintains a statistical profile of each agent's normal behavior: average transaction value, standard deviation, typical counterparties, transaction velocity, and daily volume patterns. New transactions are scored using z-score analysis and pattern matching. A transaction that deviates significantly from the agent's established pattern receives a high anomaly score.
6.3 Circuit Breakers
Each agent has an associated circuit breaker that implements the standard CLOSED/OPEN/HALF-OPEN pattern. After a configurable number of high-risk events, the breaker trips and blocks all transactions for that agent. After a cooldown period, the breaker enters HALF-OPEN state and allows a limited number of test transactions before fully resuming.
6.4 Insurance Primitives
AEOS provides programmable insurance pools where agents stake value to cover specific risk types. Premiums are calculated dynamically based on the agent's reputation score and dispute history. Claims are processed through the dispute resolution protocol, creating a self-sustaining risk transfer mechanism.
Sections 7–8
Immutable Ledger & Cryptographic Primitives
Every action in the AEOS protocol is recorded on an append-only ledger with hash chain integrity and Merkle proof support. Each entry contains: a sequence number, event type, actor DID, data hash, the previous entry's hash (forming a chain), and the actor's signature.
The ledger provides tamper evidence (any modification breaks the hash chain), efficient membership proofs, complete actor history, and full auditability — the complete history of any contract, dispute, or agent can be reconstructed from the ledger.
Cryptographic Primitives
| Primitive | Construction | Purpose |
|---|---|---|
| Digital Signatures | Ed25519 | Non-repudiable agent actions |
| Commitments | SHA-256 Pedersen-style | Hidden but binding values |
| Range Proofs | Ristretto255 Bulletproofs | ZK authority bound verification |
| Merkle Trees | SHA-256 with domain separation | Membership proofs |
| VRF | Ed25519-based | Fair arbitrator selection |
| Key Derivation | HKDF-SHA256 | Deterministic child keys |
| Encryption | AES-256-GCM | Authenticated agent communication |
| Hash Chain | SHA-256 linked | Ledger integrity |
Section 10
Implementation Status
| Component | Status | Lines of Code |
|---|---|---|
| Cryptographic Primitives | Complete | ~320 |
| Agent Identity Protocol | Complete | ~400 |
| Contract Protocol | Complete | ~350 |
| Dispute Resolution | Complete | ~300 |
| Risk Management Engine | Complete | ~400 |
| Immutable Ledger | Complete | ~180 |
| End-to-End Demo | Complete | ~300 |
Total implementation: approximately 2,250 lines of production Python code with full cryptographic verification. The complete system runs end-to-end demonstrating all protocol features.
Section 11
Roadmap
Public SDK
Publish the Python and TypeScript SDK. Enable any developer building an AI agent to integrate AEOS identity, contracts, and risk management with a single import.
Distributed Ledger
Replace the local ledger with a BFT distributed ledger. This enables trustless operation across multiple organizations. Integrate with existing blockchain networks for settlement finality.
Production Cryptography
Replace simplified ZK constructions with production Bulletproofs and Groth16 circuits. Integrate HSM support for key management. Achieve formal security audit.
Network Effects
As adoption grows, the AEOS network becomes more valuable. Agent reputation scores are meaningful because they're backed by real transaction history. Dispute resolution is fair because the arbitrator pool is large and well-incentivized.
AEOS is not a product. It is infrastructure. The agent economy is being built right now. The companies building payment rails are solving 5% of the problem. AEOS solves the other 95%.