Building the Fourth Protocol
How we implemented WARD (content-free hash-chain witnessing) to complete the Quox trust stack. From spec to running code in a single session.

Reason
AgentsQuoxMindAgentic TeamsMirrorQuoxLensRemember
QuoxMemoryBrain2CompoundingQuoxPlanCodebase MirrorAct
QuoxFlowQuoxEngineQuoxAgentQuoxChatAutonomyRun
EnterpriseOrganisationsPowers & ToolsmithQlusterQuoxBastionInterfaces
QuoxMCPQuoxCLIQuoxTerminalQuox ConsoleQuoxBoxGovern
HITL ApprovalsQuox SecurityAgent HonestyQuoxVaultAI GovernanceAgentic AIProve
For AuditorsVerifiable AI OpsLoggingEU AI ActCompliance SuiteChannels
Matrix RoomsDiscord ProTelegram ProQuoxSignalCoreCommsAll products A-ZBuild
QuoxProofDeveloper KitPlugin SDKBring your tool to QuoxQuoxpertQuoxSkillsQlarityShip and sell
Build and sellBrowse MarketplaceDownloadsProtocolsDev Suite
Dev ServersQuoxBuildQuoxSlotsShared Skills + RulesDev workflow
RepoBrainGripeTriageFixLoopProofLoopDoneEngineAll products A-ZGet started
OverviewArchitectureProtocols
AEEAOCLVOLTWARDReference
GlossaryAPI ReferencePlugin SDKDockerAll products A-ZHow we implemented WARD (content-free hash-chain witnessing) to complete the Quox trust stack. From spec to running code in a single session.

Update, 31 August 2026: the filing happened. draft-cowles-ward is live on the IETF datatracker, filed together with the refreshed AEE, AOCL and VOLT drafts; the full story, including the defect a pre-filing audit caught and fixed, is in The fourth draft: WARD is at the IETF. Everything else below describes the March 2026 implementation as it shipped.
Quox already had three protocols working in production. AEE wraps every agent message in a structured envelope. AOCL runs every action through an 11-layer governance pipeline. VOLT records everything in a tamper-evident hash chain.
But a question remained: who watches the watcher? VOLT proves what happened, but what independently proves that VOLT recorded it? If someone with database access silently deleted a VOLT entry, how would you know?
That is what WARD solves. It is the tamper-evident seal on the tape.
The critical design constraint: WARD stores zero bytes of event content. Only identifiers, payload hashes, and chain hashes. This means WARD databases can be shared with external auditors, published to append-only storage, or replicated across jurisdictions, without leaking any operational data.
{
"source_kind": "AEE",
"source_id": "ENV_20260308_A1B2C3",
"payload_hash": "a1b2c3d4e5f6...",
"chain_hash": "f7e8d9c0b1a2...",
"prev_chain_hash": "previous entry hash"
}The WARD spec recommends a sidecar deployment pattern. We chose to embed the witness hooks directly inside the collector service instead. This keeps the container count unchanged and the latency overhead at near-zero: each hook call is fire-and-forget, non-blocking, and isolated from the source pipeline.
AEE storeEnvelope() ──── wardHookAEE() ────┐
AOCL decision ──────── wardHookAOCL() ───┤
│
▼
ward.db (SQLite)
/var/lib/quox/ward.dbA key invariant: WARD failures must never affect the source pipeline. If the WARD database is corrupted or the disk is full, AEE envelopes and AOCL decisions continue to flow normally. The hooks are wrapped in try/catch with a non-blocking promise chain.
Every AEE envelope and AOCL decision that flows through the collector now gets a WARD receipt. Here is what a typical chain looks like: each entry linked to its predecessor by hash. ward:org/quox/env/production, 5 entries.
| # | Source | ID | Hash |
|---|---|---|---|
| 1 | AEE | ENV_20260308_A1B2 | a1b2c3d4... |
| 2 | AOCL | DEC_20260308_E5F6 | e5f6a7b8... |
| 3 | AEE | ENV_20260308_C9D0 | c9d0e1f2... |
| 4 | VOLT | EVT_20260308_G3H4 | g3h4i5j6... |
| 5 | AOCL | DEC_20260308_K7L8 | k7l8m9n0... |
| Item | Status | Description |
|---|---|---|
| Witness Service | Done | SQLite storage, SHA-256 chain hashing, uniqueness enforcement |
| Integration Hooks | Done | Fire-and-forget AEE + AOCL hooks in the collector |
| REST API | Done | 8 endpoints: stats, chains, entries, tips, verify, breakdown |
| Dashboard View | Done | Full WardView page with stats, entry list, detail panel, verify |
| Summary Card | Done | Dashboard widget showing receipts, chains, tips, integrity |
| IETF Draft | Filed | draft-cowles-ward-00 filed 31 August 2026 and live on the datatracker, alongside the refreshed AEE, AOCL and VOLT drafts |
| Tips & Signing | Done (Aug 2026) | Periodic checkpoints with Ed25519 signatures, meta-chain witnessing, and publication to external sinks |
| Verify CLI | Done (Aug 2026) | Standalone ward-verify running the 5-step verification algorithm, a distinct failure code per broken condition, and tip-signature checking |
With WARD live, Quox now has four protocols forming a complete trust layer, from message identity through governance, evidence, and independent witnessing. No other AI agent platform has this.
| Layer | Name | Description | Status |
|---|---|---|---|
| Layer 2c | WARD | Content-free hash-chain witnessing | NEW |
| Layer 2b | VOLT | Tamper-evident evidence chains | LIVE |
| Layer 1 | AOCL | 11-layer governance pipeline | LIVE |
| Layer 0 | AEE | Agent message envelopes | LIVE |
Alongside the implementation, we drafted draft-cowles-ward-00, a 1,626-line xml2rfc v3 document covering chain structure, cryptographic primitives, the 5-step verification algorithm, 7 failure codes, 3 conformance levels, and an 8-threat threat model. It was written as the fourth Quox Internet-Draft, joining AEE, AOCL, and VOLT.
*Updated twice in August 2026: first to record that this draft had not been filed and the other three had been withdrawn ahead of launch, then on 31 August, when all four were filed together. draft-cowles-ward is live on the datatracker with AEE, AOCL and VOLT at their -01 revisions, current to 4 March 2027.
The full story of the filing, including the defect the pre-filing audit caught, is in The fourth draft: WARD is at the IETF.*
The position as of March 2026. See the August 2026 update below it.
Two phases of the WARD stream are still ahead. Tips and signing (W2) will add periodic chain checkpoints with Ed25519 signatures and external sink publishing, so the proof survives even if the host is compromised. The verify CLI (W3) will implement the full 5-step verification algorithm with 7 failure codes, giving auditors a standalone tool to validate any WARD chain.
After that, the focus shifts to connectors (bridging the 419-credential Vault catalog to real tool execution via MCP servers) and VOLT Certification Tiers, the category-defining trust seal for AI agents.
Updated August 2026: both WARD phases have since shipped. Tips are created on an interval, signed with Ed25519, witnessed into a meta-chain and published to external sinks. ward-verify is a standalone CLI that runs the full 5-step algorithm, reports a distinct failure code per broken condition, and checks tip signatures against a supplied public key.
Open protocol specifications. No vendor lock-in, no proprietary formats. Implement them yourself or use QuoxCORE.