TAIFOONWhy Taifoon Now
Each incident had a different attack surface. But every single one shares the same underlying design flaw: none of them verified source-chain state on-chain.
They trusted external parties who reported that something happened, rather than proving it cryptographically. What failed was not base-layer cryptography — it was the way cross-chain state was accepted and acted upon.
Entire ecosystems now depend on cross-chain coordination working correctly. Capital moves between blockchains constantly. Protocols execute based on state they did not produce themselves.
The problem is that "confirmed" does not mean the same thing on every chain. Finality behaves differently. Latency behaves differently. Reorganizations behave differently. Yet most cross-chain systems abstract these differences away.
When a bridge processes a transaction, it needs to know that an event occurred on another chain. The convenient way to do this is to have a set of trusted validators watch the source chain and sign off when they see something. The system works until those validators are compromised, misconfigured, or unavailable.
Attestation-based systems relocate trust rather than eliminate it. The security model becomes the security of whoever is doing the attesting. As long as everything works, that dependency is easy to ignore. Once it fails, it becomes obvious that execution was gated by claims rather than independently verifiable state.
Cross-chain state verification sounds straightforward until you try to build it across heterogeneous consensus systems. Finality is not uniform:
| Chain | Consensus | Finality Model | Cryptographic Primitive |
|---|---|---|---|
| Bitcoin | Proof-of-Work | Confirmation depth (6 blocks) | SHA256d |
| Ethereum | Proof-of-Stake | Two epochs via sync committee | BLS12-381 |
| Polkadot | GRANDPA | Asynchronous finality | Blake2b-256 + BLS |
| Solana | Tower BFT | Voting + hash model | Ed25519 |
| Monad | MonadBFT | Parallel execution BFT | BLS12-381 |
| ICP | Threshold Relay | Chain key certificates | BLS threshold |
There is no universal proof format that covers all of these. Abstraction made integration easier, but it masked the differences that actually determine whether cross-chain execution is safe.
The only approach that avoids introducing new trust assumptions is to build a dedicated on-chain light client verifier for each consensus type — a smart contract that receives a block header, checks the cryptographic proof natively, and either accepts or rejects it without any external attestation.
19 different light-client verifiers are live on the network today. V2 verifiers run full on-chain cryptographic checks: BLS12-381 pairing equations for Ethereum sync committees and MonadBFT, Ed25519-over-ecrecover for CometBFT validators, Plonk SNARK verification for HotShot sequencers, SHA256d hash accumulation for Bitcoin's proof-of-work chain, GRANDPA authority set rotation with BLS aggregation for Polkadot and Kusama.
The proof blob has six layers. The outermost is a SuperRoot: a binary Merkle tree over 41 chain leaf hashes, where each leaf commits chainId, block number, block hash, MMR root, and twig count into a single 32-byte digest.
Inside that sits a chain-specific MMR inclusion proof for the block itself — logarithmic depth against 63 million stored headers. Then the event: typed per chain, because event semantics are not portable.
The innermost layer is the finality cross-check: the V5 verifier reads TaifoonFinalityAggregator.latestFinalized(chainId) — the on-chain record of what every light-client verifier has actually confirmed — and rejects any proof that claims a block the network hasn't ratified yet.
| ICP | Without Taifoon | With Taifoon |
|---|---|---|
| ICP-01 · DeFi Protocols | Trust oracle or relayer to report remote chain state | MMR inclusion proof per event, on-chain collateral verification |
| ICP-02 · Institutional & Trading | Manual polling per chain, unverifiable execution receipts | Unified signal feed across 41 chains, cryptographic execution audit trail |
| ICP-03 · Infrastructure & Data | Trust the data source, no proof of inclusion | Proof-backed responses, bloom-filtered block inclusion, gRPC streaming |
| ICP-04 · Messaging & Interop | Validator signatures, multisig trust, guardian committees | MMR inclusion proofs, on-chain verification, zero trust assumptions |
| ICP-05 · Chains & Rollups | Custom bridge per chain, months of engineering per connection | Anchor block headers once, instant interoperability across all 41 chains |
We looked for infrastructure that unified verification, synchronization, and execution gating across heterogeneous chains. Nothing in production did all three.
So we built it. The infrastructure is running. The proofs are on-chain. Execution becomes conditioned on verifiable state.