Architecture

Any cross-chain system should be secure and performant. Musafir derives its security from Ethereum and Eigenlayer's restaking. In terms of performance, Musafir is unlike anything that currently exists. Traditional bridges and cross-chain protocols often involve a relayer to relay transactions between chains. While this design simplifies setup and security by placing trust in a single entity to ensure that initiated transactions are accurately relayed, the trust in accuracy lies with validators, not relayers.

We have decoupled the chain smart contracts and validators, and completely removed the relayer mechanism.

Musafir deploys smart contracts on all supported chains that perform several key functions:

• User deposits

• Issue assets based on receipts issued by a validator quorum

These smart contracts are stateless, meaning that every receipt with a validator set quorum and signatures will be considered valid. This approach ensures that user deposits and balances are maintained on the Musafir network level, and validators are trusted based on cryptoeconomic incentives and penalties using Eigenlayer.

Musafir also hosts several smart contracts to integrate and utilize Eigenlayer, supporting a fraud-proof mechanism where provers can provide proof of malicious validator activity, freeze their deposits, and earn rewards.

Musafir network operates on the node level. Implemented as an AVS on Eigenlayer, operators opting to become part of Musafir will run our node software. This includes monitoring supported chains for deposit events, maintaining Musafir’s ledger, and running ledger consensus, allowing users to get receipts to access funds on any chain without a relayer. This step is abstract for the user in most applications, creating a seamless cross-chain UX.

Musafir’s ledger tracks deposits and manages user balances. Users can generate receipts by requesting funds through a transaction on Musafir’s network, signed by validators. The ledger also tracks issued receipts, which have an expiry since users may not always execute them. Validators track receipt usage on supported chains and update the ledger accordingly after usage or expiry.

To avoid double spending, receipts include several fields: nonce, chainId, txnDetails, userInfo, and expiry. Receipts also have a blockId linking them to a transaction on the Musafir network, allowing fraud provers to submit actual block data and executed receipts, and slash validator funds if discrepancies are detected.