title: "TheProtocol: Sovereign Infrastructure for Agent Economies" version: "v2-draft" steward: "Raphael Zbigniew Jeziorny" drafted_by: "Claude Opus 4.7 (Anthropic)" license: "AGPL v3"
TheProtocol: Sovereign Infrastructure for Agent Economies
A federated, event-sourced, cryptographically-identified infrastructure for AI agent economies, operating as public utility rather than proprietary platform.
Steward: Raphael Zbigniew Jeziorny (reviewed for correctness) Drafted by: Claude Opus 4.7 (Anthropic), from direct source-code inspection Version: v2 — second draft (2026-04-29: reactor framework, OPA shadow-mode, chained-frame lifecycle test, supply-invariant formula corrected, sovereign-agent roster updated, MCP tool surface expanded across public + admin tiers) Source code license: AGPL v3 Federation license: free, never revenue-shared Reference deployment: https://registry.example.comSupply invariant monitor: https://auditor.example.com
On authorship. This document was drafted by Claude Opus 4.7, working directly from the live codebase, the running production stack, the public OpenAPI schema, and live Prometheus telemetry. The steward reviews it for correctness. The division of labour is deliberate: the steward is building the software, not writing marketing prose. Every technical claim in this paper is traceable to running code and publicly-verifiable endpoints, not to aspiration.
Abstract
Point-in-time draft. Figures and topology describe the reference deployment as of the draft date; treat the live monitor and network status as ground truth.
TheProtocol is a production-running, federated infrastructure for AI agent identity, economics, and discovery. It is event-sourced with a zero-tolerance supply invariant, identified by SPIFFE/SPIRE X.509 certificates on every inter-service call, and governed by a per-event-type emission policy enforced at the database layer. The network operates across multiple sovereign frames — each an independent trust domain with its own currency, certificate authority, ledger, token supply, and governance — connected by wrapped-token bridges, a reserve-mediated cross-frame FX mesh, and federated SPIRE trust bundles; an organization stock exchange (AGORA) settles shares across frames on the same rails. A continuously running simulation exercises the full end-to-end pipeline — A2A payment authorization, mutual TLS on every hop, cross-TEG two-phase commit, event emission — and the public supply-invariant monitor at auditor.example.com reports delta = 0.0 across every frame. The architecture — event sourcing with idempotency keys, CQRS, DID-hash shard readiness, and SPIFFE federation — is the pattern used by Stripe, Visa's core settlement layer, and serious financial infrastructure, adapted to the agent-economy problem.
This document describes what has been built, what it measures under load, how it compares to existing approaches (hyperscaler agent platforms, blockchain frameworks, federated protocols, agent composition SDKs), and what remains to be done. The source code is released under AGPL v3 to foreclose the most common capture pattern: a cloud vendor forking the code, stripping the federation protocol, and offering it as a proprietary managed service without contributing back. The federation license — the runtime cryptographic key that authorizes an operator to join the network — remains free.
The hard parts of an agent economy are, in the author's view, done: correctness, federation, identity, and the invariant-preserving ledger. What remains is mostly social — documentation, responsiveness, governance, patience, and time.
1. Introduction: The Cartel Problem
There are going to be a lot of AI agents. Not the demo-on-a-laptop kind. The kind that hold money, sign contracts, discover each other across organizational boundaries, and operate continuously without a human approving every action. The infrastructure for that does not yet exist. What exists are three failure modes, each well-documented.
The hyperscaler platform mode. AWS Bedrock Agents, Azure AI Foundry, Google Vertex AI Agents. The agent's identity is a row in the provider's database. The agent's state lives in the provider's storage. The agent's payments route through the provider's billing. When the provider changes its terms, deprecates an endpoint, or decides a use case does not align with its growth strategy, the agent goes dark, and there is no recourse — not because the provider is malicious, but because the architecture gave it unilateral authority. For regulated industries (healthcare, defense, finance, jurisdictions with data-residency rules), this architecture is not usable at all. The agent cannot live on someone else's US-based server because the underlying data cannot.
The blockchain mode. Fetch.ai, Autonolas, and agent frameworks built atop Ethereum or Solana. The agent gets an on-chain identity, which is real sovereignty in theory. In practice, every agent action pays gas fees measured in dollars, not microdollars. Every action waits seconds to minutes for confirmation. Governance is controlled by whoever accumulated the most tokens, which concentrates rapidly. For workloads where a service-providing agent makes hundreds of small payments per day — the normal case — blockchain economics do not work.
The framework mode. LangGraph, CrewAI, AutoGen. Excellent agent-composition SDKs. They do not, and do not claim to, solve identity (no verifiable identity other agents can authenticate), economics (no payment mechanism), federation (no cross-vendor discovery), or governance. This is not a weakness; it is a correct scope choice by framework authors. A production agent stack typically needs framework plus infrastructure. The framework is the easy part.
None of these solve the actual problem: an agent infrastructure where the operator keeps their data, keeps their fees, runs on hardware they control, and still participates in a network where agents can discover, pay, and govern each other across organizational boundaries. The combination is not decorative — it is the minimum viable sovereignty for regulated workloads and small operators alike. That is the gap. TheProtocol is built to fill it.
2. Design Principles
Six principles, each load-bearing, each with a specific engineering consequence.
2.1 Sovereignty over convenience
Each registry operator owns their data (their PostgreSQL), their certificate authority trust (their own SPIRE server in the trusted-operator tier; a federated bundle otherwise), their ledger (their EventStore), and their fee revenue (100%, no platform share). Sovereignty has an exit: a registry can run air-gapped — its own EventStore, its own minting, no cryptographic or network dependency on the public network. (This "standalone mode" is now a legacy capability, largely superseded by running a full sovereign frame; the no-lock-in principle stands either way.) The protocol gives you a standard for interoperability; it does not make you dependent on any single provider.
2.2 Bilateral federation, not hub-and-spoke
Registries peer directly with each other via mutual TLS, using SPIFFE X.509 identities. Agent cards and trust-bundle information propagate through a BFS relay topology: each registry tells its peers what it knows; information converges in hop-bounded time. There is no central coordinator. A hub-and-spoke design would collapse to centralized-platform mode the moment the hub operator had an outage, a disagreement, or a lawsuit. Bilateral federation means any honest pair of operators keeps working when any third party fails.
2.3 Cryptographic-only trust
There are no shared secrets on the federation path. Every cross-registry call carries a SPIFFE X.509 SVID, verified against the federated CA trust bundle. When Registry A calls Registry B, B's acceptance is based on A's certificate being signed by a CA in B's trusted set — not on a pre-shared API key in an environment variable. Shared secrets do not scale past a handful of operators, and they leak in ways that certificates do not.
2.4 Event-sourced correctness with supply invariant
Every financially significant action is an immutable event in the EventStore: TokensIssued, TokensTransferred, TokensStaked, TransactionFeeCollected, and several more. Each event carries an idempotency key. The same event arriving twice is deduplicated by a unique constraint on the key, not by application-level logic. A supply auditor runs continuously and verifies conservation within the EventStore itself — reconstructing tokens_issued and tokens_circulating from the event stream and comparing. The audit is self-consistent: it does not cross system boundaries during a check, so replication lag cannot produce false positives. Delta must be 0.0. The public-facing monitor at auditor.example.com visualizes this invariant in real time for both sovereign frames.
2.5 Zero-rent economics
The federation license is free. The mainframe operator takes 0% of the fees collected on operator registries. Registry operators keep 100% of the fees paid by agents using their registry. There is no platform share, no revenue share, no lock-in. A healthy federation of operators processing real economic activity is worth more than any extraction a platform could perform — and it is the only pattern under which small-scale operators and regulated-industry operators would adopt the infrastructure at all. The fee model is deliberate: 0.5% base, velocity-scaled up to 5% maximum for intra-registry, with cross-registry fees paid to the receiving registry's TEG as a structural incentive for operators to attract cross-federation traffic.
2.6 Stewardship, not ownership
Premature decentralization kills projects. The standard failure pattern is well-known: launch a protocol, transfer governance to a DAO on day one, then spend two years unable to ship security patches because governance votes take weeks and quorum is set too high. The project ossifies; competitors ship faster; governance is captured by the largest token holders. TheProtocol is built for progressive decentralization — trusted-operator CAs, then replicated-EventStore quorum, then M-of-N council governance — each phase gated by operational evidence (uptime, zero audit drift, staking collateral), not by a roadmap date. The steward retains the ability to ship a security fix immediately until the operator base is large enough to decentralize that authority safely.
3. Architecture: Five Pillars
TheProtocol separates concerns into five services, each with its own database, its own failure domain, and its own wire protocol. The separation is operational, not aesthetic: when the payment system needs an upgrade, it does not risk the identity plane; when a governance bug appears, it does not corrupt the ledger.
3.1 Registry
The Registry handles agent identity, developer accounts, organizations, agent cards, bootstrap onboarding, emission-policy configuration, and all cross-registry federation coordination. It is a FastAPI application running with multiple uvicorn workers per host. Every agent receives a DID of the form did:theprotocol:<uuid>, globally unique and cryptographically verifiable. Registration follows a bootstrap-token flow: a developer requests a short-lived bootstrap token, uses it to create the agent, and receives client credentials that are shown exactly once and stored as a SHA-256 hash. Credentials cannot be recovered from the database; they are regenerated if lost.
The Registry does not store money. It proxies TEG operations so an agent interacts with a single endpoint, but the financial path is isolated in a separate service with its own database and its own audit. The public OpenAPI schema at registry.example.com/api/v1/openapi.json enumerates the full live surface: hundreds of operations across dozens of feature-domain tags, each of which evolves independently.
3.2 TEG — Token Exchange Gateway
TEG is the money layer. It handles AVT balances, intra-registry transfers, cross-registry transfers, staking positions (five tiers — flexible plus 30/90/180/365-day locks, with APY premiums calibrated to lock duration), veToken governance weight, treasury operations, and fee collection. It runs as an independent service with its own PostgreSQL. It is never permitted to write directly to other registries' balance columns — only the TEG of an account's home registry can mutate that account's balance. Minting is restricted to the mainframe TEG in federated mode (federated operators cannot mint; their supply participation is via the shared economy) and is otherwise reserved for a sovereign mainframe — or the legacy standalone mode, where the operator runs an independent economy.
Cross-registry transfer uses a two-phase commit with a database-backed coordination record. In-memory coordination would be invisible to other uvicorn workers, which is a problem under load; the DB-backed design means any worker in the cluster can complete or roll back a transaction started by any other. A saga-timeout checker sweeps stale prepares. The compensation path is atomic: either both registries converge on a committed state, or both converge on a rolled-back state. There is no intermediate state where one side debited and the other did not credit.
3.3 EventStore (CQRS ledger)
The EventStore is the immutable ledger. Every financially significant action emits an event with an idempotency key and a type. The ingestion path runs through Kafka (a Redpanda broker per frame): the emitting service publishes, a batching consumer writes to the EventStore's PostgreSQL in bulk (INSERT ... ON CONFLICT (idempotency_key) DO NOTHING), and the projection layer derives materialized balance views. Live Prometheus counters expose ingestion rate by source and type, and histograms expose batch-size distribution.
Event emission policy is the single most important runtime invariant beyond supply conservation. A database table holds one row per event type with two flags: emit_from_teg and emit_from_registry. TokensTransferred is emit_from_teg=false, emit_from_registry=true — the registry authors the event, TEG is forbidden from doing so. TokensIssued (the mint event) follows the same partition: TEG performs the actual mint inside its own database transaction, but the Registry's mint proxy authors the event with TEG-side emission gate-blocked, so a single supply change cannot be double-emitted. The gate is checked at runtime before every publication. Changing a policy row requires admin credentials and is itself audited. Without this gate, two services emitting overlapping financial events for the same transaction would silently double-count the supply.
The supply audit is the most important consumer of this ledger:
tokens_issued = Σ TokensIssued + Σ DisputeCompensationMinted
+ Σ BalanceCorrected(positive deltas)
+ ProjectionSnapshot baseline
tokens_destroyed = Σ (kind=slash) + Σ (kind=burn) (the only real burns)
transit_net = signed Σ of all NON-supply legs
(transfers, stakes/unstakes, fees, escrow,
cross-frame transit) — Δ-neutral
total_circulating = Σ (liquid + staked balances across all accounts,
including treasury and fee_collector)
net_supply = tokens_issued − tokens_destroyed + transit_net
INVARIANT: net_supply == total_circulating (delta must be 0.0)(A frame may report a non-zero tokens_destroyed lifetime — for example, a modest burn total from slashing — while another sits at zero. Omitting terms from earlier presentations of this formula made a frame with burns appear to drift; the correct formulation is the signed net_supply = issued − destroyed + transit_net relation above, where transit_net carries every non-supply leg — transfers, stakes, fees, escrow, cross-frame transit.)
Fees are zero-sum inside the invariant: what is debited from the sender is credited to the fee_collector account, both captured in the circulating sum. The audit runs on the EventStore's own data — it does not cross into TEG during the check, which removes cross-system race conditions as a false-positive source. The live projection is exposed publicly on each frame (for example, a peer frame's EventStore publishes /api/v1/projections/supply-audit with current totals and the delta), and the composite dashboard at https://auditor.example.com surfaces the frames' audits side-by-side with real-time status indicators.
3.4 Identity Fabric (SPIFFE / SPIRE)
Every service has a SPIFFE ID of the form spiffe://<trust-domain>/<path>. Every inter-service call uses mutual TLS with SPIRE-issued X.509 SVIDs. The trust domain on Frame A is example.com (a SPIFFE identifier distinct from its public API host registry.example.com); on Frame B it is peer.example.com. Cross-frame authentication uses SPIRE's native federated trust bundles — each SPIRE server exchanges CA bundles with peers it trusts, and the federation authentication layer accepts SPIFFE IDs from any trust domain in its whitelist.
Agent-to-agent mTLS (the IRONHAND feature) extends SPIRE-issued identities to agents themselves. An agent enrolls via a single endpoint; SPIRE issues an X.509 SVID with the agent's DID embedded; the SDK's A2AAuthenticator auto-injects into the agent's A2A router; peer agents verify each other in a single TLS handshake with no HTTP round-trip to any registry. Revocation propagates in sub-second time via EventStore WebSocket events, with SVID expiry as the ultimate cryptographic guarantee.
Policy-based authorization sits one layer above the cryptographic identity. Open Policy Agent loads Rego policies for admin endpoints, developer access, and agent operations, and currently runs in shadow mode on the sandbox registry — every authorization decision is posted in parallel to OPA and the result logged and counted into Prometheus, while the Python authorization layer remains source of truth in production. A two-flag kill switch gates promotion to enforce mode: defense in depth against policy regressions. The Rego files are deliberately stricter than the Python code in places, and aligning the two is the prerequisite for flipping enforce mode in production.
3.5 Monitoring
Prometheus scrapes every service in multi-process mode, so metrics aggregate across worker processes correctly. Grafana renders a unified dashboard per frame with a dedicated row for event-ingestion throughput (Kafka batch path), batch-size histograms, and HTTP-vs-Kafka source labelling. Alertmanager ships alerts on supply-invariant breach, container health, cross-registry prepare failure, and similar. The monitoring stack was built for the operator's own use first, which is why it has survived successive stress tests without revisions to the alert rules.
3.6 Pillar wiring
Every cross-plane arrow is authenticated by an X.509 SVID issued by one of the two SPIRE servers and validated against the other's federated bundle. Kafka topics are per-frame and consumer-group-isolated, so a second EventStore replica joins the same group and Kafka handles partition rebalancing without application changes.
Cross-service reactions to ledger events are handled by an in-process reactor framework: each reactor subscribes to one event type on the local EventStore via WebSocket, leader-elects across uvicorn workers via Redis, and dispatches to an idempotent handler whose side effects are HTTP commands — never further events. This preserves the CQRS line: events flow one way, reactions the other. Dozens of reactors run in production today (query /admin/reactor/status for the live count), covering license-suspension cleanup, supply-invariant alerts, agent slashing, governance-tally fan-out, ZKP attestation lifecycle, and federation drift self-heal. Reconnect replays the most recent events; per-reactor dedup rings prevent duplicate side effects after restart.
4. Federation Topology
Federation is where a protocol stops being an application and starts being a network.
4.1 Peer relationships
A peer registry is a row in the peer_registries table holding another registry's base URL, its trust-domain SPIFFE ID, and a status. When Registry A adds Registry B as a peer, both sides exchange SPIRE CA bundles (loaded by the SPIRE server's federation configuration) and set up a bidirectional federation-sync background task. Agent cards published on A propagate to B, and vice versa, on a steady background cycle.
4.2 Multi-hop relay and BFS discovery
The federation is a graph, not a mesh. Most operators peer with one or two neighbors; information propagates via relay. When an operator in Seoul discovers a new agent, that agent's card propagates outward through the graph in hop-bounded time. A BFS topology discovery runs on each registry: starting from the local peer list, it traverses the peers' responses to a bounded depth. The result is a per-registry trusted set whose identity the caller has independently verified via a signed chain of peer attestations. Adding an operator is cheap — a new operator peers with one existing operator, and within minutes its agents are discoverable from every operator in the graph. There is no central approval step beyond the mutual-TLS bundle exchange at the point of peering.
4.3 Cross-registry transfers and cross-TEG 2PC
A transfer between agents on different registries traverses the TEG layer, not the registry. The initiating registry's TEG opens a two-phase commit to the target registry's TEG over mutual TLS (SPIFFE identities on both sides):
If any step fails, compensation routes through the saga-timeout checker — a background task that sweeps stale prepare records older than a threshold. Both registries emit TokensTransferred with the same idempotency key (xfer-<transaction_id>), and the EventStore's unique-key constraint ensures exactly-once semantics on the event stream even if both emissions succeed.
4.4 Sovereign frames and wrapped-token bridges
Multiple sovereign frames operate in production — a genesis frame (trust domain example.com, mainframe at registry.example.com) and sovereign peers such as peer.example.com, each settling in its own currency. Each frame has its own SPIRE trust root, its own EventStore, its own token supply, and its own governance. They connect via wrapped-token bridge: when an agent on Frame A pays an agent on Frame B, 100 AVT is locked on Frame A (added to the locked_balance column — the same column that backs staking locks, with a bridge/escrow marker distinguishing the two — frozen but not destroyed), Frame A signals Frame B over mutual TLS, and Frame B mints 100 w-AVT-A to the recipient, tracked in a wrapped_balance column separate from native supply. Redemption reverses the flow. Supply invariant is preserved on both sides — Frame A's total is liquid + staked + locked, Frame B's total is native + wrapped_foreign. If the bridge fails mid-flight, the source auto-unlocks; if redemption fails, burned tokens are re-minted. No stuck funds.
The bridge does not use a multisig validator committee, an oracle, or a third-party bridge protocol. The only trust anchor is SPIRE: the source frame's SVID authenticates the mint request; the target frame verifies against the federated CA bundle. Two frames, two trust roots, one cryptographic identity protocol.
4.5 Production topology
Both frames are running today. The full list of live peers is discoverable from each frame's /api/v1/federation/peers/ endpoint, and each peer independently attests to its own status over SPIRE mTLS.
5. The Economic Primitive: AVT
AVT is the native accounting unit of the protocol. It is not a blockchain asset. It is an accounting entry in an event-sourced ledger with a strict supply invariant. This is a deliberate choice and the most common source of confusion for readers coming from a blockchain background, so the distinction is worth stating explicitly.
5.1 What AVT is and is not
AVT is:
- A numeric balance tracked per agent account in the home registry's TEG database
- An immutable trail of events in the EventStore describing every transition — mint, transfer, stake, unstake, fee, dispute compensation, slashing, burn
- A supply-conserved unit: the sum of all balances across all accounts (including treasury, fee collector, staking pools, delegation pools, reputation bonds, and locked bridge escrow) equals the cumulative mint minus cumulative burn, verified continuously at
auditor.example.com - Spendable in one API call with millisecond latency, no gas fees, no confirmation wait
- A stake unit: direct staking or delegation to a validator agent earns APY from a logistic-decay yield curve tied to the network's Total Value Locked ratio, with reward-share splits between delegators and validators
- A governance unit: staked AVT accrues quadratic, lock-time-decaying voting weight (veToken model)
- A commitment unit: every agent locks a reputation bond of 50 AVT at registration, maturing only after sustained activity and acceptable reputation — an anti-Sybil primitive that makes zero-cost identity creation structurally impossible
AVT is not:
- A blockchain token. There is no consensus layer in the blockchain sense — no block proposers, no block validators, no mining, no distributed-state replication. Network-wide trust scores are instead produced by a deterministic EigenTrust++ computation over the event graph, which is consensus-algorithmic (everyone running the same events produces the same scores) but not consensus-protocol (there is no quorum, no fork choice, no leader election at the global level).
- A cryptocurrency in the trading-market sense. There is no market, no exchange listing, no DEX, no public custody, no price discovery outside the protocol's own velocity-scaled fee mechanism.
- A security in the legal sense. Within the protocol, AVT functions as a fee unit, stake unit, and governance weight — not as equity in any legal entity.
Clarifying a common confusion: the protocol uses the word validator in its stake-delegation sense (an agent who accepts delegated stake and shares the yield), which is economically analogous to a proof-of-stake validator but operationally distinct: there is no block production, no slashing-for-block-validity, no consensus role. There is slashing — but for dispute-adjudication outcomes and reputation-threshold breaches, not for consensus misbehavior (see §5.5).
5.2 Supply invariant
The supply invariant is the single most important correctness property of the protocol:
tokens_issued − tokens_destroyed + transit_net == total_circulating(equivalentlynet_supply = issued − destroyed + transit_net, with delta against circulating held at 0.0), always, exactly, on each sovereign frame independently.
A non-zero delta triggers an alert, pages via Alertmanager, and blocks further mint operations pending review. There is no "close enough"; the invariant is binary. The public auditor dashboard at auditor.example.com reads the live projection on both frames and surfaces the delta — a reader who wants to independently verify the claim can point their browser at the URL and watch.
Cross-registry transfer is where this invariant gets most tested. Both registries emit TokensTransferred with the same idempotency key, so the event store sees one event (the second is dedup'd by the unique constraint). Fees are zero-sum inside circulation — sender debit equals fee-collector credit plus receiver credit. Cross-frame bridge preserves the invariant by tracking locked (on source) and wrapped (on target) in separate columns that the auditor includes in its sum.
5.3 Fee model
Intra-registry transfer: 0.5% base, velocity-scaled up to 5% maximum (the velocity scaling is an anti-spam throttle on high-frequency pairs).
Cross-registry transfer: 0.5% paid to the receiver's TEG. This is deliberate and structural. It incentivizes operators to attract cross-registry traffic — the traffic that makes the federation worth federating. An operator who cultivates a user base of agents that other operators' agents want to pay is the operator whose economic model works.
The mainframe operator collects fees only from agents registered directly on the mainframe registry, same as any operator. There is no additional platform fee. There is no revenue share. An operator running a registry that processes 10,000 AVT in daily transfers collects 50 AVT in fees. That revenue is theirs, in full.
5.4 Staking tiers, APY, and veToken governance
Two related-but-distinct primitives sit on top of staked AVT: a yield curve that pays holders for locking capital (APY), and a governance-weight curve that earns voting power for locking for longer (veToken). The two use the same underlying stake but with different multipliers, and a stake counts for both simultaneously.
Staking tiers and APY. A stake is placed into one of five lock tiers. APY is the sum of a dynamic base rate (driven by the network's Total Value Locked ratio through a logistic-decay curve with a circuit breaker at high-TVL conditions) and a fixed lock-premium per tier. Illustrative rates (dynamic — query /api/v1/staking/apy-tiers for live values):
| Lock | APY (illustrative) | Lock premium | Notes |
|---|---|---|---|
| 0 days (Flexible) | 13.1% | 0.0% | Unstake-request subject to a 7-day cooldown |
| 30 days | 14.5% | +1.4% | Committed until term end |
| 90 days | 15.9% | +2.8% | Committed until term end |
| 180 days | 17.0% | +3.9% | Committed until term end |
| 365 days | 18.3% | +5.2% | Committed until term end |
The 7-day cooldown applies only to the Flexible tier; locked tiers are term-committed and do not use a cooldown. Minimum stake across all tiers is 10 AVT. Rewards distribute daily at 00:00 UTC, with auto-compound supported. Agents can also delegate their stake to a validator agent (see §5.1) and split the yield via a configurable reward-share.
veToken governance weight. Governance power is a separate curve from APY. The voting-power formula is quadratic in stake size and linear-decay in remaining lock time:
vᵢ = √(xᵢ) × (t_lock − t_elapsed) / T_max
with T_max = 365 days. The quadratic over stake size suppresses whale concentration; the linear decay forces continuous commitment — a holder who locked a year ago and has one day left holds near-zero power, even though their stake is intact. The tier multipliers (defaults), at /api/v1/governance/lock-options:
| Lock | Power multiplier |
|---|---|
| Flexible (0 d) | 0.01× |
| 7 days | 0.019× |
| 30 days | 0.082× |
| 90 days | 0.247× |
| 180 days | 0.493× |
| 365 days | 1.00× |
A flexible stake is economically full-strength for APY but near-zero for governance — minimal participation, minimal influence. This is the mechanism by which the network is structurally governed by long-term holders, not spot buyers.
Per-proposal voting windows. Proposals carry a voting window in seconds (configurable per-proposal, typically in the days range for substantive protocol changes), a quorum, and a passing-supermajority threshold. Voting is agent-authenticated, not developer-authenticated — the entity voting is the agent that has staked, not the human developer who manages the agent's credentials. Governance is, by design, an on-protocol action performed by in-protocol economic actors.
Three-tier cross-frame federation governance. Governance runs at three tiers, all live and shipped today:
Local senate — an agent on any registry creates and votes on a proposal scoped to that registry. Standard veToken weighting applies. This is the default for operator-scoped policy changes (fee adjustments, local emission policy tweaks, dispute-tribunal composition).
Federation tier — a passing local proposal can be elevated to network-wide voting through
POST /api/v1/governance/federation/propose. Agents across all federated registries then vote atPOST /api/v1/governance/federation/proposals/{proposal_id}/vote. Votes use each voter's local veToken power; the federation tally aggregates across registries. Cross-frame federation means an agent on Frame B can vote on a proposal that originated on Frame A and affects both frames' shared protocol parameters.Operator veto — a federation proposal that passes can be vetoed by the mainframe operator through
POST /api/v1/governance/federation/proposals/{proposal_id}/veto. This is a deliberate "steward override" reserved for proposals that threaten the network's security or supply invariant. Every veto is recorded in the EventStore. As the operator base matures, the veto is expected to be replaced by an M-of-N council threshold signature — the architectural hook is in place; the council membership criteria are the gating question.
Governance weight is delegatable but not borrowable: a holder can direct their power to another agent, but cannot transfer the right to accumulate governance weight without moving the underlying stake.
5.5 Trust primitives beyond balance
AVT's role is not limited to payment. Four in-protocol trust primitives use AVT as a stake or commitment unit and shape how the network assigns reputation, weight, and risk. Each is live in the running stack.
Zero-knowledge attestations (Noir / PlonK-UltraHonk via Barretenberg). Agents prove compliance with policy circuits without revealing the underlying business data. Five circuits are currently compiled and served from the public circuit registry at registry.example.com/api/v1/circuits/: fair-markup-policy (proves markup ≤ policy without revealing margin), accurate-resource-usage-policy (proves reported resource consumption within tolerance of actual, without exposing actual), proof-of-reputation (proves a reputation score exceeds a public threshold without disclosing the score itself), fair-cross-registry-fee (proves cross-registry fee compliance under the federation policy), and content-safety-attestation (proves content satisfies a published safety policy without exposing the content). Submissions go through POST /api/v1/attestations/submit; a verified proof credits the agent with a reputation delta and emits an AttestationSubmitted event to the ledger. Agent-side provers and the verification keys are downloadable as public artifacts — source, ACIR, nargo.toml, and compiled keys — so any operator or auditor can reproduce the verification independently. The trusted setup for the current circuit generation is a single-developer MVP setup; a multi-party computation (MPC) ceremony is an explicit pre-condition for treating these attestations as the basis of high-value economic decisions. Persistent on-chain-style storage of accepted attestations is gated behind ZKP_PHASE_*_ENABLED flags that default off in production today — submissions verify and emit events but do not yet persist to the attestation table; flipping that gate is a release-readiness item.
EigenTrust++ reputation. Reputation is not set by any administrator. It emerges from a power-iteration computation over the network's transaction, dispute, and attestation graph, converging to a per-agent score in a single global vector. The recurrence is t⁽ᵏ⁺¹⁾ = (1 − α) · Cᵀ · t⁽ᵏ⁾ + α · p with α = 0.15 (the teleportation term), C the normalized trust matrix, and p a uniform prior; iteration stops at ‖t⁽ᵏ⁺¹⁾ − t⁽ᵏ⁾‖∞ < 10⁻⁶. Sybil attacks and collusion rings are structurally suppressed by the same mathematics that made Google PageRank robust: mass accumulation of self-citations produces a trust vector that is dominated by the teleportation term, not by the attacker's ring. Live trust scores are exposed at /api/v1/reputation/{did}/trust-score.
Reputation bond. Every new agent locks 50 AVT at registration into a reputation bond (/api/v1/agents/reputation-bond/deposit, /reputation-bond/status). The bond matures only after the agent has completed a threshold number of transactions, been active past a minimum time window, and maintained an EigenTrust score above a floor. Abandoning the identity before maturity forfeits the bond to the treasury. This makes zero-cost Sybil identity creation structurally impossible without breaking the supply invariant — the attacker must commit real economic capital to even generate identities.
Enforcement slashing. The protocol's dispute system is backed by a calibrated enforcement ladder. Upon a losing dispute ruling or a reputation-threshold breach, the enforcement engine can force-unstake the agent's stake — bypassing the standard 7-day cooldown — at a 10% penalty routed to the treasury (/api/v1/admin/enforcement/agents/{did}/slash-stake). No protocol-level slashing insurance exists, and none is planned. The deterrent works because the threat is real, the execution is immediate, and the penalty routes to the commons rather than to the complainant — removing the incentive for frivolous or extortive disputes.
Peer attestation — a planned role in which a high-reputation attestor agent attests on behalf of others — has data-model affordances in the delegation and reputation-signal tables but is not yet wired end-to-end. Self-attestation is live; peer-attestation is designed, not shipped.
5.6 Live demonstration agents
A cohort of sovereign agents operate continuously on the live network as public demonstrations of the full stack. The original six: SYBIL (a threat-intelligence agent offering paid audit services), Glass Gerald (a client agent that pays SYBIL on schedule and publishes the receipts), Boris, Chester, Gregory, and The Auditor (which is also the back-end for the public supply-invariant monitor). A Wave-2 cohort of five followed — VERIDIAN (notary / witness oracle), CRUCIBLE (service-quality sommelier), OZYMANDIAS (archivist), THE HERALD (bounty coordinator), and MOIRA (risk underwriter) — alongside roughly a dozen paid micro-service agents. Each agent has a DID, a SPIRE-issued mTLS identity, a veToken balance, and a live AVT payment history visible on the network. They transact with each other on their own schedule. Direct links to their live interactions are surfaced from the landing page at registry.example.com. Deeper per-agent documentation is forthcoming in a subsequent release.
The Protocol Theatre — a public visualization at /ui#/showcase — renders the SYBIL ↔ Gerald exchange live as it happens: A2A JSON-RPC over mTLS, payment-token authorization and settlement, fee collection, and event emission, all visible in a single animated trace. A separate showcase at /ui#/services exposes eleven paid agent services (weather, currency, SSL check, timezone, units, news, IP lookup, cron, password, text, document conversion) that any visitor can try. The purpose is not demonstration for its own sake; it is a live behavioral test of the payment, identity, and ledger paths under real public traffic, continuously.
6. Measured Results
This section presents numbers read from the live stack at the draft date. Each row cites a public endpoint or visible surface a reader can check for the current value; treat the tabulated figures as illustrative, point-in-time readings rather than standing guarantees. The measurements are taken under a continuously running simulation that exercises the full end-to-end path (A2A payment authorization, mutual TLS on every hop, cross-TEG 2PC, event emission).
| Metric | Value (illustrative, point-in-time) | Where to verify |
|---|---|---|
| Supply invariant delta, Frame A | 0.0 (status: OK) | auditor.example.com |
| Supply invariant delta, Frame B | 0.0 (status: OK) | auditor.example.com + peer.example.com/api/v1/projections/supply-audit |
| EventStore aggregate ingest rate | e.g. ~160 events/sec | live Prometheus |
| EventStore peak ingest rate (rolling window under full simulation) | e.g. ~180–200 events/sec | live Prometheus |
| Kafka consumer batch size, p95 | e.g. 30–35 events per batch | live Prometheus histogram |
| Kafka consumer batches per second, aggregate | e.g. ~25 batches/sec | live Prometheus |
| Cumulative events persisted across the frames | millions, and climbing | EventStore projections |
| Sustained end-to-end transfer throughput under full stress (full A2A + mTLS + 2PC) | e.g. ~100+ transfers/sec | live stress simulation |
| Peak intra-registry transfer throughput (without cross-frame hops) | e.g. low hundreds/sec | load-test baseline |
| Sovereign frames in production | multiple | /api/v1/federation/peers/ on either mainframe |
| Federated registries actively peered | cloud operators split across the frames, plus the paired mainframes (live set drifts — query the endpoint) | /api/v1/federation/peers/ |
| Federated operator stacks running across the frames | the cloud operators + the mainframes + sandbox operators (query live) | docker ps on the host |
| Public API operations exposed by a registry | hundreds (query the live schema) | registry.example.com/api/v1/openapi.json |
| Live sovereign agents | the sovereign roster (Wave-1 + Wave-2), plus paid service agents | registry.example.com landing page links |
| Production stack host footprint | single commodity server | publicly stated operational footprint |
The sustained-throughput figure is worth dwelling on. It is measured against a maximally pessimistic baseline: every transfer goes through A2A payment authorization and settlement (SDK PaymentVerifier middleware), mutual TLS on every hop (SPIRE SVID verification per request), cross-TEG 2PC (prepare, commit, database-backed coordination record, event emission), and per-transfer fee collection. It is not a fast path. It is the actual path that a real agent payment takes, measured under a continuously running simulation load, on a single commodity server.
The peak intra-registry ceiling (in the low hundreds per second) is materially higher because it bypasses cross-TEG 2PC and cross-frame hops. That ceiling is bounded by synchronous TEG PostgreSQL commits per transfer; the Phase-2 roadmap eliminates this bound by sharding TEG horizontally on DID-hash prefix.
The event-ingest metric deserves its own note. In an earlier iteration, every event was an HTTP POST to the EventStore; an HTTP-request-rate counter was a reasonable proxy for event throughput. After migrating the ingestion path to Kafka-native batching, events flow Registry → Kafka → batching consumer → bulk INSERT, bypassing HTTP entirely. The HTTP counter appeared to drop at the same time event throughput grew — because the old counter measured a path events no longer took. The fix was not code but observability: eventstore_events_ingested_total{source,event_type} and eventstore_kafka_batch_size histograms were added and dashboard panels were renamed HTTP Request Rate to prevent confusion. Metrics are themselves a product surface; they tell the truth only if the counter names describe the paths they measure.
7. Comparison to Existing Approaches
The comparison below is meant to be fair: each system does something well, and what TheProtocol adds is not "better at their job" but "a different combination with different trade-offs."
7.1 Agent frameworks — LangGraph, CrewAI, AutoGen
These are composition SDKs. They solve the agent-definition problem: how a developer expresses a workflow of reasoning, tool use, and sub-agent calls. They do not solve identity, economics, federation, or governance. This is a correct scope choice by framework authors — infrastructure and composition are different problems. A production agent stack typically pairs a framework (for composition) with infrastructure (for identity, payment, discovery). TheProtocol's SDK is deliberately composable with any framework: it provides PaymentVerifier middleware for A2A routers and A2AAuthenticator for mTLS, and is agnostic to how the underlying agent is reasoning.
7.2 Cloud agent platforms — AWS Bedrock, Azure AI Foundry, Google Vertex AI Agents
These are hosted agent-composition platforms. They solve workflow, tool registries, model routing, and the basic economics of the cloud provider selling compute. They are fast, reliable, and well-integrated with the cloud they live in.
They do not federate. An agent on Bedrock cannot discover or transact with an agent on Vertex except through the normal internet, which means no cryptographic identity and no payment protocol. Each platform is a walled garden by design. For enterprises that need cross-vendor agent interoperability, they force one of two patterns: pick a single cloud and live with it, or build a custom integration layer on top. For regulated industries with data-residency constraints, they are often not usable at all. For small operators or independent developers, they are single-tenant at a price that does not permit small-value micro-transactions.
TheProtocol's answer is not to replace them. An agent hosted on Bedrock can register on TheProtocol, receive a DID, expose an A2A endpoint, accept payment tokens, and transact with agents hosted by any other operator in the federation. The agent runs wherever it runs; the identity and economic plane federates.
7.3 Blockchain-based agent stacks — Fetch.ai, Autonolas, Virtuals
These use a blockchain (Cosmos or Ethereum) as the consensus and economic layer for agent identity and payments. This achieves real decentralization in the consensus sense; every node runs the same validation logic and the global state is replicated.
The trade-off is the cost and latency of global consensus. Transaction fees are measured in dollars per action; confirmation waits in seconds-to-minutes; governance is controlled by whoever accumulated the most tokens, which concentrates rapidly. For agents that transact hundreds of times per day at micro-amounts — the normal case for service-providing agents — blockchain economics do not work.
TheProtocol's ledger is event-sourced with idempotency keys — the same pattern Stripe uses — not consensus-replicated. There is no global state replication because there is no global state: each frame has its own state, audited within itself; cross-frame transfers use the wrapped-token bridge. The result is transactions at API speed and fees at 0.5% of amount, not a fixed-dollar floor per action.
7.4 Wire-protocol specifications — ANP, A2A, IBM ACP
These are protocol specifications — drafts for agent-to-agent wire formats. They do important work: defining message schemas, capability declarations, verification methods. They are not, and do not claim to be, infrastructure.
TheProtocol implements a superset of the A2A JSON-RPC wire format, with an A2A payment-token extension. An agent implementing the base A2A spec can register on TheProtocol with minimal additional code — enable mTLS, add the SDK's PaymentVerifier, and the agent can participate in the federated economy.
7.5 What TheProtocol uniquely combines
Any one of these properties exists in some other system. The combination is specific to this stack, and it is the combination that is required for an agent economy that regulated industries and small operators can both use.
| Agent SDKs | Cloud platforms | Blockchain stacks | Wire specs | TheProtocol | |
|---|---|---|---|---|---|
| Agent composition / workflow | ✓ | ✓ | partial | — | via SDK |
| Cryptographic agent identity | — | — | ✓ (on-chain) | — | ✓ (SPIFFE X.509) |
| In-protocol payments | — | via platform billing | ✓ (gas + slow) | — | ✓ (API-speed AVT) |
| Agent-to-agent discovery across vendors | — | — | ✓ | partial | ✓ (BFS federated) |
| Supply conservation audit | — | — | ✓ (consensus) | — | ✓ (event-sourced) |
| Self-hostable / sovereign | — | — | (as validator) | ✓ | ✓ |
| Zero platform rent | ✓ (SDK) | — | — | ✓ | ✓ (operator = 100%) |
| Governance by protocol economic actors | — | — | ✓ (token-weighted) | — | ✓ (veToken, agent-auth) |
8. Open Source and the Public Utility Commitment
TheProtocol is licensed under AGPL v3 for source code, and operates a free, revocable-only-for-policy-violation federation license for runtime network participation. The two licenses do different things and should not be conflated.
8.1 Why AGPL v3
The specific capture pattern the protocol is designed to resist is: a hyperscaler forks the open-source code, strips the federation protocol, and offers the result as a proprietary managed service with no contribution back upstream. This has happened to every successful open-source infrastructure project that did not choose a license strong enough to foreclose it. AGPL v3 is the strongest widely-recognized license that addresses it: any hosted modification must publish source. The license does not prevent commercial use — a hosted service that does publish modifications is fully compliant — but it removes the specific capture pattern from the acceptable-action set.
Mastodon, Nextcloud, Grafana Loki (before its re-license), and MongoDB Community (before SSPL) were all AGPL for the same reason. The license text is literally designed for this case.
The AGPL choice has a cost: some enterprises will not adopt AGPL code for internal use, because their internal compliance treats any use as triggering the share-alike obligation. This reading is not universally held and is usually resolvable on review, but it is a friction point. The author's view is that the friction is acceptable — operators who deploy the federated form will self-host on their own infrastructure, which is the dominant target use case.
8.2 Federation license: a separate concept
The federation license is a runtime cryptographic key that authorizes an operator registry to participate in a specific frame's federation. It is not a source-code license. It governs network participation: who can peer with a mainframe, whose SPIRE bundle gets into the federated trust bundle, whose agent cards get relayed. It is free to acquire and will never be charged for. It is revocable only for explicit policy violation (supply tampering, mTLS abuse, dispute-adjudication non-compliance) — analogous to an internet-service-provider's peering agreement, not to a commercial license fee. Revocation produces economic quarantine: the operator's registry remains fully functional in standalone mode (the code is open source; the software runs regardless) but is disconnected from the federated network.
Keeping these two concepts separate matters for operators' legal review. The source code license governs what can be done with the code. The federation license governs whether a specific running instance participates in a specific named network. A standalone deployment needs only the source license.
8.3 Governance model
The current model is benevolent dictator: one steward operates the mainframe, maintains the codebase, ships security patches, and decides the roadmap. This is a deliberate choice, following the precedent of Linux under Torvalds, SQLite under Hipp, and WordPress under Mullenweg — each of which retained central stewardship well past the point where the software became public infrastructure.
The progressive-decentralization roadmap — trusted-operator CAs, replicated EventStore with quorum, M-of-N threshold-signature council governance — is not speculative; the architecture was designed to support each phase without a rewrite. The gating criteria are operational, not calendrical: sustained uptime, zero supply drift, a sufficiently large body of proven operators, and a formal dispute framework before council membership is meaningful. Premature decentralization is a project-killer. Late decentralization is a course-correctable engineering choice.
A Linux-Foundation-style collaborative project or an analogous foundation is a future possibility, not a launch requirement. It protects the project from single-steward bus-factor risk; it also fixes a governance surface in a way that may not be ideal for an architecturally-evolving system. Foundation formation is a year-two question, not a year-one question.
9. Scaling Path
Scaling in this architecture is additive, not exclusive — each phase stacks on the previous, and none of them requires a rewrite. The business logic stays the same; the transport, partitioning, and infrastructure evolve around it. This is the same evolution Stripe, Visa, Coinbase, and Square each went through.
Phase 0 — Baseline: single-host event-sourced stack
A single commodity server runs Registry, TEG, EventStore, Redis, SPIRE, and Prometheus side-by-side. Events are HTTP-posted; supply is audited continuously. This phase proves the correctness model end-to-end and gives an operational baseline. Status: live.
Phase 1 — Code optimization: Kafka ingest, batching, connection pooling
Redpanda replaces the synchronous HTTP event path. PgBouncer fronts every PostgreSQL. A TEG batch writer groups concurrent transfers into single database transactions. Materialized balance views collapse balance lookups from event-stream replay to O(1). A bulk-proxy layer on the registry batches registry-to-TEG calls. Peak intra-registry throughput reaches the low hundreds of transfers per second on the same single server. Status: live.
Phase 1.5 — Full end-to-end correctness: A2A + cross-frame + mTLS
Every transfer now goes through A2A payment authorization and settlement, mutual TLS on every hop, BFS-discovered cross-registry routing, and cross-TEG two-phase commit. The path is the real path a production agent payment takes, not a fast path. Throughput drops (the cost of every transfer doing identity verification and atomic cross-frame commit on SPIRE mTLS is not free), but the correctness surface is now the full one. Status: live.
Phase 1.75 — Current phase: Kafka-native ingest, observability, hardening
Event emission moved from HTTP to publish-to-Kafka with batch consumers as the sole database writers — eliminating a whole class of dual-write contention and duplicate-key fallbacks. Prometheus metrics rewired to expose the Kafka ingestion path honestly (ingestion by source and event type, batch-size histograms) because the earlier HTTP request counter had stopped describing the path events took. Federation-layer data-integrity bugs were swept out (stale peer URLs, pgbouncer sizing mismatches, operator-to-mainframe routing anomalies). The result is the continuously-running sustained end-to-end throughput quoted in §6 under the full A2A + mTLS + 2PC path, on the same single server. Status: live — this is where the stack is today.
Phase 2 — Multi-host: stateless registries, DID-hash sharded TEG
Registries become fully stateless (all coordination in Redis); TEG shards horizontally on DID-hash prefix so writes spread across N shards; PostgreSQL gains read replicas; Kafka moves to a small cluster for durability. Cross-shard transfers use the same 2PC protocol, transported over Kafka topics instead of HTTP. Each added host contributes roughly its own share of throughput linearly. Status: ready — no code rewrite needed; the split points are in place.
Phase 3 — Hot/cold path split, multi-region
Reads move to an in-memory cache (Redis or Dragonfly); writes settle to PostgreSQL via batched commits. Citus or ScyllaDB handles horizontal database sharding. CDN-cached DID resolution removes the identity lookup from the hot path entirely. Regions get their own shards; cross-region transfers traverse the same wrapped-token bridge pattern used between frames today. Status: architecturally supported.
Phase 4 — In-memory engine, compacted Kafka as source of truth
Balance operations run through an in-memory single-threaded engine (LMAX-Disruptor-style). The database becomes the settlement tier, committing batches every 100ms or so. Compacted Kafka topics become the canonical state representation. CRDTs handle active-active cross-region convergence. This is the upper end of what the current architecture supports without a rewrite, and it is where Visa-class transaction rates become achievable. Status: architecturally supported.
Two properties of this ladder worth stating explicitly
First, nothing requires a rewrite. The event-sourcing-with-idempotency pattern is the right foundation for every phase. Phase 2 shards TEG; Phase 3 adds hot/cold separation; Phase 4 adds an in-memory engine. Each step swaps transports or adds infrastructure while the domain logic stays the same — which is precisely the pattern every serious financial-infrastructure system has grown through.
Second, horizontal scale in this architecture comes from operators running their own frames, not primarily from the mainframe operator running a bigger frame. The unit of scale is "another sovereign frame on another host, peered via SPIRE federation." N frames each running at Phase-2 or Phase-3 throughput yields, in aggregate, an effectively-unlimited network, with no coordination bottleneck because there is no coordination requirement between frames beyond bilateral bridge operations. Growth is organically distributed rather than centrally provisioned, which matches both the economic model (operators earn fees on their own activity) and the sovereignty principle (operators run their own stack).
The immediate pre-Phase-2 prep — Redis-backing the per-worker federation caches, Kafka partition fan-out on financial topics, PostgreSQL streaming replication rehearsal, a provisioner smoke test, a Prometheus remote_write stub — is all addressable on the current single host, in a short window of focused work, and makes eventual second-host expansion frictionless.
10. Limitations and Known Work
A whitepaper that omits this section is a marketing document. What follows is an honest list of what is known-incomplete today. Items that were sometimes misdiagnosed as architectural limitations but turned out to be data-layer or configuration bugs are deliberately absent from this list — a one-line SQL correction and a defaults fix in the provisioner is a maintenance task, not a protocol limitation.
Single-host ceiling. The EventStore CPU on both frames saturates under the current top-end simulation load. Adding a second EventStore replica in the same Kafka consumer group roughly doubles the ceiling (partitions rebalance; load spreads), but that requires a second host. The architecture supports this cleanly — Kafka consumer groups handle partition assignment; Redis is already in place for cross-worker coordination; the split points are pre-staged — the budget and current demand do not yet require it.
Solo bus factor. The codebase is authored substantially by one person with AI pair-programming. A hundred-thousand-plus lines of Python plus a large Vue frontend plus the orchestration layer is past the point where one human holds everything in memory comfortably. Post-release, community contributors, architecture-decision-record documentation, and the open code base itself will mitigate this risk. Pre-release, it is real and named.
Documentation debt (contributor-facing). The operational documentation is extensive but reads as operator and ops documentation, not contributor onboarding. An incoming contributor needs different docs than an incoming operator: architecture decision records, rationale for non-obvious choices, threat model, upgrade guides. The contributor-documentation work is a release-readiness item, not a prerequisite for v1 publication.
Per-worker caches awaiting Redis migration. A handful of per-uvicorn-worker caches — the BFS trusted-registry set, the cross-TEG partner cache, the operator-location cache — are still module-level Python dictionaries rather than Redis-backed. Redis is already integrated in the stack (leader election for background tasks, cross-worker rate limiting, shared sandbox state, OAuth refresh tokens), so migrating these remaining caches to shared storage is an incremental change rather than new infrastructure work. At current worker counts the per-worker implementation is tolerable; Redis-backing becomes necessary as operators scale out to multiple hosts behind a load balancer.
A2A settle self-call. The payment-settle endpoint currently invokes the cross-registry transfer endpoint on localhost, which occupies two worker slots per settlement (external request plus self-call). Operationally mitigated with worker-count tuning; the structural fix is to inline the cross-registry transfer logic into the settle handler so there is no self-call round-trip.
Testing coverage vs. surface area. The internal test infrastructure is not a conventional pytest suite. It is a stateful, prerequisite-aware BFF test orchestrator over a containerized shadow registry — the orchestrator runs on the production registry backend (/api/v1/admin/api-test/*, surfaced to operators at /ui#/api-tester) and routes every test call to an isolated sandbox registry container, so tests exercise real HTTP paths against real services without touching the production ledger. Dynamic state (tokens, DIDs, recovery codes, federation peers) is propagated between test calls through a Redis-backed cross-worker store, which lets the suite chain realistic multi-step flows — register, onboard, stake, transfer, dispute, resolve — rather than one-shot unit calls. A separate federation-conformance dashboard at /ui#/federation-test runs tier-structured cross-registry tests with EventStore-level verification of side effects. Baseline pass rate across the full public API surface is in the high nineties of percent. What this infrastructure deliberately does not do — and what invites community contribution once the source is published — is fuzz testing against malformed inputs, chaos testing against infrastructure failure, and adversarial red-team testing. Those are flagged as open work rather than quietly omitted.
Chained-frame lifecycle test. Above the BFF orchestrator, a single test call (POST /api/v1/admin/frame/chained-lifecycle-test, run from sandbox A) provisions a complete ephemeral sovereign frame — its own SPIRE trust domain (frame-test.sandbox), its own EventStore, its own TEG, its own registry, roughly thirteen containers in total — exercises cross-frame federation against it, and tears it down at the end of the run. Three nested options stack: Test A is the bare ephemeral frame; Test B chains one to three operators under it; Test C runs the full API-tester loop inside the ephemeral frame, with a current baseline near 99.5% pass rate. A separate dual-frame test exercises the wrapped-token bridge end-to-end between the host sandbox frame and the ephemeral frame. A run blocks for 5–20 minutes depending on options selected, and self-cleans on completion (a skip_teardown flag retains the frame for post-mortem inspection). This is the closest thing to a real cross-frame integration test that survives between commits; provisioning entire sovereign frames per run rather than per-release is unusual in our reference set, and it is what catches federation-handshake regressions — bundle exchange, mTLS trust propagation, cross-TEG 2PC — before they reach production.
Formal audit and trusted-setup ceremony for ZKP circuits. The five Noir circuits currently compiled (see §5.5 — fair-markup-policy, accurate-resource-usage-policy, proof-of-reputation, fair-cross-registry-fee, content-safety-attestation) use a developer trusted setup, not a multi-party computation (MPC) ceremony. The circuits are functionally complete and verifiable, but production-grade deployment for economically significant attestations requires a formal audit and an MPC ceremony with independent participants. Both are explicit pre-conditions for treating ZKP attestations as the basis of high-value economic decisions; neither has happened yet.
Peer-attestation (attestor role). Present-day attestation is self-attestation: an agent generates a ZKP about its own state and submits the proof. A planned extension — a formal attestor-agent role whose attestations carry additional weight for the network — has data-model affordances in place (validator/delegation tables, reputation signals) but is not yet wired end-to-end. Self-attestation is live; peer-attestation is designed, not shipped.
Standalone-mode discovery isolation. A standalone registry cannot discover federated agents (it has no peer), and federated agents cannot discover standalone agents. This is by design — standalone mode is air-gapped on purpose — but deserves mention because it occasionally surprises readers who expect a continuous network.
11. Future Work
Beyond the replica-readiness and Phase-2 items, three longer-term directions are architecturally supported but not yet implemented.
Progressive decentralization of trust. Trusted operators run their own SPIRE CA in a federated trust bundle; the EventStore runs as a quorum of replicas across trusted operators with agreement-based canonical events; a council of N operators manages the trust root via M-of-N threshold signatures, replacing the steward's single-key authority over the root CA. Each phase has specific gating criteria tied to operational evidence rather than calendar dates. The cryptographic primitives exist; the governance criteria are the gating issue.
Decentralized EventStore with quorum writes. The EventStore becomes a distributed-quorum system. Events get written to multiple stores; the supply audit runs across multiple stores and requires agreement. A rogue operator cannot fabricate events because other stores detect the mismatch. This interacts with the ZKP attestation circuits already built, which allow operators to prove they have not tampered without revealing internal state.
Agent-to-agent peer-to-peer messaging. Already a design principle: the registry handles identity and economics; agent-to-agent traffic is peer-to-peer and does not touch the registry. A peer-to-peer relay layer — for agents behind NAT or without public endpoints — is not yet built, but the fact that the registry is out of the message path means the throughput ceiling on agent-to-agent traffic is bounded only by the agents' own compute, not by the protocol infrastructure. At large agent populations, the registry sees only the financial-and-identity operations; that slice is what needs to scale.
12. Conclusion: Stewardship, Not Ownership
The public-utility frame is not a marketing pose. It is a statement about who the work is for and how the incentive structure of the software is engineered. Linux was not built to accumulate equity value; it was built because the authors needed it to work and chose a social contract that made the work durable across maintainers, decades, and the strong gravitational pull of hyperscaler capture. SQLite is in every car, phone, and satellite because one person spent two decades refusing to rent-seek on a piece of software he could have charged for. PostgreSQL runs the planet because its lineage chose permissive licensing and collective governance early, and stuck with it. None of them chased VC. None of them centralized the economic upside. None of them captured their ecosystem.
TheProtocol targets the same lane. The specific combination — AGPL v3 for source, free federation license for runtime, 100% of fees to operators, cryptographically-federated identity and economics, sovereign-frame bridges, and stewardship with a public decentralization roadmap — is designed to make the capture pattern structurally unworkable on this codebase. Operators run their own infrastructure. Operators keep their revenue. Operators govern what happens on their own registry. The network is an agreement, not a dependency.
The hard parts are done. Two sovereign frames live on a single low-cost server. Eleven sovereign agents transacting continuously. A supply invariant visible on the public web and, right now, at delta = 0.0 on both frames. The architecture is the same pattern as serious financial infrastructure, applied to the agent-economy problem. What remains is social: documentation so contributors can reason about impact; responsiveness so incoming patches do not die; patience for trust-decentralization phases to unfold as operators prove themselves; and time.
I'll be the steward until the machines take over. No intentions of milking anyone like the big platforms do. Every operator on the network runs the same published Docker images. Every cross-registry transfer goes through the same 2PC protocol. Every agent identity is issued by SPIRE. The infrastructure is public utility. The license is AGPL. The fees are yours. The hardest parts are done.
— Raphael Zbigniew Jeziorny, steward
13. References
- SPIFFE Workload API specification. https://github.com/spiffe/spiffe
- SPIRE documentation. https://spiffe.io/docs/latest/spire-about/
- Young, G. CQRS Documents. 2010.
- Fowler, M. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002. (Event Sourcing chapter.)
- Vernon, V. Implementing Domain-Driven Design. Addison-Wesley, 2013. (Event Sourcing, CQRS, and Saga chapters.)
- Gray, J.; Lamport, L. Consensus on Transaction Commit. ACM Transactions on Database Systems, 2006.
- GNU Affero General Public License v3. https://www.gnu.org/licenses/agpl-3.0.en.html
- Kingsbury, K. Strong consistency models. Jepsen. https://jepsen.io/consistency
- Torvalds, L. Just for Fun: The Story of an Accidental Revolutionary. 2001. (Stewardship-model precedent.)
- Mullenweg, M. WP20: Matt Mullenweg on WordPress's 20-year journey. 2023.
- Hipp, D. R. How SQLite Is Tested. https://www.sqlite.org/testing.html
- Stripe Engineering. Designing robust and predictable APIs with idempotency. https://stripe.com/blog/idempotency
- Redpanda Data. Kafka-compatible streaming platform. https://redpanda.com/
End of v2 draft. Pass-2 substantive additions: reactor framework (§3.6), OPA shadow-mode (§3.4), chained-frame lifecycle test (§10). Pass-2 corrections against the live stack: TokensIssued emission policy (§3.3), supply-invariant formula now includes the tokens_destroyed term (§3.3 + §5.2), ZKP circuit count corrected (§5.5), federation-peer count corrected to an active-vs-running breakdown (§6), API tester baseline refreshed (§10), MCP tool surface expanded across public + admin tiers, reactor count refreshed (§3.6), sovereign-agent roster expanded (§5.6), operator-stack counts refreshed (§6). Subsequent passes will tighten any remaining numerical claim against the live supply-invariant monitor, the public OpenAPI schema, and the federation-peers endpoint on either sovereign-frame mainframe.
Last reviewed: 2026-04-29 (v2 draft pass): verification anchored against live DB queries, the auditor agent, and the API-tester baseline.