BCEbridge
Search
⌃K

Under the hood of BCEbridge

How does BCEbridge work from the User perspective?

The user must complete 2 transactions: Send transaction on the Source blockchain and Receive transaction on the Destination blockchain.
The transfer steps are the following:
  1. 1.
    Connect wallet on Blockchain A.
  2. 2.
    Complete Send transaction.
  3. 3.
    Connect wallet on Blockchain B.
  4. 4.
    Complete Receive transaction.

How does BCEbridge work under the hood?

There are several types of token transfer possible with BCEbridge:
  1. 1.
    Send Native tokens and receive Native tokens.
  2. 2.
    Send Native tokens and receive Wrapped (or minted) tokens.
  3. 3.
    Send Wrapped (or minted) tokens and receive Native tokens.
  4. 4.
    Send Wrapped (or minted) tokens and Receive Wrapped (or minted) tokens.

There are 3 ways a user can interact with the transactions

  1. 1.
    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.
  2. 2.
    Complete Send transaction on the Source chain manually and delegate finishing Receive transaction for the user to BCEbridge. It is valid for all the chains where this function is enabled.
  3. 3.
    Complete Send transaction on the source chain manually. Receive transaction will be finished by BCEbridge. It is valid only when Receiving on XRP Ledger.
1. Send and Receive manually
2. Delegate Receiving to the bridge
3. XRPL bridge
​

4 entities in the cross-chain token transfer process

  1. 1.
    User - EOA (Externally Owned Account) / Wallet from which the token X is transferred from one chain to another.
  2. 2.
    Blockchain A smart contract - a smart contract on the Source blockchain which receives transfer requests from the User.
  3. 3.
    Blockchain B smart contract - a smart contract on the Destination blockchain, which accepts input from the User.
  4. 4.
    Validator - an off-chain entity responsible for verifying Lock and Burn transactions on the bridge smart contracts.

1. Send Native tokens from Blockchain A and receive Native tokens on Blockchain B

This works similarly 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.
  1. 1.
    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 are specified. The assets get locked.
  2. 2.
    With the Receive transaction, the User asks Validator to check the request log.
  3. 3.
    Validator checks if funds were actually locked in the Blockchain A smart contract.
  4. 4.
    If they were, the Validator sends its signature to the User.
  5. 5.
    User sends the signature to the Blockchain B smart contract.
  6. 6.
    Blockchain B smart contract unlocks the requested X tokens and sends them to the User immediately.

2. Send Native tokens from Blockchain A and receive Wrapped (or minted) tokens on Blockchain B

  1. 1.
    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.
  2. 2.
    With the Receive transaction, the User asks Validator to check the request log.
  3. 3.
    Validator checks if funds were actually locked in the Blockchain A smart contract.
  4. 4.
    If they were, the Validator sends its signature to the User.
  5. 5.
    User sends the signature to the Blockchain B smart contract.
  6. 6.
    Blockchain B smart contract mints the requested wX tokens and sends them to the User immediately.

3. Send Wrapped (or minted) tokens from Blockchain B and receive Native tokens on Blockchain A

​
  1. 1.
    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.
  2. 2.
    With the Receive transaction, the User asks Validator to check the request log.
  3. 3.
    Validator checks if funds were actually burnt in the Blockchain B smart contract.
  4. 4.
    If they were, the Validator sends its signature to the User.
  5. 5.
    User sends the signature to the Blockchain A smart contract.
  6. 6.
    Blockchain A smart contract unlocks the requested X tokens and sends them to the User immediately.

4. Send Wrapped (or minted) tokens from Blockchain A and Receive Wrapped (or minted) tokens on Blockchain B

  1. 1.
    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.
  2. 2.
    With the Receive transaction, the User asks Validator to check the request log.
  3. 3.
    Validator checks if funds were actually burnt in the Blockchain A smart contract.
  4. 4.
    If they were, the Validator sends its signature to the User.
  5. 5.
    User sends the signature to the Blockchain B smart contract.
  6. 6.
    Blockchain B smart contract mints the requested w2X tokens and sends them to the User immediately.
​

