Signatures
BLS12-381 today. SLH-DSA and ML-DSA at Phase 3.
Problem
Which signature scheme does the chain use, and how does it migrate? The answer has to be defensible today and convergent on a post-quantum destination.
Solution
BLS12-381 today. Hybrid in Phase 2. SLH-DSA / ML-DSA at Phase 3.
| Phase | Validator consensus | Account / high-value |
|---|---|---|
| Phase 1 today | BLS12-381 aggregate | Ed25519 |
| Phase 2 hybrid | BLS12-381 + hash commitment | Ed25519 + hash commitment (high-value) |
| Phase 3 PQ | PQ aggregate (research) | SLH-DSA · ML-DSA |
Phase 2 hybrid construction: each high-value transaction (governance call, escalation trigger, resolution waterfall execution) carries both a classical signature and a hash-based commitment to the same payload, with verification requiring both. Phase 3 destination: SLH-DSA (FIPS 205) for high-value operations end-to-end, ML-DSA (FIPS 204) as an alternative for performance-sensitive operations.
Discussion
The hardest single migration in the project is the validator-consensus aggregate signature. Classical BLS gives us aggregate signatures that scale to large validator sets. PQ aggregation is harder and the existing schemes are larger and slower. The interim approach in Phase 2 is acceptable; the destination in Phase 3 is research-active and the cookbook makes no promise about exactly which aggregate primitive ships.
See Also
- § 3.2 · Proof Systems — the proof-side of the same migration
- § 6.5 · Re-attestation Under Primitive Change — what the migration looks like from the holder's seat