Three distinct proof systems on L1: SGX, SP1, RISC0, composed since Unzen by ZkRequiredVerifier (exactly two sub-proofs, at least one from SP1 or RISC0). Previous in-house Halo2-based ZK-EVM circuits explicitly deprecated per Raiko README. The reduction is not a new weakness but a wider unlisted surface: Unzen activated Prague and Osaka EVM semantics at one timestamp, putting two further classical asymmetric primitive families on mainnet, and both were verified live by direct call on 2026-08-20 (BLS12-381 G1ADD at 0x0b returns the 128-byte point at infinity for infinity plus infinity; P256VERIFY at 0x100 returns 0x..01 for a valid secp256r1 signature on chain 167000). Taiko published no consolidated cryptographic inventory naming them, and publishes none for the rest of the stack either; this list is reconstructed from contract source, release notes, the mainnet L1 contract log and the 2026-07-23 postmortem, which names the RSA-3072 MRSIGNER key and the DCAP debug-attribute check. An in-repo analysis (added 2025-10-08) models a Grover-speedup adversary against the 208-bit truncated Keccak-256 comparison, estimates about 2^104 quantum iterations against about 2^208 classical, and concludes no change is required; it is analysis of one design choice, not a PQ inventory or plan.

0 PQ families deployed at user/consensus signature layer. Proof-system layer hosts FRI-based STARK primitives (PQ-safe at soundness) but they are wrapped in a BN254 pairing-based SNARK, so the on-chain verification path is Shor-vulnerable end-to-end.

No NIST FIPS 203/204/205 PQC primitive deployed by Taiko Labs.

On 2026-06-21 the proof-verification path was forged in production. Three defects chained: the RSA-3072 key behind MRSIGNER, held in docker/enclave-key.pem, had been committed to the public raiko repository; the on-chain SgxVerifier accepted DCAP quotes from debug-mode enclaves, whose memory including the in-enclave signing key in reportData is host-readable; and the Inbox measured a proposal's age from a timestamp carried inside the proof, so an attacker able to forge proofs could forge the age and trigger the five-day permissionless-proving exception (permissionlessProvingDelay is 5 days in the mainnet Inbox config). Forged SGX Geth plus SGX Reth attestations then satisfied the then-live MainnetVerifier, which accepted a TEE-only pair with zero ZK proofs, and finalized a fake state. A second defect found in the same review: the third-party-owned attestation entrypoint was Ownable and its owner could have pointed quote verification at a permissive verifier, a full attestation bypass. Neither defect was caught by the OpenZeppelin Shasta re-audit (report dated 2026-01-19, audit window 2025-12-15 to 2025-12-24: 0 critical, 0 high, 0 medium, 3 low all resolved, plus 3 notes of which 2 resolved and 1 partially) or the 2024-03 Code4rena contest. Credit retained for the response: the on-chain remediation ran on the June timeline through DAO proposals, and the eventual repository fix is broad, adding DEBUG-enclave rejection, a fail-closed MRENCLAVE/MRSIGNER allowlist enforced by default, a per-network TCB policy fixed in bytecode rather than settable by an admin, a per-MRENCLAVE ATTRIBUTES pin, monotonic policy versioning so a remove-then-re-add cannot silently revive stale instances, non-payable registration, and an optional registrar; the attestation trust root moved to a Taiko-owned Automata DCAP v1.1.0 instance, disclosed as not byte-for-byte the v1.0 baseline Trail of Bits audited in 2025-02; a scoped Daybreak/Codex audit of SgxVerifier.sol and SecureSgxVerifier.sol is committed in-repo with its single medium finding resolved; an OpenZeppelin incident-response review on 2026-06-25 found no critical, high or medium issues; and Unzen made the ZK mandate structural. The debug-enclave rejection was not merged 2026-06-22/23. The two same-week pull requests carrying it were closed unmerged on 2026-06-23; the fix reached the v3.0.0 protocol line on 2026-07-01, ten days after the exploit. No machine-checked formal proofs of verifier contracts; no reproducible-build evidence tying deployed verifiers to audited source. Cryptanalytic tier mix: Tier 1 (ECDSA secp256k1 and secp256r1, RSA-3072, Keccak-256, SHA-256), Tier 2 (BN254 and BLS12-381 pairings), Tier 4 (SP1/RISC0 prover ecosystems).

EOAs use ECDSA secp256k1; pubkey revealed on first transaction. Canonical bridge escrow magnitude per the 2026-07-23 postmortem: about USD 1.75M drained on 2026-06-21, composed of about 295.972 ETH, USDC and other stablecoins, and about 1.99M TAIKO; 991 ETH in the Bridge and about 108.5M TAIKO in the ERC20Vault, together about USD 11M, were never reached; the escrow was recollateralized 1:1 from Foundation and Taiko Labs operating cash with no locked or unvested tokens touched. Current TVL/TVS is not verified here.

