Taifoon

Most cross-chain proof systems don't explain what's actually holding them together. This is the data structure underneath all of it, and understanding it changes how you think about cross-chain verification entirely. Why not a standard Merkle tree? A standard Merkle tree is fixed at construction. Every leaf is defined upfront and the root is computed once. If you want to add new data, you rebuild the tree and every existing proof becomes invalid. Blockchains never stop producing blocks. A proof system built on a fixed Merkle tree would require constant reconstruction and would invalidate every proof every time a new block is added. An MMR solves this. What an MMR actually is A Merkle Mountain Range is an append-only data structure. New leaves can be added without invalidating existing proofs. The structure grows as new blocks arrive and every proof generated against it remains valid indefinitely. Taifoon uses it as a catalogue. Every block header from every indexed chain gets appended as a leaf. The structure always reflects the current state of every chain while preserving the full verifiable history. How Taifoon structures it The indexing works in three levels: 1) Every 2048 consecutive block headers are grouped into a twig. The twig root is a Merkle hash of those 2048 blocks. 2) Twigs accumulate into a chain-specific MMR. The peaks of that MMR represent the full indexed history of that chain. 3) All chain peaks are bagged together into a single SuperRoot, a 32-byte hash committing to the finalized state of all 38 chains simultaneously. What this enables Any block on any of the 38 indexed chains can be proven against the SuperRoot with a compact Merkle path. The proof includes the block hash, the twig siblings, the chain MMR siblings, and the SuperRoot siblings, a complete cryptographic path from a single block to a structure covering 38 chains. The SuperRoot is deterministic. Same finalized blocks always produce the same hash. Anyone can recompute it independently from public RPC data. Current scale 88 million block headers indexed across 38 chains. Approximately 40 blocks per second collected across all networks. Every header becomes a provable leaf in the MMR. API docs: taifoon.io/docs/v5-proof-… #CrossChain #DeFi

Taifoon Proof is live. V5 MMR proofs across 40+ chains. One API. What it does: Every block header across 40+ chains is indexed in real time as an MMR twig. A Merkle Mountain Range is an append-only cryptographic accumulator that lets you prove any historical block belongs to the chain without storing every block. Each twig feeds into chain-specific MMR peaks, which aggregate into a single SuperRoot. The verification flow: → Source block collected and indexed as an MMR twig. → Intent anchored to twig position. → Destination chain confirms. → Source twig finality confirmed. → Inclusion proof submitted on-chain. The API: GET /v5/proof/blob/{chainId}/{blockNumber} Returns the full Merkle path from twig to peaks to SuperRoot. On-chain execution via TaifoonUniversalOperator.executeVerifiedCall(). Same proof format across all chains. Chain coverage: L1s: Ethereum, BSC, Gnosis, Fantom, Avalanche, X1 L2s and rollups: Arbitrum, Base, Optimism, Linea, Scroll, zkSync Era, Blast, Zora, Mode, Fraxtal, Lisk, Unichain, Lyra, Flow EVM, HyperEVM, Sei, Monad, ApeChain, RARI GRANDPA parachains: Moonbeam, Astar, Peaq Non-EVM: Solana, Bitcoin, Polkadot, Kusama, Tron, Aptos, Sui, ICP One proof format. Any chain. All verifiable on-chain. Current collection rate: approximately 40 blocks per second across all networks. Every header becomes a provable twig. taifoon.io/proof #CrossChain #DeFi

Taifoon Pulse is now public. Real-time status for 41 networks on a single dashboard. Block height, sync lag, blocks collected per chain, and health status updated continuously across EVM and non-EVM chains. What Pulse surfaces per chain: → Block height, current and live. → Blocks collected per second. → Sync lag in real time. → Health status: SYNCING, CATCHING UP, or OFFLINE. What runs underneath it: → 323 RPC endpoints with automatic failover. → WebSocket collectors for Arbitrum, Optimism, and Base. → GRANDPA finality tracking for Moonbeam, Astar, and Peaq. → MMR proofs generated per block across all 41 networks. This is the same internal heartbeat we use to monitor our own collector network. Now open to anyone building on top of multi-chain data. For L2s and chains: If you want to be included in the RPC warmbed pool, reach out directly. For protocols building bridges, DEXs, or aggregators: Pulse feeds the DA layer powering cross-chain proof verification. If you need to know whether a block finalized across 41 chains, this is the data layer for that. taifoon.io/pulse #CrossChain #Infrastructure

