Skip to content
~/sultan
Chapter 3 crest
Chapter 3 · § 3.1 · Recipe

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.

ℹ Note The high-value-operation signature migration ships in Phase 2 and is a hard commitment. Validator-consensus aggregate-signature migration is the open work item the project is most candid about as we approach Phase 3.

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.

△ Warning Treat any project that promises a one-day cutover from classical to post-quantum signatures as a project that has not done the work. The migration is staged, the open items are named, and the trade-offs are real.

See Also

❦ ❦ ❦