#8 Findora Academy 💟 | Rialto Bridge Architecture — Deep Dive

Welcome to our second article discussing the newly launched cross-chain bridge, Rialto, that connects Findora to BNB Chain (and, later on, other EVM-compatible blockchains like Ethereum).

Findora’s AMM DEX Ecosystem

Rialto is the first cross-chain bridge built to access the growing DeFi market of privacy Dapps being deployed on Findora, including decentralized exchanges (DEXs) such as FairySwap🧚‍♀️ and Venice.finance. Be sure to visit these project links to check for any APY promotional campaigns.

Rialto Bridge Promotional Campaign

For the mainnet Rialto bridge launch, a $5m bridge fee reimbursement promotion was launched. Click here to participate and earn free FRA!

In this article, we will go into a deep dive on the technical architecture of Rialto. See the first article for a broader overview.

Overview

Rialto, at its core, is a message-passing protocol, through which events and transactions on a source chain are routed to a destination chain. The architecture of Rialto relies on proposals created by relayers located on the target (or destination chain) chain and these proposals must be approved by other relayers. On the target chain, approval voting also occurs and the transaction is executed only after a voting threshold is passed.

Architectural Details

Before any asset can be transferred between chains, a bridge must be set up between them. A set of contracts must be deployed on the source chain as well as the destination. These contracts (Bridge, Handler, Token) will define the behavior of the bridge.

A set of relayers must also be deployed in order to facilitate the transfer in a decentralized manner. These relayers are configured with the RPC endpoints of each chain and are responsible for voting and triggering the execution of the transfer.

Rialto Architecture

The user will first send an approval for the deposit of a specific amount.

1. A deposit transaction is initiated on the Bridge Contract. The user needs to input the target chain, the resource ID, and the calldata. After a few checks, the deposit() function of the handler contract is called, which executes the corresponding call of the token contract.
2. After the function of the token contract in BNB Chain is executed, a deposit event is emitted by the bridge contract, which holds the necessary data to be executed on Findora. This is called a proposal. Each proposal can have five statuses (inactive, active, passed, executed and canceled).
3. Relayers are always listening on both sides of the chain. Once a relayer picks up the event, it initiates a voting on the proposal, which happens on the bridge contract on Findora. This sets the state of the proposal from inactive to active (from 0 to 1).
4. Relayers must vote on the proposal. Every time a relayer votes, an event is emitted by the bridge contract that updates its status. Once a threshold is met, the status changes from active to passed (From 1 to 2). A relayer then executes the proposal on Findora via the bridge contract.
5. After a few checks, the bridge executes the proposal in the token contract via the handler contract on Findora. Another event is emitted, which updates the proposal status from passed to executed (From 2 to 3).
6. Once executed the funds are minted on the destination chain and transferred to the recipient.