Most cross-chain systems ask you to trust a relayer, a committee, or an oracle. Taifoon doesn't ask for trust. Every V5 proof is independently verifiable from public data. No Taifoon involvement required. Here is how to do it, step by step. Step 1: Fetch the proof GET api.taifoon.dev/api/v5/proof/b… V5 proof blob for Ethereum block 24651876: blockHash: 0x3d6000bd459913ad4d0f07f4e816d8f2792d0f56c694f66598cc68bcbd83c429 miniMmrRoot: 0x9439378debac8211226d965690e1feeb31b3e64559d860c315200f022d4d789b superrootHash: 0x1a7a67af476f01b9b56d93188efd4ea89f5fa0bcf1f5f54aedfd880947ed193c twigCount: 331,364 87ms p50. 2-4KB. All you need to verify. Step 2: Verify the block hash Take blockHash from the response and check it on @etherscan: etherscan.io/block/24651876 If the hash matches, the block is canonical on Ethereum mainnet. You are checking directly against the source chain. Not against us. Step 3: Verify MMR inclusion The proof includes Merkle siblings. Hash the block with each one in sequence: Block 24651876 → Twig (2,048 blocks) → Chain MMR → SuperRoot If the final result matches superrootHash, the block is correctly committed. Standard Merkle verification. No custom cryptography. Step 4: Check the SuperRoot is live GET api.taifoon.dev/api/spinner/su… If superrootHash in your proof matches the current published SuperRoot, that @ethereum block is committed to a structure aggregating 38 chains simultaneously. One hash. 38 chains. Fully public. What a valid V5 proof establishes: The block exists on Ethereum, verified against Etherscan directly. It is committed to Taifoon's MMR, verified via Merkle siblings. The MMR is committed to the live SuperRoot, verified against public API. Every step is checkable from public data. The proof reconstructs or it doesn't. Full API docs: taifoon.io/docs/v5-proof-… #CrossChain #DeFi

Try it yourself. Fetch a real V5 proof for Ethereum block 24651876: GET api.taifoon.dev/api/v5/proof/b… The response includes the block hash, miniMmrRoot, superrootHash, and Merkle siblings to reconstruct the full path. Verify the block hash against Etherscan. Verify the superroot against the live API. Start here: taifoon.io/api-overview

Finality is not uniform across chains. → Ethereum finalizes via Casper FFG checkpoints at epoch boundaries. → Bitcoin requires 6-confirmation depth under PoW. → Solana uses Tower BFT with 31-slot supermajority. → Polkadot uses GRANDPA with 2/3 validator votes. → OP Stack L2s finalize via dispute games on Ethereum L1. Arbitrum via BOLD. Every chain finalizes differently. Every chain has a different proof surface. There is no universal proof format that covers all of these natively. So how does Taifoon aggregate all of them into a single verifiable structure? The answer is the SuperRoot. Every 10 seconds, the MMR indexer: — Collects finalized block hashes from all 38 chains — Groups every 2,048 blocks into a twig — Computes an MMR root per chain — Bags all network peaks into a single 32-byte hash That hash commits to the finalized state of all 38 chains simultaneously. Current SuperRoot: 0x1a7a67af476f01b9b56d93188efd4ea89f5fa0bcf1f5f54aedfd880947ed193c Chains included: 38 Total twigs: 16,094 What does a proof actually look like? Every proof is structured in six layers. L1 — Global SuperRoot L2 — Chain-specific headers L3 — Merkle path from chain to SuperRoot L4 — Merkle path from block to mini-MMR L5 — Transaction and receipt data L6 — Chain-native finality commitment Layer 6 is what makes the format chain-agnostic. For Ethereum: PoS checkpoint data. For Bitcoin: PoW confirmation depth. For Solana: Tower BFT slot proof. For OP Stack: dispute game resolution from Ethereum L1. Same outer structure. Chain-specific finality at the innermost layer. Is the SuperRoot verifiable independently? Yes. It's deterministic. Same finalized blocks always produce the same SuperRoot hash. Anyone can re-compute it from public RPC data by fetching finalized blocks, computing MMR twigs of 2,048 blocks each, computing network MMR peaks, and bagging all peaks together. If your result matches the published SuperRoot, the data is consistent with public chain state. No trust required, it's math. Current coverage: 38 production networks — 35.4M blocks indexed. EVM L1s: Ethereum, BSC, Gnosis, Polygon OP Stack L2s: Optimism, Base, Unichain, Blast, Mode, Zora Arbitrum stack: Arbitrum One, ApeChain, RARI Chain ZK rollups: zkSync Era, Scroll, Linea Non-EVM: Bitcoin, Solana, Polkadot, Kusama, Tron, Sei EVM Proof size: 2-4KB — Generation latency: 87ms p50

There are two ways to condition cross-chain execution. One relies on attestation: external actors signing off on what happened. The other relies on proof: on-chain verification before anything executes. They are fundamentally different systems. See how they compare below.