Mainnet live since May 2024 (about 27 months at evaluation). No new dormant-balance disclosure found.

Validity-proof verification on L1 uses BN254 pairing-based SNARK wrappers around SP1/RISC0 STARK proofs, plus SGX attestation signatures rooted in Intel's RSA-3072 and ECDSA P-256 attestation chain. Both surfaces Shor-vulnerable. Sequencer-side signatures inherited from Ethereum L1 proposers (based-rollup property). Unzen's two-sub-proof rule with a mandatory zkVM proof removes the SGX-only finality path against a classical key compromise but does not change the quantum case: a CRQC forges the BN254 wrapper and the SGX attestation alike. The 2026-06-21 incident is a realized classical forgery of exactly this surface (forged withdrawal proofs against the Bridge and ERC20Vault).

The Taiko-operated public RPC endpoint was probed directly on 2026-08-20: TLS 1.3, X25519 ECDHE key agreement, AES-256-GCM or ChaCha20-Poly1305 depending on client preference, rsa_pss_rsae_sha256 certificate signature. Both IETF hybrid post-quantum groups tested, X25519MLKEM768 and SecP256r1MLKEM768, were rejected with TLS alert 40. No hybrid PQ KEM anywhere in Taiko's documented RPC stack.

Pseudonymous transparent EVM ledger, chain ID 167000, explorer Taikoscan. Full tx graph public.

Based-rollup design delegates ordering to Ethereum L1 proposers, but block production is now gated: permissionless proposing and permissionless proving-by-age were disabled on 2026-06-22 as incident response and, per the Proposal0019 specification, deliberately not restored by Unzen; the permissionless-preconfirmation runtime was removed from the Rust client on 2026-07-15 in favour of the whitelist driver; and the docs list PreconfWhitelist and ProverWhitelist contracts on mainnet. Forced inclusion via L1 was re-enabled at Unzen, with due inclusions (older than the 576-second forcedInclusionDelay) that proposers must process or their proposal reverts, which preserves a censorship-resistance entry point. On transport concentration, Taiko documents exactly one public mainnet RPC endpoint, which it operates itself; a claim that public RPC concentrates among Alchemy, Infura and QuickNode is not supported by any source and is not carried. No validator-metadata retention policy published.

The canonical Taiko Bridge produces direct on-chain linkage between L1 and L2 addresses, and Taiko's own bridging documentation covers only that canonical path. Third-party bridges are known to serve the route, but no specific vendor list could be corroborated from any primary source, so none is carried.

No shielded pool on Taiko Alethia. ECDSA Shor-breaks address pseudonymity once linked to identity off-chain.

No on-chain mixer integrated.

Type-1 Ethereum-equivalent inherits Ethereum's crypto-agility surfaces by design, and Unzen demonstrated that inheritance by activating Cancun, Prague and Osaka semantics at one timestamp (2026-08-06 13:00:00 UTC per taiko-geth v2.6.0), against an attribution of EIP-7702 to Shasta (mainnet about 2026-04-07). Proof-layer agility is now demonstrated in production: the Unzen DAO bundle replaced MainnetVerifier with ZkRequiredVerifier, rotated four SP1 verification keys, two RISC0 image IDs and three SGX MRENCLAVE values, and deleted the pre-Unzen SGX instance registrations, in 22 actions inside one L1 transaction. MRSIGNER was left unchanged. The verifier composition itself is immutable on the Inbox and needs an implementation upgrade, so it changes by fork, not by calldata. Type-1 equivalence means Taiko cannot ship a user-signature-scheme change unilaterally; EIP-7932 and EIP-8141 were both still Draft on Ethereum as of 2026-08-20.

Account abstraction is present and verified, not merely inferred from Ethereum equivalence: the ERC-4337 EntryPoint contracts at the canonical v0.6, v0.7 and v0.8 addresses all return deployed bytecode on Taiko mainnet (chain 167000, checked by eth_getCode on 2026-08-20), and EIP-7702 is live via Prague semantics since the Unzen activation of 2026-08-06. That makes a PQ migration through a smart account verifying ML-DSA-44/65/87 per FIPS 204 or SLH-DSA per FIPS 205 architecturally tractable. No Taiko-specific client-layer PQ migration is documented or deployed, so the score stays where it was; the added evidence firms the basis for the existing credit rather than earning more.

