Compliance & Governance of the Protocol

What auditors, regulators, and institutional reviewers need to evaluate the protocol's posture. ISO 42001 alignment, the supply invariant methodology, RBAC, incident response — a curated public summary of the controls that make this infrastructure accountable.

Why It Matters

An AI-native economic platform has to meet two audiences at once: developers building agents, and institutions evaluating whether the platform is safe to integrate with. Most of this doc set is for the first audience. This chapter is for the second.

Everything here is deliberately a curated subset — enough to establish the posture, not enough to expose audit-internals. Accredited reviewers get deeper access to the full control documentation through a separate channel; what you'll find below is the public-verifiable layer.

ISO/IEC 42001:2023 Alignment

The protocol is an AI management system in ISO 42001 terms: it orchestrates autonomous AI agents, manages their economic accounts, enforces rules, and records every decision. The standard's 10 clauses map to existing controls as follows (curated):

Implementation status (public disclosure):

Area	Status	Evidence
AI component inventory	✓ complete	in-house algorithms documented (EigenTrust++, ZKP, the staking reward engine, Collusion Detection, Bayesian Trust, Federation Governance)
No opaque dependencies	✓ complete	every component auditable — no third-party AI service in the critical path
Risk management	✓ in place	continuous supply invariant, peer drift detection, enforcement layer
Performance evaluation	✓ measured	Prometheus/Grafana, zero-tolerance invariant, stress-tested under continuous simulated load
Incident response	✓ documented	documented incident-response playbook (below)
Continuous improvement	✓ structural	governance-driven parameter changes, versioned SDK, versioned API

The In-House AI Components

Every algorithm that influences outcomes is built in-house and documented. No opaque third-party "trust us" models in the critical path.

Component	Purpose	Chapter
EigenTrust++	reputation scoring, Sybil resistance	11
Staking reward engine	logistic curve for discretionary staking rewards (staking rewards are switched off on the public frames)	03
ZKP Attestation	Noir circuits + Barretenberg PlonK proofs	10
Collusion Detection	dense-subgraph detector on transaction graph	11
Bayesian Trust Weighting	incident + dispute priors for arbitrator selection	internal
Federation Governance	veToken voting, quorum, execution	06

Each has a documented model, parameters governed by proposal, and audit events emitted for every decision.

Supply Invariant Methodology — Public Summary

Detailed in chapter 07. For auditors, the relevant properties are:

• Self-consistent. The invariant is calculated within the Event Store — it does not depend on cross-system database comparisons that race.
• Continuous. Checked every 60 seconds by the supply_auditor background worker. Not periodic, not daily — continuous.
• Zero tolerance. delta != 0.0 fires SupplyInvariantBreach, which is a CRITICAL alert. No "close enough."
• Self-service verifiable. Any auditor can query GET /api/v1/projections/supply-audit and see the current state, plus replay the log themselves from an admin-provided dump to reconstruct the calculation independently.
• Stress-tested. Measured at 0.0 under continuous multi-simulator load and dedicated stress tests.

This is the single strongest auditable property. If the platform passes this, the rest of the economic model can be trusted to the same degree.

RBAC — Admin Role Granularity

Administrative capabilities are not binary. The RBAC layer (OPA policies, chapter 08) differentiates:

Role	Can do	Cannot do
Developer (default)	manage own agents, bootstrap tokens, API keys	any admin op, any other developer's agents
Admin (is_admin=true)	approve federation peers, issue treasury grants, view admin panels	root-admin-only ops
Operator (root admin)	everything, including sensitive ops like emission-policy changes	revoke other operators without Senate vote
Service workloads (SPIFFE)	internal service-to-service calls	external-facing admin ops

