TAIFOONTaifoon for Cross-Chain Transport
Transport systems can require a complete proof chain before settlement:
• Receipt proof — the event actually occurred
• Block inclusion proof — the event is in a specific block
• Twig inclusion — the block is committed to a 2048-block segment
• MMR inclusion — the twig is in the per-chain MMR
• SuperRoot reference — the MMR is in the cross-chain commitment
Settlement happens only after verification passes. No validator committee required.
The bridge no longer needs a trusted validator set to confirm the source event. The on-chain verifier contract checks the proof against the committed SuperRoot.
Relayers can attach inclusion metadata derived from Taifoon's aggregation rather than relying on internal trust models. The relayer becomes a data transport layer — trust comes from the proof itself.
| Aspect | Traditional Bridge | With Taifoon |
|---|---|---|
| Trust Model | Validator multisig (e.g., 5-of-9) | On-chain proof verification |
| Attack Surface | Compromise validators | Must forge valid MMR proof |
| Finality Check | Validator attestation | Light client verification |
| Cross-Chain Scope | Pairwise trust per route | Shared SuperRoot for all chains |
| Audit Trail | Validator signatures | Cryptographic proof chain |
Instead of maintaining pairwise trust relationships (Chain A trusts Bridge X, Chain B trusts Bridge Y), messaging layers can reference a shared commitment root spanning all supported chains.
One SuperRoot. 37 chains. No bilateral trust agreements needed.
1. Deploy or reference TaifoonUniversalVerifier on destination chains
2. Modify settlement logic to require proof submission
3. Call verifyInclusion(proof) before releasing/minting
4. Optionally layer proof requirement alongside existing validator signatures
5. Gradually reduce validator trust as proof verification proves reliable
Traditional Bridge: Security = min(validator set security, smart contract security)
Taifoon-Integrated Bridge: Security = cryptographic proof correctness + smart contract security
The attack surface shifts from "compromise N-of-M validators" to "forge a valid MMR proof" — which requires compromising the underlying blockchain consensus itself.