Coordinated upgrade record over trailing 24 months: mainnet launch May 2024, Ontake hard fork (audited by OpenZeppelin November 2024), Pacaya hard fork (2025, superseded by Shasta), the Taiko Alethia naming carried in protocol release tags from 2025-02-04, Shasta architecture on mainnet about 2026-04-07 (protocol v3.0.0), emergency incident-response bundles Proposal0016 through Proposal0018 (2026-06-22 to 2026-06-30), Unzen hard fork (Proposal0019, DAO execution 2026-08-03, L2 activation 2026-08-06). DAO plus Security Council governance. No contested or stalled forks.

ERC-4337, EIP-7702 and the multi-prover architecture make a hybrid (classical plus PQ) verification path architecturally constructible. ZkRequiredVerifier is a ComposeVerifier: it hardcodes the accepted two-verifier combinations in areVerifiersSufficient, so adding a PQ-safe on-chain wrapper as a further slot alongside SGX Geth, SGX Reth, SP1 and RISC0 means shipping a new ComposeVerifier subclass through the same DAO proposal-and-upgrade pattern Unzen used, not a configuration change. No such hybrid spec'd.

Default-pass per v3.1 rule. No stateful hash scheme.

N/A, Taiko Alethia is a based rollup; ordering is delegated to Ethereum L1 proposers and validity is established via the multi-prover stack. No BFT consensus with BLS signature aggregation at the Taiko layer.

Zero PQ signatures observed in the Taiko Alethia transaction stream. The multi-prover stack verifies on chain through BN254 pairing-based SNARK wrappers, which are not PQ.

Code search across every taikoxyz repository re-run 2026-08-20 for ML-DSA, ML-KEM, SLH-DSA, dilithium, sphincs, falcon512, XMSS, quantum-resistant and post-quantum returned zero implementation hits. The single hit of any kind is a documentation file, the InboxOptimized1 truncation analysis, which evaluates a Grover work factor and recommends no change. No ML-DSA, ML-KEM, SLH-DSA, Falcon, XMSS or SPHINCS+ implementation exists in taiko-geth, taiko-client, taiko-alethia-client-rs, raiko or taiko-mono.

Based rollup uses Ethereum L1 proposers as sequencing layer; since 2026-06-22 proposing, proving and preconfirmation are whitelist-gated, and the replacement SGX prover instances were registered at Unzen by the admin.taiko.eth registrar Safe with validity running to 2027-08-03. All of these operator keys are classical ECDSA secp256k1; provers (SGX, SP1, RISC0) operate on Intel attestation roots and zkVM proof keys, none PQ.

VOIDED to 0 per v3.1 (5a = 0). No PQ milestone exists to void in any case: DAO Proposal0016 through Proposal0019 cover incident recovery and the Unzen fork, and Proposal0019's own specification document lists only verifier rotation, forced-inclusion restoration and the ZK mandate. None of the four proposal bodies references PQ, ML-DSA, ML-KEM, SLH-DSA or quantum.

Trailing 12-month PQC announcement count from Taiko Labs/Taiko DAO channels: 0. Shipped PQ on mainnet: 0. No gap between announcement and delivery because there is nothing on either side of it.

Voided per Gate 2, no PQ signature deployed.

Taiko publishes no wallet allowlist; because the chain is Ethereum-equivalent, any wallet that works on Ethereum works on Taiko unmodified, so the wallet tile is the general Ethereum wallet population rather than a Taiko-specific set, and no named top-three could be sourced. The one dated post-quantum capability found anywhere in this tile is hardware-side: Trezor Safe 7 verifies its bootloader and firmware with what Trezor names 'SLH-DSA-128' at every power-on and applies the same scheme to firmware updates and device authentication. Two precision caveats for that credit: Trezor names only 'SLH-DSA-128' and does not state which FIPS 205 parameter set it uses (128s or 128f, SHA2 or SHAKE), and the scheme protects device and firmware integrity, not transaction signing, which remains ECDSA secp256k1. An ML-DSA-44 device-attestation attribution is not supported by Trezor's product page and is not carried. No wallet vendor publishes a Taiko-specific PQ signing roadmap.

The canonical Taiko Bridge and ERC20Vault were the target of the 2026-06-21 forged-withdrawal-proof incident: about USD 1.75M drained through 39 forged withdrawal messages of which 36 paid out. The tile's flagged exposure, a forged proof or key moving escrowed funds, has now occurred classically. Restored controls are live on-chain and merged in the public repository on 2026-06-23: a designated pauser role for Bridge and SignalService, Ether and ERC20 withdrawal quotas via QuotaManager, and SignalService versioning so no prior state transition can be used to withdraw. No PQC roadmap is published for the canonical bridge. Third-party bridge vendors serve this route but no named list could be corroborated, so none is carried; the tile is scored on the canonical bridge, where the evidence is primary. Quotas bound the rate of a forge, they do not prevent it.

