Architecture · 7 min read
Cross-chain interoperability is not decentralized merely because it connects two blockchains. The bridge between them can introduce a smaller validator set, a privileged relayer, an opaque proof service, or an upgrade key that becomes the system’s real trust boundary.
Begin with what the destination can verify
Describe the exact source-chain fact that the destination needs to accept: a finalized header, a state inclusion, an event, or a derived claim. Then document how the destination verifies that fact and which assumptions verification introduces.
AIMB-X research explores proof-driven verification, but every proof system still has implementation, data-availability, and cryptographic assumptions.
- What statement is being proven?
- Which source-chain state is considered final?
- Who can produce and submit the proof?
- Can the destination reject or recover from stale state?
Model different finality systems
Connected chains can finalize state with different guarantees and delays. The cross-chain protocol should not compress those differences into a single unexplained “confirmed” status.
A verifier policy can wait for explicit evidence, attach confidence to a pending state, or reject a message whose source assumptions no longer hold.
- Finality evidence
- Reorganization behavior
- Proof freshness
- Timeout policy
- Destination rollback constraints
Publish the unresolved assumptions
A credible research artifact includes the cases it does not yet solve: verifier upgrades, proof-generation cost, unavailable source data, cryptographic migration, and recovery after partial execution. Those limits are part of the architecture, not footnotes.