Under the hood of Allbridge

Search…

How Allbridge works from the User perspective? 
The user needs to Complete 2 transactions: Send transaction on the Source blockchain and Receive transaction on the Destination blockchain.
The transfer steps are the following:
Connect wallet on Blockchain A.
Complete Send transaction.
Connect wallet on Blockchain B.
Complete Receive transaction.
How does Allbridge work under the hood?
There are several types of token transfer possible with Allbridge:
Send Native tokens and receive Native tokens.
Send Native tokens and receive Wrapped (or minted) tokens.
Send Wrapped (or minted) tokens and receive Native tokens.
Send Wrapped (or minted) tokens and Receive Wrapped (or minted) tokens.
There are 3 ways a user can interact with the transactions
Complete Send transaction on the Source chain and Receive transaction on the Destination chain manually. It is valid for all the chains except for XRP Ledger.
Complete Send transaction on the Source chain manually and delegate finishing Receive transaction for the user to Allbridge. It is valid for all the chains, where this function is enabled.
Complete Send transaction on the source chain manually. Receive transaction will be finished by Allbridge. It is valid only when Receiving on XRP Ledger.
Send and Receive manually
Delegate Receiving to the bridge
XRPL bridge
​
entities in the cross-chain token transfer process
User - EOA (Externally Owned Account) / Wallet from which the token X is transferred from one chain to another.
Blockchain A smart contract - a smart contract on the Source blockchain which receives transfer requests from the User.
Blockchain B smart contract - a smart contract on the Destination blockchain, which accepts the input from the User.
Validator - an off-chain entity that is responsible for verifying Lock and Burn transactions on the bridge smart contracts.
Send Native tokens from Blockchain A and receive Native tokens on Blockchain B
This works similar to the usual DEX swap with 2 liquidity pools when we lock tokens in one liquidity pool and receive from the other. Except, that the token is the same and on different blockchains.
With the Send transaction, the User sends a request to the Blockchain A smart contract, where the address of the wallet on the Blockchain B and the amount of token X that must be sent to the wallet is specified. The assets get locked.
With the Receive transaction, the User asks Validator to check the request log.
Validator checks if funds were actually locked in the Blockchain A smart contract.
If they were, the Validator sends its signature to the User.
User sends the signature to the Blockchain B smart contract.
Blockchain B smart contract unlocks the requested amount of X tokens and sends them to the User right away.
Send Native tokens from Blockchain A and receive Wrapped (or minted) tokens on Blockchain B
With the Send transaction, the User sends a request to the Blockchain A smart contract, where specifies the address of the wallet on the Blockchain B and the X tokens that must be sent to Blockchain B. Blockchain A smart contract locks the received tokens from the User and creates a request log.
With the Receive transaction, the User asks Validator to check the request log.
Validator checks if funds were actually locked in the Blockchain A smart contract.
If they were, the Validator sends its signature to the User.
User sends the signature to the Blockchain B smart contract.
Blockchain B smart contract mints the requested amount of wX tokens and sends them to the User right away.
Send Wrapped (or minted) tokens from Blockchain B and receive Native tokens on Blockchain A
​
With the Send transaction, the User sends a request to the Blockchain B smart contract, where specifies the address of the wallet on Blockchain A and the wX tokens that must be sent to Blockchain A. Blockchain B smart contract burns the received tokens from the User and creates a request log.
With the Receive transaction, the User asks Validator to check the request log.
Validator checks if funds were actually burnt in the Blockchain B smart contract.
If they were, the Validator sends its signature to the User.
User sends the signature to the Blockchain A smart contract.
Blockchain A smart contract unlocks the requested amount of X tokens and sends them to the User right away.
Send Wrapped (or minted) tokens from Blockchain A and Receive Wrapped (or minted) tokens on Blockchain B
With the Send transaction, the User sends a request to the Blockchain A smart contract, where specifies the address of the wallet on Blockchain B and the w1X tokens that must be sent to Blockchain B. Blockchain A smart contract burns the received tokens from the User and creates a request log.
With the Receive transaction, the User asks Validator to check the request log.
Validator checks if funds were actually burnt in the Blockchain A smart contract.
If they were, the Validator sends its signature to the User.
User sends the signature to the Blockchain B smart contract.
Blockchain B smart contract mints the requested amount of w2X tokens and sends them to the User right away.
​
entities in the cross-chain token transfer process
User (Sender / Receiver) - EOA (Externally Owned Account) / Wallet from which the token X is transferred from one chain to another.
Blockchain A smart contract - a smart contract on the Source blockchain which receives transfer requests from the User / Allbridge Sender.
Blockchain B smart contract - a smart contract on the Destination blockchain, which accepts the input from the User / Allbridge Sender.
Allbridge Validator - an off-chain entity that is responsible for verifying Lock and Burn transactions on the bridge smart contracts.
Allbridge Sender - an off-chain entity that is responsible for creating the Receive transaction for the User.
The process of finishing the transfer for a user
With the Send transaction, the User sends a request to the Blockchain A smart contract, where the address of the wallet on the Blockchain B and the amount of token X that must be sent to the wallet is specified. The assets get locked/burnt.
When a user clicks the “Finish for me” button on the bridge UI, the User triggers Allbridge Sender.
Allbridge Sender asks Allbridge Validator to check the Send transaction finality.
Validator checks if funds were actually sent (locked/burnt) on the Blockchain A smart contract.
If they were, the Validator sends its signature to the Sender.
Sender sends a signature to the Blockchain B smart contract.
Blockchain B smart contract unlocks/mints the requested amount of X tokens, takes a small fee to cover the transaction’s gas costs, and sends the remaining amount of tokens + some gas token (if the gas balance of the wallet is less than this amount) to the User right away.
How does Allbridge pay for gas?
The fee is needed to pay for the step 6. When Allbridge Sender sends a signature to the Blockchain B smart contract. Sender pays for this transaction from its own balance of gas tokens.
When Blockchain B smart contract receives a signature from the Sender, it unlocks/mints the requested amount of tokens and takes the fee from this amount. The fee goes to the same contract as the Bridge Fee.
The fee is equivalent to $0.50 worth of the transferring assets, which should be enough to cover the transaction gas.
Bonus gas for empty accounts
If a wallet has very small or empty balance of gas tokens, we add some additional gas with the transferred tokens.
For example, if you send USDC to Solana and you have no SOL on this address, we will send you additional 0.003 SOL.
Bonuses value for chains
Chain
Amount
Token
Solana
003
SOL
Terra
1
UST
entities in the cross-chain token transfer process
User (Sender / Receiver) - EOA (Externally Owned Account) / Wallet from which the token X is transferred from one chain to another.
Non-XRPL chain smart contract - a bridge smart contract on the blockchains other than XRPL.
Outgoing Transactions Ledger on NEAR - a bridge smart contract on the NEAR blockchain.
Allbridge Validator - an off-chain entity that is responsible for verifying Lock and Burn transactions on the bridge smart contracts.
XRPL Sender - an off-chain entity that is responsible for verifying Lock, Unlock, Mint, and Burn transactions on the bridge smart contracts for XRPL transfers.
Non-XRPL to XRPL
With the Send transaction, the User sends a request to the non-XRPL chain smart contract,  where the address of the wallet on the XRPL and the amount of token X that must be sent to the wallet is specified. Non-XRPL chain smart contract locks/burns the received tokens from the User.
When a user clicks the “Receive” button on the bridge UI, the User asks Validator to receive the X tokens on the XRPL.
Validator checks if funds were actually locked/burnt on the non-XRPL chain smart contract.
If they were, the Validator sends an Unlock/Mint transaction to the Outgoing Transaction Ledger on NEAR .
After that, Validator triggers XRPL Sender.
XRPL Sender checks the finality of the Unlock/Mint transaction on NEAR OTL.
If XRPL Sender finds an Unlock/Mint transaction on the NEAR OTL, it unlocks/mints the requested amount of X tokens and sends them to the User right away.
XRPL to non-XRPL
With the Send transaction, the User sends a request to the XRPL, where the address of the wallet on the non-XRPL chain and the amount of token X that must be sent to the wallet is specified. The assets get locked/burnt.
With the Receive transaction, the User asks Validator to check the request log.
Validator checks if funds were actually sent (locked/burnt) to the XRPL.
If they were, the Validator sends its signature to the User.
User sends the signature to the non-XRPL chain smart contract.
Non-XRPL chain smart contract unlocks/mints the requested amount of X tokens and sends them to the User right away.