signer — a generic threshold-signature organism

audience: ai

This example walks a generic threshold-signature organism — an organism that takes a message from a requester, produces a t-of-n threshold signature across a committee of providers with varying attestation levels, and commits the signature on a public surface consumers gate their own TicketValidators against. Design inspired by zipnet and inverted: where zipnet decrypts, this organism signs.

The scenario the example exercises: a market of signature providers with variable levels of attestation competing for ticket-validator admission. Some providers run software-only. Others run TDX-attested. Others run TDX with bidirectional RA-TLS and a reproducible-build root whose hash binds the binary. Consumers compose a TicketValidator clause that admits signed outcomes only when the participating providers’ aggregate attestation clears a declared floor; providers below the floor are ignored without being expelled.

The organism lives in its own small coalition, signer-δ, and is generic over the message type M: SignableMessage (exactly as zipnet is generic over D: ShuffleDatum).

What the organism demonstrates

• Inverse-of-zipnet shape. Zipnet decrypts sealed broadcasts; signer produces signatures. Both are threshold-committee organisms with the same surface shape: a typed request stream, a typed outcome collection, a committee ACL, a generic message parameter.
• Scheme polymorphism. A single signer deployment commits to one SignatureScheme. The supported schemes include BLS12-381 (G1 and G2), FROST Schnorr (secp256k1 and ed25519), FROST ECDSA, and classical Shamir-Lagrange. Two signer instances that differ only in scheme derive distinct organism ids.
• Attestation variance. Unlike zipnet (uniform MR_TD across the committee), the signer organism’s committee tolerates providers at different attestation levels. The organism’s min_attestation_level is a floor; providers above the floor register; consumers gate above the floor at their own discretion.
• Competition on attestation + capacity + price. Providers publish ProviderCards carrying their supported schemes, declared attestation level, Measurements digest, capacity, and fee per partial signature. Consumers and the organism’s scheduler select providers from the card collection.

Why this example is in the book

The three earlier Part II examples exercise three roles that together describe most of the coordination-market surface: consumer (web3), provider (web2), publisher (oracle). The signer example adds the fourth role that the other three do not directly exercise: a threshold committee organism whose value to every consumer is the signature it produces, and whose internal structure is a market of competing members.

• web3 shows an AI agent consuming a lattice and a coordination market.
• web2 shows a provider competing in a coordination market.
• oracle shows a publisher whose trust model reduces to one Measurements set.
• signer shows a committee-internal market where providers compete on attestation and the organism’s output is a threshold signature consumers gate their admission against.

The signer-δ shape

• Coalition. signer-δ — a one-member wrapper around the signer organism, matching the oracle-γ and searcher-α patterns.
• Primary member. One standalone organism — the signer, generic over M: SignableMessage. Its Config folds the scheme, the threshold, the minimum attestation level, the committee DKG public-key digest, and the message type tag.
• Member market. Committee membership is itself a market: providers register as ProviderCards and compete for inclusion in the next committee-rotation window. Consumers that care about the market read the ProviderCard collection directly (provider-reads).

What runs where

A consumer that requires TdxRemote or higher will accept outcomes only when at least t of the participating providers carry a matching or stronger level. A consumer willing to accept Software-level providers will admit anything. Admission is consumer-side; no central authority re-computes it.

Chapters

1. Setup and shape — Config, scheme selection, committee formation, the signer-δ coalition wrapper.
2. Binding consumers — how a consumer references the signer organism, composes a TicketValidator with an attestation floor, and verifies signatures.
3. Reading the provider market — the ProviderCard collection, the attestation ladder, consumer-side provider selection.
4. Wrapping attestation surfaces — how a provider ships each attestation level: software declarations, TDX quotes, RA-TLS bidirectional, reproducible-build roots.
5. Partial-signing in the committee — the request flow: message digest in, partial sigs out, committee-internal reconstruction.
6. Aggregate and publish — how partial signatures combine into the final aggregate and how the SignatureOutcome is committed to the public surface.
7. Committee rotation, key refresh, successor chain — proactive DKG refresh, committee-member replacement, retirement markers.

Register and non-goals

• Register. audience: ai — dense, pattern- forward, code-forward where a shape is load-bearing. Every section cites the Rust types in examples/signer/ where they are defined.
• Non-goal. Not a threshold-cryptography primer. BLS, FROST, and GG18 have their own literature; this example specifies only the organism’s composition shape on mosaik. Where a protocol detail is load-bearing (non-interactive vs. interactive scheme, nonce-commit rounds) the chapter names it and links out.
• Non-goal. Not a catalog of every signature scheme worth supporting. The SignatureScheme enum lists a useful representative set; a production deployment extends it by republishing the organism under a new Config.
• Non-goal. Not a settlement or payment design. Provider fees are a declared field; the book pins the shape (fee_per_partial_wei) and stops short of specifying settlement rails.

Cross-references

• zipnet book — the threshold-committee organism this example inverts.
• Part I — emergent coordination — attestation fabrics — the pattern this example instantiates.
• Part II — oracle overview — the closest kin: single-trust-anchor organism vs. variable-trust-anchor committee.
• Part II — web2 overview — the provider-market analog; the signer-δ’s ProviderCard and the bridge-β’s ProviderCard are structurally the same shape.
• The coalition crate — the data-model crate every Part II example imports from.