The named-custodian list cannot be verified: its lead entry is a placeholder rather than a named vendor, and the accompanying trade-press claim that custodians are piloting quantum-resistant key migration is unattributed. Neither can be sourced, so neither is carried. What is left: no custodian publishes a dated post-quantum key-migration roadmap covering assets held on Taiko mainnet, and no dated custodian-side artifact of any kind was found for this chain. The tile is an evidenced absence, not a verified readiness position in either direction.

The RPC third of this tile lost its evidence: Taiko documents one public mainnet endpoint, which it operates, and an Alchemy/Infura/QuickNode top-three could not be sourced. That endpoint was measured on 2026-08-20 to reject both hybrid ML-KEM key-exchange groups. The HSM leg holds and is now precise: AWS KMS supports the ML_DSA_44, ML_DSA_65 and ML_DSA_87 key specs per FIPS 204 with the ML-DSA-SHAKE-256 signing algorithm, a generic cloud-HSM capability not bound to Taiko; a 2025-06 ship date for it could not be confirmed and is not carried. Intel SGX remains in Taiko's multi-prover (SGX Geth and SGX Reth verifiers) but since Unzen it is no longer an independent finality path: every accepted proof pair contains at least one zkVM proof and SGX plus SGX is structurally rejected. SGX attestation roots remain classical (ECDSA P-256 attestation key, RSA-3072 enclave-signing key, Intel PCK certificate chain); the on-chain attestation entrypoint moved in mid-2026 from a third-party-owned Ownable instance to a Taiko-owned Automata DCAP v1.1.0 instance after a full-bypass risk in the third-party owner key was identified, with the residual gap disclosed (v1.1.0 is not byte-for-byte the v1.0 code Trail of Bits audited in 2025-02). No RPC provider, HSM vendor or TEE vendor publishes a Taiko-relevant RSA-to-PQ attestation roadmap.

Based rollup, ordering delegated to Ethereum L1 proposers, but since 2026-06-22 permissionless proposing and permissionless proving-by-age are disabled and, per the Proposal0019 specification, deliberately not restored at Unzen; preconfirmation runs whitelist-only. The active proposer and prover sets are therefore permissioned. Multi-prover client diversity persists (SGX Geth, SGX Reth, SP1, RISC0; exactly two sub-proofs per accepted proof with at least one from a zkVM). Security Council of nine with a 7-of-9 threshold for emergency execution.

24-month track record of coordinated upgrades through DAO governance: Ontake (2024), Pacaya (2025), Shasta (about 2026-04-07), Unzen (2026-08-03 execution, 2026-08-06 activation). Under pressure, per the postmortem's own timeline: the attack began 2026-06-21 19:04 UTC, automated alerts fired about 23 minutes later at 19:27, funds began leaving at 22:07, seven of nine Security Council signatures were collected by 2026-06-22 04:37, the Bridge and ERC20Vault were paused at 05:40, permissionless proving and proposing were disabled the same day, recovery hooks merged 2026-06-23, the chain was restored to its pre-attack state 2026-06-29 and the bridge reopened 2026-07-02. Unzen was then proposed to the DAO 2026-07-07, approved by the Security Council 2026-07-14 and executed 2026-08-03. Audit pre-commitment via OpenZeppelin re-audits and a 2026-06-25 incident-response review. Held below full credit because the root-cause repository fix did not merge until 2026-07-01.

Taiko Labs is the named protocol-development entity; co-founder Daniel Wang is publicly identified as CEO and co-founder in Taiko-published material and holds a Security Council seat under the Taiko Labs profile. Taiko DAO operational with a nine-member Security Council (7-of-9 threshold for emergency execution per the 2026-07-23 postmortem). No designated PQ lead.

A dated precedent now exists: with an attacker actively forging proofs on 2026-06-21, the DAO and Security Council paused the bridge about eleven hours after the first fraudulent proof, disabled the permissionless proving path the attacker had exploited, changed the attestation-verification logic (reject debug-mode enclaves, rotate SGX instances and MRENCLAVE values, move the attestation trust root to a Taiko-owned entrypoint), invalidated the retriable forged withdrawal messages the attacker had proven but not yet executed, rolled chain state back to a pre-attack checkpoint, recollateralized the escrow and reopened under quotas, all through public, individually dated on-chain proposals, then made a zkVM proof structurally mandatory at Unzen. This is coordination of a cryptographic-verification change under live attack. It is not a primitive migration, it leaned on a nine-member council and on whitelisting, and the root-cause fix took ten days to reach the public protocol line, so it is not evidence of a rehearsed PQ migration-under-attack; full credit is withheld on all three counts.

No quantum canary embedded in Taiko Alethia protocol. Incident monitoring (automated alerts, withdrawal quotas) is operational tooling, not a rate-limited or monitored legacy-key exposure designed to detect CRQC arrival.