5 entities in the cross-chain token transfer process

  1. 1.
    User (Sender / Receiver) - EOA (Externally Owned Account) / Wallet from which the token X is transferred from one chain to another.
  2. 2.
    Blockchain A smart contract - a smart contract on the Source blockchain which receives transfer requests from the User / BCEbridge Sender.
  3. 3.
    Blockchain B smart contract - a smart contract on the Destination blockchain, which accepts the input from the User / BCEbridge Sender.
  4. 4.
    BCEbridge Validator - an off-chain entity responsible for verifying Lock and Burn transactions on the bridge smart contracts.
  5. 5.
    BCEbridge Sender - an off-chain entity responsible for creating the Receive transaction for the User.

The process of finishing the transfer for a user

  1. 1.
    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 are specified. The assets get locked/burnt.
  2. 2.
    When a user clicks the “Finish for me” button on the bridge UI, the User triggers BCEbridge Sender.
  3. 3.
    BCEbridge Sender asks BCEbridge Validator to check the Send transaction finality.
  4. 4.
    Validator checks if funds were actually sent (locked/burnt) on the Blockchain A smart contract.
  5. 5.
    If they were, the Validator sends its signature to the Sender.
  6. 6.
    Sender sends a signature to the Blockchain B smart contract.
  7. 7.
    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 BCEbridge pay for gas?

When BCEbridge Sender sends a signature to the Blockchain B smart contract. Sender pays for this transaction from its balance of gas tokens. The fee is needed to pay for step 6.
When Blockchain B smart contract receives a signature from the Sender, it unlocks/mints the requested tokens and takes the fee from this amount. The fee goes to the same contract as the Bridge Fee.
The fee is equivalent to $1 worth of the transferring assets, which should be enough to cover the transaction gas.

Bonus gas for empty accounts

If a wallet has a 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 have no SOL on this address, we will send you an additional 0.003 SOL.

Bonuses value for chains

Chain
Amount
Token
Solana
0.003
SOL
Terra Classic
0.1
USTC
Tezos
0.1
TEZ
Waves
0.01
WAVES

5 entities in the cross-chain token transfer process

  1. 1.
    User (Sender / Receiver) - EOA (Externally Owned Account) / Wallet from which the token X is transferred from one chain to another.
  2. 2.
    Non-XRPL chain smart contract - a bridge smart contract on blockchains other than XRPL.
  3. 3.
    Outgoing Transactions Ledger on NEAR - a bridge smart contract on the NEAR blockchain.
  4. 4.
    BCEbridge Validator - an off-chain entity responsible for verifying Lock and Burn transactions on the bridge smart contracts.
  5. 5.
    XRPL Sender - an off-chain entity responsible for verifying Lock, Unlock, Mint, and Burn transactions on the bridge smart contracts for XRPL transfers.

Non-XRPL to XRPL

  1. 1.
    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 are specified. Non-XRPL chain smart contract locks/burns the received tokens from the User.
  2. 2.
    When a user clicks the “Receive” button on the bridge UI, the User asks Validator to receive the X tokens on the XRPL.
  3. 3.
    Validator checks if funds were actually locked/burnt on the non-XRPL chain smart contract.
  4. 4.
    If they were, the Validator sends an Unlock/Mint transaction to the Outgoing Transaction Ledger on NEAR.
  5. 5.
    After that, the Validator triggers XRPL Sender.
  6. 6.
    XRPL Sender checks the finality of the Unlock/Mint transaction on NEAR OTL.
  7. 7.
    If XRPL Sender finds an Unlock/Mint transaction on the NEAR OTL, it unlocks/mints the requested X tokens and sends them to the User immediately.

XRPL to non-XRPL

  1. 1.
    With the Send transaction, the User sends a request to the XRPL, where the wallet address 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.
  2. 2.
    With the Receive transaction, the User asks Validator to check the request log.
  3. 3.
    Validator checks if funds were actually sent (locked/burnt) to the XRPL.
  4. 4.
    If they were, the Validator sends its signature to the User.
  5. 5.
    User sends the signature to the non-XRPL chain smart contract.
  6. 6.
    Non-XRPL chain smart contract unlocks/mints the requested X tokens and sends them to the User immediately.
Previous
What is BCEbridge?
Next
BCEbridge XRPL Bridge
Last modified 3mo ago