Cryptographic assumptions
SEAL uses PLONK over BN254 and a Poseidon commitment forest. Settlement, transfer, withdrawal and account-only circuits have immutable verification routes and keys. Account checkpoints improve freshness detection; they do not make proof soundness or encrypted delivery post-quantum secure.
Proofs and setup
The universal SRS file is pinned by SHA-256 and upstream provenance in the phase-one manifest seal-pool/packages/circuits/scripts/powers-of-tau.json. Run npm run check:srs to check the file's integrity, or npm run verify:srs -- .local/phase1-independent to perform full cryptographic verification and retain a fresh record. See verification instructions.
Independent review of SEAL's final circuit relations, compiler transformations, compact prover and optimized verifier remains pending. That is a separate protocol release requirement; it is not a missing universal setup verification or a requirement for a new SEAL-specific ceremony.
PLONK uses the Perpetual Powers of Tau universal structured reference string. Circuit keys are derived from it without a separate contribution ceremony for each circuit. Security still requires a correctly verified setup with an honest contributor who destroyed its secret, along with sound circuits, transcripts, prover randomness and verifier implementation. Universal does not mean transparent. Runtime hashes identify implementations; they cannot establish cryptographic soundness or exclude mutable dependencies behind a proxy. Deployment policy requires immutable verifiers.
Poseidon and Merkle binding
SEAL uses the pinned circomlib Poseidon instantiation over BN254 for tree nodes, note commitments, nullifiers and spending key hashes. The full parameters and encodings are specified in the protocol specification.
The Ethereum Foundation's Poseidon Initiative records suspension of its Poseidon1 collision prize in August 2026. That primary source does not establish that every use of Poseidon was abandoned, or that SEAL's distinct parameters are broken or proven safe. Changes in roadmap selection are not a substitute for cryptanalysis of the exact deployed function.
A Merkle tree does not make an insecure hash secure. Its binding relies on the relevant collision and second preimage resistance of the chosen construction. Some attacks weaken one property without breaking every other property; that is an attack specific distinction, not a blanket exemption for tree hashing. MD5 must not be used where collision resistance is required. See RFC 9162 and RFC 6151.
Quantum security
BN254 proof commitments, X25519 envelope key exchange and ECDSA account signatures depend on elliptic curve assumptions that are not secure against a sufficiently capable quantum computer. An observer can retain encrypted notes today for potential decryption after a future break of key exchange. Replacing future proofs would not protect that historical ciphertext. NIST overview.
This is also an ecosystem problem. Ethereum uses BLS validator signatures and classical account signatures; Bitcoin uses elliptic curve transaction signatures, including BIP 340 Schnorr signatures. Making SEAL's local primitives post quantum would not by itself secure its host chain. Partial improvements may still reduce specific risks. The Ethereum Foundation's September 2026 priorities target December 2029 for full quantum resistance, with contingency work for reduced guarantees. It is a roadmap target, not a guaranteed completion date. No SEAL behavior depends on it. See Ethereum PQ research.