A forged cross-chain message just minted 1 billion Polkadot tokens on Ethereum. The attacker submitted a message through Hyperbridge's gateway contract. The proof verification had a Merkle Mountain Range edge case — at leafCount == 1 the computation degenerates and a crafted proof passes against a legitimate stored root. Worse, the gateway never cryptographically bound the submitted payload to the validated proof. Any valid-looking proof alongside any payload would do. Admin control over the bridged DOT token contract transferred to the attacker. 1 billion tokens minted. Dumped for approximately $237,000. The attacker's profit was limited only by shallow liquidity in the DOT-ETH pool on Ethereum. On a deeper pool, the same exploit produces a proportionally larger loss. This is not a new class of attack. It is the same design failure that produced Ronin, Wormhole, and Nomad. Execution was conditioned on a message being accepted, not on source-chain state being proven. The specific control that was absent: cryptographic verification that the incoming payload corresponded to a real state transition on Polkadot, verifiable on-chain at the destination. This is the distinction between attestation and verification. Attestation An external message claims something happened on the source chain. The contract executes based on that claim. Verification Source-chain state is proven cryptographically before execution. The proof either reconstructs correctly or nothing executes. Taifoon's V5 verifier reconstructs the source-chain SuperRoot from the payload bytes themselves, through Merkle siblings, and cross-checks the result against a finalized value published on-chain. The event hash used for replay protection is derived inside the verifier from those same payload bytes — replay uniqueness and payload binding collapse to one check. They can't disagree. A forged message has no inclusion path that reconstructs to any finalized SuperRoot. Routed through TaifoonUniversalOperatorV5.executeVerifiedCallV5(), the Hyperbridge transaction reverts before the vendor call. The verification layer that would have caught this exists. Most bridges are not using it. #CrossChain #DeFi

Most cross-chain systems do not verify source-chain state on-chain. They rely on external attestations. A typical execution flow looks like this: → An event occurs on the source chain → A relayer observes it → A committee, multisig, or oracle signs a message → The destination contract executes based on that message The destination chain does not verify the source chain directly. It verifies that a set of actors agreed on a statement. This creates a dependency on three things: validator honesty, multisig security, and oracle correctness. Bridge architectures vary in implementation, but the underlying model is consistent across all of them and execution is conditioned on signatures, not on proof of source-chain state. Recent failures illustrate different attack surfaces against this same model: → Harmony: multisig compromise → Ronin: validator compromise → Nomad: message validation flaw The implementations differed. The shared property did not: source-chain state was not verified on-chain. This can be addressed without replacing the bridge itself. Taifoon introduces a verification layer that sits underneath existing bridge infrastructure. Rather than conditioning execution on signatures or attestations, execution is gated by cryptographic proof of source-chain state verified on-chain at the destination. The execution condition changes... From "A set of actors signed this message" To "This state transition is provable against the source chain" The result is not a different bridge. It is a different execution model: one where the verification happens on-chain, the proof is independently reproducible, and the trust boundary is explicit rather than assumed. 🌀 taifoon.io

The term "trustless" is widely used across cross-chain infrastructure. In practice, most systems implement a different model. A typical cross-chain flow looks like this: → An event occurs on the source chain → A relayer or oracle observes it → A committee, multisig, or oracle network attests to it → The destination contract executes based on that attestation The destination chain does not verify source-chain state directly. It verifies that a set of actors agreed on a statement about that state. This creates a dependency on validator honesty, multisig security, and oracle correctness. If an incorrect message is delivered, there is no on-chain mechanism to independently verify whether the underlying source-chain event was valid at that moment. Analysis happens off-chain, after the fact. A stricter definition of "trustless" requires something different: → Any party can verify cross-chain state on-chain → Without relying on external attestations In this model, execution is conditioned on proof of source-chain state, not on signatures from a committee or oracle network. Taifoon is designed as a verification layer that enables this model. Instead of accepting attestations, contracts verify cryptographic proofs of source-chain state directly on the destination chain. The execution condition changes... From "A set of actors attests to this state" To "This state can be proven against the source chain" The difference is not in messaging or transport. It is in what the system verifies before execution. 🌀 taifoon.io

Two systems: Trust-based reality Proof-based reality Assume: sound proofs Guarantee: π verifies ⇒ claim valid independent of belief Taifoon composes validity. On-chain. □ QED

Equilibrium — Spec Assume: sound proofs deterministic verification Guarantee: π verifies ⇒ invariants hold independent of state perturbations Systems fluctuate. Validity stabilizes. Taifoon. □ QED

Consensus Landscape — Spec Assume: sound proofs deterministic verification Guarantee: different peaks same invariants Systems diverge. Validity doesn’t. Taifoon composes truth. □ QED

Invariant — Spec Many worlds. One constraint. Assume: sound proofs deterministic verifier Guarantee: everything passes through math nothing passes around it Taifoon. On-chain. □ QED

Truth is a surface. Math defines its curvature. Assume: sound proofs deterministic verification Guarantee: π verifies ⇒ reality snaps to math not opinion Taifoon composes validity. On-chain.

Math Over Middlemen — Spec Assume: sound proofs deterministic verification Guarantee: π verifies ⇒ reality constrained by math not committees Security invariant. Chains optional. Taifoon. □

Truth Machine — Spec Assume: H collision-resistant sound proofs Define: root := Commit(state) Guarantee: π verifies ⇒ state-transition valid ∧ binds(root) Pr[forge] ≤ 2⁻²⁵⁶ Less narrative. More invariants. Taifoon. On-chain. □ QED

Spinner — Formal Spec Assume: H collision-resistant Proofs sound Verifier deterministic Guarantee: deploy once ⇒ verify anywhere verify(root, π, claim) ⇒ valid(claim ∧ binds(root)) Pr[forge] ≤ 2⁻²⁵⁶ Developer velocity, on-chain. Taifoon composes validity. □ QED