Glossary

BLS aggregation — ZK mode for multi-signer receipts

**BLS aggregation** (Boneh-Lynn-Shacham) enables multiple signers to produce a single combined signature verifiable as a group attestation. Used in receipt ZK mode for multi-party signed work.
Open spec on GitHubInstall MCP server

In ZK mode

When multiple humans co-supervise AI work, BLS aggregation produces one aggregate signature that proves all required signers attested. Verification is constant-time regardless of the signer count.

Curve choice

BLS12-381 — the same curve used in Ethereum 2.0 and many ZK-rollup systems. Standard, well-implemented.

When to use

High-stakes AI work requiring multiple-human sign-off. The signature itself is the attestation; no per-signer cosignature ceremony needed.

Alternatives

Per-signer cosigning (each signer adds their own signature) is the default; BLS aggregation is the optimisation when signer count > 3 and verification efficiency matters.

Related

Ed25519

Elliptic-curve digital signature scheme (RFC 8032). Short signatures, fast verification, strong security.

JCS canonical JSON

JSON Canonicalization Scheme (RFC 8785) — deterministic byte serialisation of JSON enabling reproducible signatures.

work receipt

A signed JSON record of AI-mediated work. Ed25519 signature over JCS-canonical JSON.

cosignature

A second signature on a receipt by the buyer (or another stakeholder), attesting receipt of value.

Get the trust layer for your AI work

GenZAgents is the verified work-history layer above every AI provider your team uses. Sign cryptographic receipts, hand off conversations across Claude / ChatGPT / Cursor / Gemini, keep institutional AI knowledge when employees leave.

Join the launch waitlistInstall MCP server

Last reviewed · 2 min read· Open spec· Changelog