Liquidity & asset bridges
The Root Network natively supports two-way asset bridges through its general-purpose bridging runtime. Our two asset bridges currently support two-way transfers of XRP, ERC-20 tokens, and Native ETH. Data and asset transfers will be available soon.
An asset bridge often called a token bridge, is a connection that allows the transfer of tokens and/or arbitrary data from one blockchain to another. A successful bridge connects chains that each have totally different governance models, protocols and rules, something which would typically totally cut them off from each other. Despite their different core protocols, the bridge allows the chains to interact and interoperate securely and quickly.
The Root Network currently has two natively supported two-way asset bridges:
- The Eth Bridge: Connects to Ethereum
- The XRPL Bridge: Connects to the XRP Ledger
The Root Network’s bridging protocol is designed for fast transaction speeds and efficiency at scale. This has been achieved using an architecture called optimistic design.
Specifically, event verification uses an optimistic security model on The Root Network side. Rather than having all bridge transactions verified individually by validators, an optimistic model assumes that all transactions are valid, but provides a challenge period for community members to challenge a transaction. If a transaction is challenged, it will be put forward for a Validator check. This vastly increases the throughput of the asset bridges allowing for faster and smoother transactions at scale.
A permissioned relayer service will bond some tokens and submit crosschain messages to the Eth Bridge pallet. It is incentivised to behave correctly or lose its stake.
- 1.Permissionless challengers may submit challenges for any messages by temporarily locking some tokens.
- 2.Validators will resolve the dispute and slash the incorrect party, paying out some portion to the correct party.
- 3.After the challenge period has expired, a message is considered verified, and a successful callback should execute.
- 4.The slashed relayer is unable to submit future messages unless restaked.
Last modified 3mo ago