Comment on page
Bridging
Submit your deployment address to this form. We will provide engineering support and prioritize specific infrastructure needs.
Our validating bridge deployed directly to Ethereum is the primary way to bring assets to Eclipse Mainnet. You will be able to bridge ETH and eventually other assets via our bridge. The bridge is a hashed timelock contract (HTLC).
ETH is the native token for Eclipse Mainnet. We do not have any other native token for Eclipse Mainnet.
Link to Eclipse Devnet Hyperlane UI: https://hyperlane-warp-template-9mgz5yk9j-abacus-works.vercel.app/
The Hyperlane bridge will provide fast finality bridging between Eclipse Mainnet and non-Ethereum chains. The Eclipse team worked with Hyperlane to deploy their mailbox contracts for the SVM.
Eclipse and Hyperlane partnered to bring Hyperlane's Permissionless Interoperability solution to Solana Virtual Machine (SVM) based blockchains. This integration enables Eclipse rollups to connect with other rollups and ecosystems without permission, communicate with non-IBC-enabled chains, provide fast-finality interoperability protocol for Eclipse rollups, and establish a mechanism for a token bridge.
Hyperlane's solution allows for unlimited instantiation of rollup chains, making it useful for high throughput SVM-based rollups. This collaboration is a significant step towards promoting interoperability, modularity, and customization within the SVM ecosystem and the industry as a whole.
IBC is the standard bridge between Cosmos chains.
To support trust-minimized IBC bridging to non-Eclipse chains, we impose a challenge period on IBC messages. We pass state roots as soon as they are generated by Eclipse Mainnet, but they cannot be used for IBC state proofs until after a specified number of blocks (the challenge period). If a correct fraud proof is passed to the light client on the receiving chain within the challenge period, then all IBC messages after that point are removed.
Our integration with IBC is still under development.
Validating Bridge | Hyperlane | Inter-Blockchain Communication (IBC) | |
|---|---|---|---|
Security | Short-Term: Messages passed from the L2 rely on a trusted intermediary
Long-Term: Trust-minimized | Configurable ISMs (Interchain Security Modules) | Validator-based, rules may vary per chain; proof-of-authority intermediary |
Time to Finality | From Ethereum to L2: Fast Finality
From L2 to Ethereum: Challenge Period | Based on the finality time of the origin chain, and a block on the destination. | Fast finality facilitated by Tendermint chain |
Congestion Handling | Primary cost is unlocking ETH from the HTLC on Ethereum | Only worried about congestion on the chains being connected, as there is no Hyperlane chain. | Relayers in IBC have not yet broadly implemented a fee market. During congestion, end users will need to pay higher fees. |
Censorship Resistance | Bridging into the L2 inherits the censorship resistance of Ethereum. Bridging back from the L2 inherits the CR of the sequencer set in the short-term, but will inherit Ethereum CR via forced inclusion in the long-term. | Censorship resistant by construction. Hyperlane’s permissionless nature ensures its neutrality, as it can be run without any dependency on external actors. | Bridging through IBC relies on a set of untrusted relayers and the validator set of the Polymer and external Cosmos chain. Messages will go through if there is one honest relayer and the chains will continue to make progress as long as there is an honest majority of validators. |
Update Authority | Eclipse governance (TBD) | You retain and decide the upgrade authority for your warp routes, and you can control it for the Mailbox deployed on your chain or rollup. | To update one side of the bridge requires trusting the settlement of one network. To withdraw requires the settlement of the other network. Polymer acts as a router and does not hold funds directly on their bridge. |
Additional Tools | Eclipse Canonical Bridge UI |