What it is. Sei is a public blockchain built for very high transaction volumes, and everything held on it today is guarded by math that a large quantum computer is expected to break.
What we found. In July 2026 Sei's engineers published the network's first written design for quantum-safe wallets, and three weeks later it had not been put to a vote and had drawn no public reply on the page Sei opened for comment.
Why it matters. A design on paper protects no money, and by Sei's own account this one can only help holders who switch keys early, because anyone who waits until an attacker can impersonate them has waited too long.
Nothing post-quantum runs on any Sei network: mainnet signs consensus with Ed25519 (curve25519-voi, ZIP-215 verification semantics), authorizes Cosmos and EVM accounts with ECDSA secp256k1, and keys peer gossip with ephemeral X25519 through HKDF-SHA-256 into ChaCha20-Poly1305, while an organization-wide code search on 2026-08-19 returned one ML-DSA hit, the proposal text itself, and zero hits for mldsa and Dilithium. SIP-5, Post-Quantum Authorization for EVM Accounts (Draft, created 2026-07-27), specifies ML-DSA-44 per FIPS 204 behind a key-binding registry with SOLO and DUAL activation modes and a governance-set cutoff height H_Q, leaves consensus keys out of scope, and carries the limit its own text states: the first binding of a post-quantum key to an existing account is authorized by that account's classical ECDSA secp256k1 signature, so it defends only accounts that migrate before the attacker arrives, which is why Gate 1a-Sig and Gate 1a-KEM both fail, the mainnet-traffic cap sets a QRI ceiling of 60 that the raw score of 24 never reaches, and Migration Stage holds at 1.
Summary
Sei is a Cosmos-SDK proof-of-stake L1 with parallelized EVM execution on CometBFT-derived consensus, live since the pacific-1 genesis timestamp 2023-05-22T15:00:00Z and EVM-only after the SIP-3 transition, with IBC disabled in both directions on 2026-07-31. The bonded set read on 2026-08-20 returns 40 validators, every consensus key Ed25519. Accounts sign ECDSA secp256k1 on both the Cosmos and EVM side, peer gossip runs ephemeral X25519 with HKDF-SHA-256 and ChaCha20-Poly1305, hashing is SHA-256 and Keccak-256, and all of it is Shor-vulnerable or Grover-weakened. SIP-5 (Draft, 2026-07-27) is the whole delta: ML-DSA-44 per FIPS 204 for EVM account authorization, an algorithm-identifier registry that preserves 20-byte addresses, SOLO and DUAL activation modes, typed transactions at EIP-2718 type bytes 0x70 and 0x71, rotation under proof of possession, and a governance-set cutoff that disables classical EOA authorization. The proposal states its own cost: 2,420 signature bytes, 37.2 times the 65-byte ECDSA secp256k1 signature it replaces, and a 112,236-gas intrinsic floor against 21,000. No client implements any of it, every deployment sub-score stays zero, and announced-versus-shipped moves to 1 and 0. QRI 24, Band 3 Planning, Migration Stage 1.
Forge. Forge-dominant: this chain secures value and operations with signatures, so the principal quantum risk is forgery of spends and attestations once Shor breaks secp256k1 and Curve25519. There is no harvest-now component for forgery, the public key alone enables it, and on Sei the public key is recoverable from any transaction the account has ever sent. Decrypt / HNDL applies to the X25519 gossip handshake and to RPC transport, which is metadata exposure rather than stored-value exposure.
1 announced → 0 shipped on mainnet under a named primitive. none; shipped is zero so the quotient is undefined, and the reported figure is the announced-claim count used as the proxy the rubric thresholds are read against (SIP-5 and its same-window official Sei blog post counted as one coordinated claim). A proxy of 1 sits at or below the 1.5 threshold, so no deduction and no cap fire. The claim is accurately self-labeled: the proposal states it does not by itself make Sei post-quantum secure, carries Draft status, and the blog post frames the mechanism as voluntary, says Sei Labs is not proposing it for immediate implementation, and states plainly that post-quantum signatures would slow every EVM chain. Sei's earlier 2026-01-09 research post is deliberately not counted as a second announced claim: it announces no Sei post-quantum capability or initiative and argues the opposite, that no then-available post-quantum signature fits the throughput target, so counting it would penalize honest engineering disclosure, which is the behavior this metric exists to protect..
What the gates say
- Gate 1a, Hybrid signature: FAIL , no hybrid signature composition is deployed or merged anywhere in Sei spec or code. SIP-5 (Draft, 2026-07-27) documents an account-level AND-composition design, the DUAL activation mode, in which a bound account in DUAL_ONLY mode, that is between its binding's activate_height and the global cutoff H_Q, can originate a transaction only with both a valid recoverable ECDSA secp256k1 signature and a valid ML-DSA-44 signature over the same 32-byte Keccak-256 transaction digest. The gate still fails: the design is a Draft with zero implementation on any network, no governance vote, and no published SUF-CMA-preservation / non-malleability analysis of the combined authorization, and the proposal's own text states that the pre-activation LEGACY_OR_DUAL mode is compatibility and testing, not two-factor security, because a classical-only path remains available until activation. Consequence: QRI cap 60, Stage cap 4.
- Gate 1a, Hybrid KEM: FAIL , the validator and peer gossip channel is the CometBFT-derived SecretConnection in Sei's sei-tendermint tree: ephemeral Curve25519 Diffie-Hellman via X25519, key derivation with HKDF-SHA-256, record encryption with ChaCha20-Poly1305, and peer authentication by signing a 32-byte challenge with the node's Ed25519 key. No hybrid PQ KEM, that is no ML-KEM per FIPS 203 and no X25519MLKEM768-style composition, appears anywhere in that path, so a recorded gossip session is harvest-now-decrypt-later exposed once X25519 falls to Shor. Public RPC endpoints sit behind operator-managed TLS whose negotiated groups are not published by Sei. SIP-5 is an account-authorization proposal that proposes no KEM and says nothing about transport or key encapsulation; its scope statement explicitly excludes migration of consensus, governance, bridge, oracle and contract-level authentication.
- Gate 1b, Commit-to-hash: COND , no OR-composition declared; the composition SIP-5 proposes is account-level AND-mode, and its SOLO mode is a plain replacement, not an OR hybrid
- Gate 2, Evidence reconstruction: PASS , every sub-score reconstructible from public artifacts within 48 hours. The reconstruction set for is: the SIP-5 document in the official Sei improvement-proposal repository, the merged pull request that added it and that pull request's commit metadata, the proposal's public discussion thread, two same-window official Sei blog posts (the SIP-5 announcement and the earlier quantum-exposure research post), the node repository's commit and release history, an organization-wide code search, the pacific-1 genesis file, the live bonded validator set read from three independent public Cosmos REST endpoints, Sei's own EVM and interoperability documentation, and the sei-tendermint p2p and Ed25519 source files
- Gate 3, Primitive naming: PASS , Ed25519 named with implementation and verification semantics, ECDSA secp256k1, X25519, ChaCha20-Poly1305, HKDF-SHA-256, SHA-256 and Keccak-256 named with mechanism for the deployed surface; ML-DSA-44 per FIPS 204 named exactly for the proposed surface, with proposal-only status stated, and FN-DSA named as the deferred candidate whose FIPS 206 is not final
Burn-vs-rescue policy on file
Declared option f, Undeclared. Sei has adopted no policy on value at quantum-vulnerable addresses post-CRQC. SIP-5 (Draft, 2026-07-27) proposes one for EVM accounts: after a governance-set global cutoff height H_Q, classical EOA authorization is disabled network-wide; an unmigrated account keeps its balance, nonce, storage and code and remains a valid transfer and CALL target but cannot originate transactions, a freeze-at-cutoff design rather than a burn (seizure, forfeiture or sweeping of state held by an inoperable account is listed as out of scope), and the design forbids raising H_Q after the cutoff has taken effect and thereby reactivating classical authorization. The proposal states plainly that it cannot securely rescue an account once an attacker can already forge its classical signature, because a last-minute registration transaction can be copied, frontrun, censored or replaced. Draft status, no governance vote, no dates, so the policy remains undeclared.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 31 / 100
The inventory is now complete and artifact-backed across consensus, accounts, transport and hashing, but it is assembled from genesis state, live chain state and source files rather than from Sei's own specification pages, which name none of these primitives. SIP-5 documents the account-layer primitive and its quantum exposure in a first-party formal document, naming ECDSA secp256k1 and its post-Shor forgeability exactly, naming Keccak-256 as the digest every SIP-5 signature covers, and specifying ML-DSA-44 with exact byte lengths and a pinned FIPS 204 context string (ASCII SEI_SIP_5_V1, pure ML-DSA, with HashML-DSA and external-mu interfaces explicitly forbidden). Scored 13 because no Sei-published specification page names the deployed curve, EdDSA parameter set or transport primitives, so a reader cannot build this inventory from Sei's documentation alone.
Ed25519 (validator consensus signing; curve25519-voi implementation with ZIP-215 verification options and a caching verifier) · ECDSA secp256k1 (Cosmos-side accounts) · ECDSA secp256k1 (EVM-side accounts post-v2, recoverable y_parity || r || s form with the low-s rule) · X25519 ephemeral Diffie-Hellman (peer and validator gossip handshake, sei-tendermint SecretConnection) · HKDF-SHA-256 (gossip key derivation) and ChaCha20-Poly1305 (gossip record AEAD) · SHA-256 (hashing) · Keccak-256 (EVM hashing; also the 32-byte digest every SIP-5 signature would cover) · ML-DSA-44 (FIPS 204, NIST security category 2; 1,312-byte public key, 2,420-byte signature), proposed in SIP-5 (Draft, 2026-07-27) as the initial post-quantum algorithm for EVM account authorization; not deployed on any network Deployed surface is entirely Shor-vulnerable or Grover-weakened; ML-DSA-44 appears in the tag map as a proposed primitive only. SIP-5 itself notes the Grover bound that matters for its own design: a targeted preimage attack against a 160-bit truncated address has generic cost about 2^160 classically and about 2^80 under ideal Grover search, which is one reason the proposal states it does not claim a 20-byte registry-backed account is the final post-quantum account model.
Ed25519→ Shor-break-via-DL-without-pairingsECDSA secp256k1→ Shor-break-via-DL-without-pairingsX25519 (gossip handshake)→ Shor-break-via-DL-without-pairings, with harvest-now-decrypt-later exposure on recorded sessionsSHA-256→ Grover-weakenKeccak-256→ Grover-weakenML-DSA-44 (proposed in SIP-5, Draft; not deployed)→ PQ-safe lattice with Grover-caveat, carrying the lattice-confidence discount
Every active primitive sits in classical elliptic-curve discrete log (secp256k1 for accounts, Curve25519 for consensus signing and gossip key agreement) or SHA-2 / Keccak hashing. No lattice, hash-based-signature, code-based, or isogeny family is deployed.
Sei now publishes a per-primitive NIST category mapping in a first-party document. SIP-5's initial profile states ML-DSA-44 is NIST security category 2 under FIPS 204, and documents the rationale for choosing it over FN-DSA, which the proposal correctly describes as lacking a final published FIPS 206 at the SIP's creation and as carrying a more delicate floating-point signing implementation. That description still holds: FIPS 203, 204 and 205 are final (2024-08-13) and FIPS 206 does not appear in NIST's FIPS publication list in any status as of this scoring, so FN-DSA remains selected without a finalized standard. Nothing NIST-PQC-categorized is deployed; the deployed primitives (ECDSA secp256k1, Ed25519, X25519) are classical schemes at roughly the 128-bit classical level with no PQC category. Score 0 to 2: the mapping exists on paper only.
Consensus signing uses curve25519-voi's Ed25519 with VerifyOptionsZIP_215 and a caching batch verifier, which is a deliberate, unambiguous verification ruleset rather than a default library call, and the gossip channel uses standard reviewed Go primitives (curve25519, HKDF-SHA-256, ChaCha20-Poly1305). Against that: no published formal verification of any Sei cryptographic component was located (no machine-checked artifacts), no constant-time audit publication for the Sei tree was located, and the provenance is a fork of upstream Cosmos-SDK and Tendermint rather than an independently reviewed Sei implementation. Cryptanalytic tier 1. The negative findings are absence-of-evidence from, not proof of absence.
2 Quantum Recovery Exposure weight 10% 18 / 100
Every transaction reveals the spending public key (Cosmos accounts and EVM accounts both expose ECDSA secp256k1 pubkeys at first send, and the EVM path uses recoverable signatures so the key is derivable from any transaction); validator Ed25519 pubkeys are public from genesis and are listed in the bonded-validator query. All active stake is forgeable post-Shor. SIP-5's own Abstract restates this exposure model as its motivating threat.
Same exposure model as Ethereum-style EVM and standard Cosmos accounts: once a key has signed, the public key is recoverable from chain data and is Shor-recoverable. No address scheme that hides the public key behind a hash-only commitment is in production, and SIP-5 explicitly defers a zero-knowledge migration proof that would hide a classical public key to a separate SIP.
Historical block signatures (Ed25519) and historical transaction signatures (ECDSA secp256k1) are forgeable under future CRQC. Sei has no checkpoint-anchoring or re-signing protocol declared, and SIP-5 introduces none: it lets an address opt into a new key going forward and states directly that it cannot securely rescue an account after an attacker can already forge its classical signature.
The peer and validator gossip channel establishes session keys with ephemeral X25519 Diffie-Hellman, derives AEAD keys with HKDF-SHA-256 and encrypts with ChaCha20-Poly1305, authenticating peers by Ed25519 signature over a 32-byte challenge. An adversary who records that traffic can decrypt it retroactively once X25519 falls to Shor, which is a genuine harvest-now-decrypt-later channel for mempool and consensus metadata. No hybrid PQ KEM (ML-KEM per FIPS 203 or an X25519MLKEM768-style composition) is present or proposed. Public RPC endpoints are served over operator-managed TLS whose negotiated key-exchange groups Sei does not publish, so their PQ status is unknown rather than classical-by-assertion. Sei's own research post argues the chain holds no encrypted payloads, so the confidentiality exposure is transport metadata rather than stored ciphertext, which is why this dimension is not scored lower.
3 Metadata, Anonymity & Confidentiality weight 13% 28 / 100
Pseudonymous transparent ledger (Cosmos and EVM), with a dual-address system in which the sei1 Bech32 address and the 0x EVM address derive from the same public key, which links the two views of an account by construction. Full transaction graph public via the Seistream and Seiscan explorers that Sei's own documentation and release notes reference.
Sei publishes an RPC-provider directory rather than a single canonical endpoint; three independent public REST endpoints were reachable and stake-consistent on 2026-08-20. Mempool traffic travels the gossip channel described in 2d and is observable in plaintext to any peer that completes the handshake, which includes every validator. No validator metadata-retention policy is declared in published Sei documentation.
IBC is off, not winding down. Sei's own documentation states IBC is disabled in both directions, with governance proposals 116 and 120 setting the ibc module InboundEnabled parameter false and proposal 121 setting OutboundEnabled false on 2026-07-31, leaving the IBC precompile non-functional and stranding already-bridged IBC assets on Sei. The remaining documented cross-chain path is LayerZero V2, for which Sei publishes an integration guide, alongside a thirdweb bridging integration; Wormhole-bridged assets exist on Sei per Sei's own April 2026 holder notices. Cross-chain observers can still correlate flows across these paths, and the stranded IBC balances remain visible and transferable within Sei. One correlation channel is closed; others remain documented and active.
No on-chain encryption primitives whose retroactive decryption would expose more than the transaction graph already reveals. Pseudonymity does not survive post-Shor address clustering on revealed public keys, and the dual-address derivation means a single recovered key deanonymizes both the Cosmos and EVM views of the account, but there is no encrypted note system to retroactively decrypt.
No protocol-level mixing, shuffle, or commit-reveal mechanism on Sei. SIP-5 introduces none; nothing in its scope or specification touches privacy.
4 Migration Architecture weight 10% 65 / 100
Cosmos-SDK provides module-based architecture and coordinated hard-forks, and Sei has shipped several (v2 EVM in July 2024, v6.4 live on mainnet 2026-04-13, v6.5.0 released 2026-05-15, v6.6.0 released 2026-07-31). The signature-scheme switch path was previously undocumented; SIP-5 (Draft, 2026-07-27) now specifies a dedicated algorithm-identifier registry: a one-byte alg_id per scheme (ML_DSA_44_ID = 0x01), an AllowedPQAlgorithms set whose entries may be enabled only after the exact encoding, verification procedure, test vectors and gas schedule are implemented by every consensus client, and an AlgorithmDeprecations map with a governance-notice window G_deprecate. It is explicitly designed so later protocol upgrades can add or retire schemes without replacing the registry format, and it carries two consensus rules that matter: governance must not deprecate the last live onboarding algorithm, and a deprecated binding locks rather than silently falling back to classical authorization. A first-party agility design specific to the chain is credited here. It stops there because the rubric requires a verifiable production instance of the mechanism, and the registry exists only in a Draft document: no code, no testnet, no governance vote.
Two findings set this score. First, the account-abstraction component is now verified rather than assumed: Sei's own EVM documentation states that Sei supports all non-blob transaction types including the Pectra SetCode transaction (EIP-7702), Sei publishes EIP-7702 and account-abstraction integration guides, and ERC-4337 contract wallets deploy unchanged on an EVM-equivalent chain; inherited tooling alone, with no Sei-native AA spec, would not earn this. Second, SIP-5 (Draft) specifies a chain-specific, per-account, opt-in client-layer migration path: a SetPQKeyTx that binds, rotates or replaces a post-quantum key under proof of possession (a signature under the new key) with a monotonic migration_nonce independent of the EVM account nonce, post-quantum and dual EIP-7702 authorization tuples, sponsored registration for unfunded accounts, and a wallet rule that a used EOA must default to immediate activation. Held below the 17 band (AA plus documented path) because the path is paper only, no client implements any of it, and before activation the first binding of a post-quantum key to an existing account is authorized by the account's classical ECDSA secp256k1 signature, so the registration step is forgeable by exactly the attacker it defends against, a limit the proposal concedes by stating that migration must precede the attack. Sei accounts are ECDSA secp256k1, not an RFC 8032 Ed25519 seed scheme, so no seed floor applies, and no rebind bonus is earned: no seed-rebind or hidden-key migration proof exists, and the proposal explicitly defers a zero-knowledge migration proof that would hide a classical public key to a separate SIP.
Coordinated v2 EVM upgrade (July 2024, three phases); SIP-3 merged to the proposal repository 2025-05-07 and executed through on-chain proposals; v6.4 live on mainnet 2026-04-13. Two further mandatory mainnet upgrade releases were published through the SIP-5 window, v6.5.0 (released 2026-05-15 under governance proposal 117, target height 208377745) and v6.6.0 (released 2026-07-31 under governance proposal 122, target height 224201091, carrying the first Giga components Ares and Eidos), patched through v6.6.2 on 2026-08-19, with the Eidos storage-engine migration described on 2026-08-12 as performed while the chain was running. None of these touch cryptographic primitives. Track record of coordinated upgrades is solid for a chain live since 2023-05-22, roughly 39 months, with no contested forks.
Hybrid deployment is now announced and specified, where it was previously only architecturally feasible via Cosmos-SDK module addition: SIP-5's DUAL activation mode is an explicit account-level classical-plus-post-quantum composition in which, in DUAL_ONLY mode between activate_height and the global cutoff H_Q, a bound account's transactions are valid only with both a valid recoverable ECDSA secp256k1 signature and a valid ML-DSA-44 signature, and dual EIP-7702 tuples carry both signatures over one authorization message. The rubric's bar is architecturally possible, not merely announced, and the machinery itself remains on the announced side of that line: the binding registry, typed transactions and consensus verifier are all unbuilt, nothing exists on any network, and no SUF-CMA / non-malleability analysis of the combined authorization is published. The proposal is also candid that the pre-activation LEGACY_OR_DUAL mode is compatibility and testing, not two-factor security, because a classical signature alone can both originate a transaction and authorize replacement of the binding until activation.
N/A, no stateful-hash scheme deployed or proposed; SIP-5's initial profile is ML-DSA-44, a stateless lattice scheme. Default 15/15 for stateless schemes.
N/A. Consensus signing uses Ed25519, which does not aggregate, and Sei has not announced BLS aggregation in consensus. This is first-party rather than inferred: Sei's own 2026-01-09 research post states that Giga uses ECDSA and Ed25519 and, unlike Ethereum, does not rely on BLS or aggregation in any form or on KZG commitments. SIP-5 likewise places signature aggregation out of scope and states that a finite cutoff must not be scheduled on the assumption that non-interactive lattice-signature aggregation will become available. Because 4f is out of scope its weight redistributes: the Dim 4 total is sub-scores 4a to 4e out of 80, scaled to 100. Not scored, so it is left out of the dimension total rather than counted as a zero.
5 Deployment Execution weight 22% 16 / 100
0% PQC signing traffic on mainnet. No post-quantum transaction type exists on any Sei network.
No PQ primitive merged into the sei-chain main branch as of evidence cutoff. An organization-wide code search returns one hit for ML-DSA (the SIP-5 document itself), zero for mldsa, zero for Dilithium, and one for PQAuthTx (again the SIP-5 document). Commit history on main through 2026-08-19 shows storage, RPC, P2P, config and metrics work and no post-quantum work.
Zero validators using PQ keys. The bonded set read 2026-08-20 returns 40 validators, every consensus key of type /cosmos.crypto.ed25519.PubKey.
VOIDED to 0 per v3.1 (5a = 0). SIP-5 defines three activation stages (registration support, migration, global cutoff) but attaches no date, height or governance calendar to any of them, and makes each stage conditional on prerequisites that do not yet exist.
Announced 1, shipped 0. The announced claim is SIP-5 plus its same-window official Sei blog post, counted as one coordinated public PQ claim naming ML-DSA-44 (FIPS 204); shipped is zero mainnet bytes under any PQ primitive. With shipped at zero the quotient is undefined; the announced-claim count is the proxy read against the thresholds, and 1 sits at or below 1.5, so no rubric deduction and no cap fire. Two points come off because the announced-to-shipped delta is no longer zero: a public Sei PQ claim now exists against zero shipped bytes. The remainder is credited because the claim is accurately self-labeled: the proposal's own text states it does not by itself make Sei post-quantum secure and carries Draft status, and the blog post says Sei Labs is not proposing it for immediate implementation, describes a user-chosen pace, and concedes that post-quantum signatures would slow every EVM chain.
A scheme is now selected: SIP-5 names ML-DSA-44 and discloses the footprint with exact figures: 2,420 signature bytes per post-quantum transaction, 37.8 times the 64-byte Ed25519 signature and 37.2 times the 65-byte recoverable ECDSA secp256k1 signature, which sits at the top edge of the 10-38x rubric band; RLP-encoded, the authentication fields occupy 2,446 bytes. The 1,312-byte public key is held once in the binding registry rather than carried per transaction, at a cost of at least 1,330 raw bytes of permanent state per binding and at least 1.33 GB per million bindings. The proposal adds a per-block cap on authentication bytes (MaxPQAuthBytesPerBlock) and an illustrative intrinsic gas floor of 112,236 gas for a simple post-quantum transfer (21,000 base, plus 2,446 authentication bytes at 16 gas each, plus a 50,000-gas ML-DSA-44 verification charge, plus a 2,100-gas binding read) against the 21,000 intrinsic gas of a classical transfer, and 116,292 gas for the dual-signed case, a fee penalty rather than the fee de-penalization the rubric credits. The proposal quantifies the cost honestly, noting that at 200,000 transactions per second signatures alone would require approximately 484 MB per second before encoding, propagation, erasure coding or replication overhead, explicitly declines to assume non-interactive lattice-signature aggregation will exist, and names the need for a different throughput mechanism without specifying one. Scored 3 rather than the band's 5 because nothing is deployed, no batching, data-availability offloading or fee-recalibration design exists, and the disclosure lives in a Draft proposal.
6 Supply Chain Vendor Readiness weight 22% 5 / 100
The Cosmos-era wallet set (Compass Wallet, Keplr, Leap Wallet) is stale after the SIP-3 EVM-only transition. Sei's current first-party recommended-wallet table lists MetaMask, Backpack, Binance Wallet, Dynamic, Privy, Rabby, OKX and Gem Wallet as software or embedded wallets, and Ledger as the hardware wallet, with Compass still named in a quickstart prerequisite line. No published PQC roadmap was found for any of them. Spot checks of the Keplr and Compass sites on 2026-08-20 returned no post-quantum or PQC mention; the remaining vendors were not individually swept. SIP-5 does specify what wallets would have to support (ML-DSA-44 key generation and protected backup, proof-of-possession generation, sponsored and self-paid registration, mode and activation-height selection, PQAuthTx signing, key rotation), but that is a requirement placed on future wallet behavior, not evidence of any vendor commitment.
IBC is disabled in both directions per Sei's own documentation and governance proposals 116, 120 and 121, with outbound disabled 2026-07-31. The documented remaining paths are LayerZero V2, for which Sei publishes an integration guide, and a thirdweb bridging integration; Wormhole-bridged assets are attested by Sei's own 2026-04 holder notices rather than by an integration page. No PQC roadmap is published by any of them, a finding not re-verified vendor by vendor since 2026-05-01.
No unnamed placeholder custodian is counted, and neither BitGo's nor Fireblocks' Sei support was verified. What is first-party verifiable is that Ledger Enterprise added Sei support (announced on the official Sei blog, 2026-02-27) and that Sei publishes Ledger hardware-wallet setup guides for both the EVM and Cosmos paths, and that Sei publishes a dedicated guide for exchanges and custodians covering the EVM transition. No custodian with Sei support was found to publish a PQC roadmap or to operate mainnet-deployed post-quantum MPC or threshold signing; this negative was not re-swept custodian by custodian and is the weakest-evidenced finding in this card. 6c scores 1 because the absence of deployed post-quantum custody signing across the industry is well established even where this specific sweep was not run.
Sei publishes an RPC-provider directory rather than naming a top three in a form we could read statically; three independent public Cosmos REST endpoints were reachable and mutually consistent on 2026-08-20, so multiple providers demonstrably serve the chain. Validator key custody follows the standard Cosmos priv_validator_key.json pattern with the usual HSM options; no post-quantum HSM, TEE attestation scheme or PQ-protected RPC transport is published for Sei, and the gossip transport itself is the classical X25519 handshake described in 2d. The vendor-by-vendor infrastructure sweep was not re-run.
7 Governance & Coordination weight 8% 33 / 100
40 bonded validators; Nakamoto coefficient 9 at the one-third stake threshold, computed on 2026-08-20 directly from the bonded validator set returned by three independent public Cosmos REST endpoints, all returning identical sets and stake totals, rather than from a third-party tracker. The figure is taken from first-party sources reporting identical sets and stake totals rather than from a third-party tracker, so it is not directly comparable with a single-tracker reading. Held low because a 40-validator set running a single canonical node implementation remains concentrated on both the stake and the client axis.
v2 (July 2024, three phases), v6.4 live on mainnet 2026-04-13, v6.5.0 2026-05-15 and v6.6.0 2026-07-31, each a mandatory mainnet upgrade carried by an on-chain governance proposal with a published target height. Coordinated upgrades have shipped on schedule with no contested forks. 9: none of this cadence has ever been exercised on a cryptographic primitive change, which is the load the PQ migration would impose.
Sei Foundation, the US-based Sei Development Foundation and Sei Labs are the named organizational actors. A named Sei Labs protocol researcher, Benjamin Marsh, published a first-party technical quantum-exposure analysis on the official Sei blog on 2026-01-09. That same person is a named author of SIP-5, alongside Maja Lie, with Philip Su as named reviewer, all listed with official Sei Labs email addresses, and the proposal-repository pull-request and commit metadata corroborate the authorship independently of the document's own byline. Named post-quantum ownership at Sei is therefore continuous across at least seven months and two artifact types. Named post-quantum ownership is credited here. It stops at 12 because this is an author-and-reviewer trio, not a standing PQ working group with a published mandate, budget or charter; the proposal is unratified; and its public discussion thread carries zero comments as of 2026-08-19.
No precedent of coordinating a cryptographic change under an active attacker. There is a precedent of coordinating a contested non-cryptographic change: the SIP-3 discussion thread carries 12 public comments including sustained opposition arguing that removing CosmWasm and Cosmos support dismantles Sei's original design, alongside asset-holder questions about migration mechanics that Sei answered with dated holder notices and a migration guide. Contested, executed, but not adversarial in the cryptographic sense, so it does not evidence the capability this sub-score measures.
No canary, no rate-limit-on-spend, no cryptographic tripwire embedded in consensus. SIP-5 does require that the cutoff-notice parameter G_cutoff_notice be enforced at the consensus level rather than by process, on the stated grounds that a process recommendation is not sufficient protection, and requires that a reduction of that parameter itself be announced under the old value; that is a governance safeguard for a future mechanism, not a live tripwire, and none of it is implemented.
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
This card dates historical signature exposure from the pacific-1 genesis file, which records genesis_time 2023-05-22T15:00:00Z. The date widely repeated for Sei's public mainnet launch is 2023-08-15, and the earliest pacific-1 governance proposals archived in the official network repository are dated 2023-08-11, which is consistent with a public phase beginning in August. We could not corroborate 2023-08-15 from a first-party Sei artifact, and Sei's own foundation copy says only that Sei launched its mainnet in 2023. We therefore use the genesis timestamp, which is the conservative choice for forgeability of historical signatures and the only date backed by a primary artifact.
Sei's user-facing documentation does not name the validator signature scheme on any page, including the consensus and Giga architecture pages. The primitive is nevertheless directly verifiable rather than inferred: the pacific-1 genesis file lists 25 genesis validators, all with pub_key type tendermint/PubKeyEd25519; the live bonded set read 2026-08-20 returns 40 validators, every consensus_pubkey of type /cosmos.crypto.ed25519.PubKey; a merged node-repository pull request (2025-12-09) removed secp256k1 and sr25519 validator-key support with the stated rationale that Ed25519 is the only enabled validator key scheme on pacific-1; and the implementation is curve25519-voi's Ed25519 with ZIP-215 verification options. This is a documentation gap, not an evidence gap, and it is recorded so a reader who searches Sei's docs and finds nothing knows why.
Verified to 'July 2024' from Sei's own posts, which state that v2 went live in July 2024 and that in July 2024 Sei Labs announced v2 was stable with RPCs, bridges, indexers and multisigs ready, but no exact day is given in those first-party sources. The rollout ran in three phases and the stability announcement followed a May 2024 phase post.
The SIP-5 document names ML-DSA-44, FIPS 204, and exact key and signature byte lengths; the official Sei blog post announcing it (2026-07-28) never names an algorithm or standard, describing only post-quantum signature schemes that are many times larger. Not a factual conflict, but copy drawn from the blog post alone would under-specify the primitive; the proposal document is the load-bearing technical source. Independent press coverage dated 2026-07-28 corroborates the date and states that the proposal remains open for discussion through governance and precedes any implementation decision; that coverage does not contain the phrase 'no implementation timeline established', so this card does not attribute that wording to it.
Sei's 2026-01-09 research post transposes FIPS 204 parameters, describing 'the signature length for the smallest parameter set (2420) is 1312 bytes'. In FIPS 204 the ML-DSA-44 signature is 2,420 bytes and the public key is 1,312 bytes; SIP-5 itself states both correctly. We record this because a reader cross-checking Sei's own material will hit the inconsistency, and because this card follows the SIP and FIPS 204, not the blog arithmetic.
Named post-quantum ownership at Sei predates SIP-5. A named Sei Labs protocol researcher published a first-party technical quantum-exposure analysis on the official Sei blog on 2026-01-09, and that same person is a named author of SIP-5. The stage and 7c readings rest on those two first-party artifacts.
The Nakamoto coefficient is measured directly rather than taken from a third-party tracker: the bonded validator set was read on 2026-08-20 from three independent public Cosmos REST endpoints, all returning an identical 40-validator set and identical stake totals, from which the Nakamoto coefficient at the one-third stake threshold computes to 9. This is a data refresh, unrelated to the PQC delta, and is not evidence about Sei's quantum posture.
Delta-QRI under alternative weighting
Weighting sensitivity, computed from this card's own sub-scores. Under the published L1 weights the QRI is 23.85, rounded to 24. Inverting the Dim 4 and Dim 5 weights (migration architecture 0.22, deployment execution 0.10) gives 29.7, the top of Band 3 Planning. A deployment-heavier weighting (deployment execution 0.30, migration architecture 0.02) gives 19.9. That spread is the Sei story: paper architecture scores Dim 4 = 65 on SIP-5's registry, rotation and DUAL-mode design plus first-party-documented EIP-7702 support on the EVM side, while deployment scores Dim 5 = 16 with every shipped-code sub-score at zero, which is why the Architecture-Execution Gap Cap fires. Migration Stage stays 1 under every weighting, because Stage is gated on deployment evidence that does not exist.
Announcement-to-shipped ratio
Announced: 1. Shipped: 0. Ratio: 1.
Tag: none; shipped is zero so the quotient is undefined, and the reported figure is the announced-claim count used as the proxy the rubric thresholds are read against (SIP-5 and its same-window official Sei blog post counted as one coordinated claim). A proxy of 1 sits at or below the 1.5 threshold, so no deduction and no cap fire. The claim is accurately self-labeled: the proposal states it does not by itself make Sei post-quantum secure, carries Draft status, and the blog post frames the mechanism as voluntary, says Sei Labs is not proposing it for immediate implementation, and states plainly that post-quantum signatures would slow every EVM chain. Sei's earlier 2026-01-09 research post is deliberately not counted as a second announced claim: it announces no Sei post-quantum capability or initiative and argues the opposite, that no then-available post-quantum signature fits the throughput target, so counting it would penalize honest engineering disclosure, which is the behavior this metric exists to protect.
Peers in the L1 profile
9 chains closest to Sei by Stage then QRI.