Skip to main content
SPECIFICATION

Specification and benchmarks.

Reference data behind the claims on the technology page: measured signing and verification cost, key and signature sizes, the governance cadence those numbers support, and the standard each primitive implements. Every figure here is reproducible from the published reference implementation. Hybrid figures describe the implemented, cross-verified composite profile, a first-class selectable profile; classical Ed25519 is AGA's zero-dependency operational default.

Test environment

CPU
AMD Ryzen 5 3550H
OS
Windows 11
Toolchain
Go 1.26.1
Method
go test -bench

Commodity laptop silicon, not server hardware. Production deployments on contemporary server CPUs see lower per-operation cost. The numbers below are the conservative case.

Signing and verification performance

OperationAlgorithmns/opB/opallocs/op
SignEd2551933,85000
SignML-DSA-65202,8003,9064
SignHybrid264,3003,8144
VerifyEd2551978,43000
VerifyML-DSA-6540,66033,2825
VerifyHybrid121,1004503

Ed25519 signs in roughly 34 microseconds with zero allocations. ML-DSA-65 carries the larger cost the post-quantum scheme implies, and the hybrid mode runs both, so its cost is close to the sum.

Key and signature sizes

ComponentEd25519ML-DSA-65HybridRatio
Public key (raw)32 B1,952 B1,992 B62.3x
Signature (raw)64 B3,309 B3,381 B52.8x
Public key (hex)643,9043,98462.3x
Signature (hex)1286,6186,76252.8x

Post-quantum keys and signatures are roughly 50 to 60 times larger than their classical counterparts. That size, not speed, is the practical cost of the migration, and it informs bundle storage and transport planning.

Governance cadence feasibility

CadenceWindowHybrid sign+verifyDecisions/windowFeasible
100ms100,000 us385 us259Yes
200ms200,000 us385 us519Yes
500ms500,000 us385 us1,298Yes
1000ms1,000,000 us385 us2,597Yes

Hybrid sign-and-verify totals roughly 385 microseconds per governance decision. At the fastest supported cadence (100 ms), that overhead sits at about 0.4% of the measurement window, so the cryptography is never the bottleneck.

Standards and provenance

AGA introduces no new cryptography. Every primitive is a published standard, and the post-quantum scheme is pinned to NIST known-answer vectors with two independent implementations shown to agree byte-for-byte.

PrimitiveStandardRole
SHA-256FIPS 180-4Artifact addressing and receipt chaining
Ed25519RFC 8032Classical signatures and the reference baseline
ML-DSA-65FIPS 204Post-quantum signatures at NIST Level 3
Composite (ML-DSA-65 + Ed25519)IETF LAMPSHybrid signing profile
JSON Canonicalization (JCS-lineage)Vectors-definedByte-reproducible signature inputs
Merkle treesNo-prefix SHA-256 (RFC 6962 lineage)Checkpoint anchoring; truncation-safe via the signed checkpoint
BLAKE2b-256RFC 7693Alternative hash for high-frequency measurement

Receipt specification

The governance receipt schema, canonicalization rules, signing and chain-linking construction, the evidence-bundle format, and the steps a conformant verifier runs. This is the format the benchmarks above measure.

Governance Receipt (15 fields)

FieldTypeDescription
receipt_idstringUnique receipt identifier (UUID)
receipt_versionstringSchema version ("1.0")
algorithmstringSigning algorithm identifier
timestampstringISO 8601 UTC timestamp
request_idstring | number | nullMCP request identifier (type preserved)
methodstringMCP method ("tools/call")
tool_namestringName of the tool being called
decisionstringPERMITTED or DENIED
reasonstringHuman-readable decision rationale
policy_referencestringSHA-256 hash of policy configuration
arguments_hashstringSHA-256 of canonical arguments (tri-state)
previous_receipt_hashstringChain link to previous receipt
gateway_idstringSigning gateway identifier
signaturestringEd25519 signature (128 hex chars)
public_keystringEd25519 public key (64 hex chars)

Canonicalization (JCS-lineage)

All JSON serialization uses a JCS-lineage JSON Canonicalization Scheme, defined by the conformance vectors rather than literal RFC 8785:

  • Object keys sorted by Unicode code point order
  • No whitespace outside string values
  • ECMAScript Number.toString() for number serialization (1.0 becomes 1)
  • Negative zero normalizes to positive zero
  • Array element order preserved (not sorted)

Signing and Chain Linking

SigningDigest: Canonical JSON of receipt WITHOUT the signature field. Ed25519 signature computed over these bytes.

ChainDigest: SHA-256 of canonical JSON of receipt WITH the signature field. Used as previous_receipt_hash in the next receipt.

arguments_hash tri-state: absent arguments = empty string, empty object = SHA-256("{}"), content = SHA-256(canonicalize(arguments)).

Evidence Bundle Format

An evidence bundle packages a receipt chain with Merkle proofs for offline verification:

FieldDescription
schema_versionBundle format version ("1.0")
bundle_idUnique bundle identifier (UUID)
algorithmAlgorithm suite ("Ed25519-SHA256-JCS")
generated_atISO 8601 bundle creation timestamp
gateway_idSigning gateway identifier
public_keyEd25519 public key (64 hex chars)
policy_referenceSHA-256 of policy configuration
receiptsOrdered array of GovernanceReceipt objects
merkle_rootSHA-256 Merkle root of receipt leaf hashes
merkle_proofsInclusion proofs for each receipt
offline_capableBoolean (always true)

Six-Step Verification (SEP Gateway)

1. Structural floor

Verify the algorithm identifier ("Ed25519-SHA256-JCS"), public key well-formedness, and that every receipt matches the strict schema. Fail closed on unknown algorithms.

2. Receipt signatures

For each receipt: remove signature field, canonicalize, Ed25519 verify against public_key.

3. Chain and ordering

First receipt: previous_receipt_hash = "". Each subsequent: previous_receipt_hash = SHA-256(canonical(prev receipt WITH signature)); timestamps non-decreasing.

4. Merkle and bijection

Walk each proof from leaf to root via sibling hashes; constant-time compare to merkle_root. Proof count = receipt count, leaf indices a bijection over 0..N-1.

5. Signed checkpoint

Verify the gateway-signed checkpoint anchors the recomputed Merkle root, leaf_count, and chain head leaf hash.

6. Envelope consistency

The bundle's stated roots match what was recomputed. Each proof's leaf_hash = SHA-256(canonical(receipt WITH signature)).

A seventh check, gateway key match, runs only when the verifier is given a pinned issuer key: it confirms the bundle was signed by that key (provenance). Without a pin, the six checks prove integrity only.

Algorithm Identifiers

IDSignatureHashCanonicalization
Ed25519-SHA256-JCSEd25519 (64-byte signature)SHA-256 (32-byte digest)JCS-lineage

Additional algorithm suites may be defined in future versions. Verifiers must reject unknown algorithm identifiers (fail closed).

Cross-Language Conformance

Implementations across three independent toolchains (JavaScript, Python, Go) are checked against a shared conformance suite, including a standalone verifier that uses no third-party cryptography:

TypeScript

MCP Gateway (Cloudflare Workers)

conformance + unit suite

Python

SDK (PyNaCl)

conformance + unit suite

Go

Verifier CLI

cross-verify all bundles

Independent Verifier

Standalone verification tool

cross-language conformance

57 classical cross-stack cases prove identical verdicts across six verifier configurations; the spec's canonical vectors pin byte-for-byte canonical output and matching Merkle roots; the post-quantum profile adds 28 composite cases across two independent-language oracles.