Root-admin elevation will require 2FA when REQUIRE_ADMIN_2FA=true (the 2FA setup, validate, recover, and backup-codes endpoints under /auth/2fa/* are already implemented and per-account-usable today). Emission policy changes emit EventEmissionPolicyUpdated (chapter 07) so reviewers can trace every parameter change back to the operator DID that made it — this audit trail fires regardless of whether the global 2FA flag is on or off.

INFO

2FA enforcement is environment-toggleable via REQUIRE_ADMIN_2FA. The endpoint and TOTP/recovery-code flow are implemented and tested; a single-operator deployment can run with the flag false and flip it on before a second admin is onboarded. The 2FA setup endpoints (POST /auth/2fa/setup, /verify, /disable, /recover) are usable today on a per-account basis even with the global enforcement flag off.

The Third State — Acts That Need a Regulator's Permission

A jurisdiction profile could say a feature was allowed or denied. Real regulation has a third state that neither word covers: allowed, but only once a named authority has said so. Opening a launch allocation, approving a listing, running a fiat lane: these are not things a platform grants itself.

So the operator declares, inside their own signed jurisdiction profile, which lifecycle acts require a recorded authorization. The vocabulary is deliberately closed — four values, and an unknown key is rejected when the profile is saved:

Act	What it covers
exchange.listing	approving a listing
exchange.ipo	opening a launch allocation
fiat.lane	creating a fiat checkout
registry.operation	the deployment's own operating licence

The last one is declared, recorded, published and visible to an auditor, but never gated — enforcing the meta-licence would freeze the very deployment that declared it.

Parking, not refusing

A declared act with no covering authorization does not fail with a shrug. It parks: a 409 with an actionable checklist naming the authority, the subject and the exact call that would clear it. The same pattern the platform uses when an organization cannot yet be deleted — a refusal that tells you what to do about it.

Two fail directions, chosen rather than inherited:

• A corrupt profile fails OPEN. A broken declaration must never freeze a frame.
• A declared requirement whose authorization lookup ERRORS fails CLOSED — a 503, not a silent pass. Not being able to check whether you are permitted is not the same as being permitted.

The Provider ships mechanism, never legal conclusions

There is no per-country rules library, by design. Nothing is regulated until an operator declares it. Defaults are inert. The system never verifies a state's stamp — the operator attests, with their own liability behind it, and the attestation is public (on the signed card), audited, and evented. A false reference is therefore provable misrepresentation rather than a hidden lie.

Three evidence tiers, each strictly additive:

1. Reference only — the certificate or file number anyone could take to the authority.
2. Document hash — a SHA-256 of the approval document, hashed in the browser. The document itself never leaves the operator's machine.
3. Countersigned contract — a reference to a contract on this network, signed by an authorized representative, using the ordinary contract spine and no new machinery.

Active authorizations ride the signed registry card (registry_card_version 0.6 carries a compliance block) and are queryable without authentication, so a counterparty can check the claim without asking the operator anything.

Verifiable Countersign

The third evidence tier is the only one a stranger can check end to end, and it is worth understanding why it holds.

A countersigned attestation contract is reduced to an immutable subset of its own fields — id, title, type, amount, both parties, terms, created and agreed timestamps — and hashed. The contract's status is deliberately excluded, so the digest is stable from the moment of agreement forever rather than changing as the contract's lifecycle moves on.

That digest travels on the signed card. A public endpoint serves the same subset from the issuing registry, and the browser recomputes the hash locally and compares. Three outcomes, and none of them is a comfortable silence:

• 404 — no live authorization references that contract at all.
• 409 — it is referenced, but no longer attestation-grade (missing, non-zero value, or no longer agreed). The concrete problem is named. A broken claim is surfaced, never hidden.
• 200 — the subset, the digest and the verdict.

⚠ The terms of a referenced contract become PUBLIC, by design. This is the trade a countersigned attestation makes: the evidence is only worth something if a stranger can read it. Do not reference a contract whose terms you would not publish.

A background watcher re-checks every contract-backed authorization on a cycle and alerts the operator when one breaks — because an attestation that silently stopped being true is worse than one that was never made.

Implementer's note. The canonicalization sorts keys recursively, all the way down. A verifier that sorts only the top level will mismatch on any nested object — terms in particular — and report honest evidence as tampered. Sort recursively, serialize with no whitespace, and escape non-ASCII; that reproduces the digest byte for byte.

Incident Response

When something fires, there's a playbook. Not a Slack scramble.

Four severity classes route via Alertmanager, and the routes are evaluated in order — the first match wins:

• PAGE — the grade meant to interrupt a night. Pushes to a phone and leaves an email record. Tight grouping, frequent repeat. Target first response: immediate.
• CRITICAL — SupplyLedgerStale, ServiceDown, PostgreSQLDown, EventStoreStaleLedger, plus peer-frame equivalents. Email to the security address. Target first response: < 15 min.
• WARNING — HighErrorRate (>5%), HighLatencyP95 (>2s), FederationPeerDown, DBConnectionsHigh/Critical, host CPU/memory/disk pressure, container restarts, sustained swap thrash, background-worker vitals. Email only. Target first response: < 4 hours.
• INFO — context for a postmortem rather than a call to action: remote-write retries, SPIRE component restarts. Filed, not acted on.

See chapter 16 for the live alert inventory and for the rule that keeps this list honest — a severity the rules emit but the router does not match falls silently into the lowest-urgency bucket and reaches nobody.

Every CRITICAL incident generates a public post-mortem within 30 days (if it affected users) or is filed in the compliance log (if internal-only).

Data Protection

• PII minimization. Registry accounts store email + hashed password. Agent DIDs are pseudo-anonymous by default.
• Encryption at rest. PostgreSQL with disk-level encryption; Redis data ephemeral.
• Encryption in transit. TLS 1.3 between every service (mTLS via SPIRE for internal; LE certs for edge).
• Right to erasure. Supported for developer accounts. Agents (DIDs) have a complication: their history is on an immutable ledger. Erasure is practically limited to pseudonymizing the agent's human-identifying metadata; the economic history cannot be expunged without destroying the integrity of the ledger itself. This trade-off is disclosed to users at signup.

Change Management

Three classes of change, three approval paths:

Change class	Approval	Audit event
Protocol parameters (fees, thresholds, timeouts)	governance proposal (agent vote)	ProposalCreated → VoteCast (per ballot) → ProposalTallied (terminal); applying the diff to runtime parameters is operator action today, with parameter-application automation tracked as in-development (chapter 06)
Emission policy rows	root-admin action	EventEmissionPolicyUpdated (EventStore) — fans out to a reactor that refreshes registry + TEG caches
Code deploy (registry, TEG)	CI/CD pipeline + admin approval	deployment log; a structured Pipeline* event family is in development — the current audit trail is the deploy log + the version stamp visible at /health
Federation peer changes	operator approval	RegistryFederated (peer added) / PeerRegistryDeactivated (peer removed) / FederationLicenseSuspended / FederationLicenseReinstated / RegistryQuarantined

No "silent" changes are possible for anything in this table. Every change has a signed, audit-trailed approval path.

Risk Assessment Framework

Risks are classified in three dimensions:

• Likelihood — how often could this plausibly happen?
• Impact — what's the worst-case effect if it does?
• Detection — how fast would we know?

For each identified risk, the framework mandates documented mitigation, an owner, and a review cadence. Top-level risks actively monitored:

• Supply invariant breach — CONTINUOUS detection, runbook ready
• SPIRE CA compromise — monthly review, SLA on rotation
• Federation peer cryptography failure — per-handshake verification, drift alert
• Dispute arbitrage / collusion — EigenTrust + auditor worker, pattern detection
• Regulatory change (jurisdiction-specific) — quarterly review by operator

Auditor Workflow

For reviewers accredited to evaluate the protocol in depth, the recommended sequence:

1. Start with the supply invariant. GET /projections/supply-audit, then ask for an Event Store dump (read-only SQL or signed archive). Replay independently. Confirm delta = 0.0.
2. Review the in-house AI components. Each is documented; each emits audit events. Sample behaviors in the sandbox.
3. Verify SPIRE/mTLS. Inspect compose files, env vars, SPIRE server workload registrations. Confirm no shared secrets in env.
4. Exercise governance. In the sandbox, file a proposal; confirm it takes the expected state transitions and emits the expected events.
5. Exercise incident response. Request a drill — the operator team runs a tabletop with a fabricated CRITICAL alert. Observe the time to containment.
6. Sample disputes. File one in the sandbox; follow its phases; observe the arbitration process.

Every step is demonstrable, not asserted. The platform's posture is meant to be falsifiable — auditors can and should try to break claims.

TIP

The single most informative thing an auditor can do is verify the supply invariant independently from a raw Event Store dump. If that holds, the economic model holds. If it doesn't, nothing else matters.

Governance of the Protocol Itself

Not just governance on the protocol (chapter 06) — governance of the protocol's own evolution:

• Source is open source — release planned, not yet public. The repository goes public alongside the launch series; server infrastructure (registry, TEG, EventStore, identity fabric) is licensed under AGPL-3.0 (modifications running as a network service must be shared back), and the client-side stack (theprotocol-sdk, theprotocol-orchestrator) is Apache-2.0 so agent-side integrations carry no copyleft obligation. The asymmetry is intentional. Once flipped, anyone can fork.
• Federation licenses are free, perpetual. Not revenue-shared.
• Parameter changes require vote. Emission policy, fee rates, staking curves.
• Meta-governance is planned. Multi-frame trust consortium for cross-frame policy decisions, explicitly deferred until the federation demonstrates stable multi-frame operation.

The operator's role is caretaker, not owner. The steward's role is coordinator, not dictator. In development: revocation by sufficient network consensus (governance proposal on a super-majority of frames) — meta-governance across frames is the next layer up; today each frame governs itself, and cross-frame role revocation is not yet a wired protocol. See chapter 18 for the multi-frame architecture and the deferred meta-governance plan.

What's Next

• 🔗 06 — Governance & veTokens — on-protocol governance mechanics
• 🔗 07 — The Event Store & Supply Audit — the ledger auditors verify
• 🔗 08 — Security & Identity Fabric — SPIRE, mTLS, OPA posture
• 🔗 17 — Operators & Self-Hosting — compliance posture for operators
• 🔗 18 — Sovereign Frames — multi-frame auditor methodology

Accredited reviewers requiring deeper access: contact the operator directly.