> For the complete documentation index, see [llms.txt](https://docs.allbridge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.allbridge.io/allbridge-overview/under-the-hood-of-allbridge-classic.md).

# Under the hood of Allbridge Classic

{% hint style="warning" %}

### Allbridge Classic is deprecated and will be stopped in mid-2026. You can find information on our current bridge Allbridge Core [here.](https://docs-core.allbridge.io/)

{% endhint %}

### How does Allbridge Classic work? 

![](/files/RTqK2LCVbQhpsFELq8Gi)

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. Connect wallet on Blockchain A.
2. Complete Send transaction.
3. Connect wallet on Blockchain B.
4. Complete Receive transaction.

### How does Allbridge Classic work under the hood?

There are several types of token transfer possible with Allbridge Classic:

1. Send **Native** tokens and receive **Native** tokens.
2. Send **Native** tokens and receive **Wrapped** (or minted) tokens.
3. Send **Wrapped** (or minted) tokens and receive **Native** tokens.
4. Send **Wrapped** (or minted) tokens and Receive **Wrapped** (or minted) tokens.

### There are 3 ways a user can interact with the transactions

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

{% tabs %}
{% tab title="1. Send and Receive manually" %}

### 4 entities in the cross-chain token transfer process

1. **User -** EOA (Externally Owned Account) / Wallet from which the token X is transferred from one chain to another.
2. **Blockchain A smart contract** - a smart contract on the **Source** blockchain which receives transfer requests from the **User**.
3. **Blockchain B smart contract** - a smart contract on the D**estination** blockchain, which accepts input from the **User**.
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

![](/files/CoQXlCrVrTDMr7gmY330)

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. 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. With the *Receive* transaction, the **User** asks Validator to check the request log.
3. **Validator** checks if funds were actually locked in the **Blockchain A smart contract.**
4. If they were, the Validator sends its signature to the **User**.
5. **User** sends the signature to the **Blockchain B smart contract.**
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

![](/files/IL5VXJp80PKdxX029sdK)

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. With the **Receive** transaction, the **User** asks Validator to check the request log.
3. **Validator** checks if funds were actually locked in the **Blockchain A smart contract.**
4. If they were, the Validator sends its signature to the **User**.
5. User sends the signature to the **Blockchain B smart contract.**
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

![](/files/uj6hjWyXlg7im5B6W4XP)

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. With the **Receive** transaction, the **User** asks **Validator** to check the request log.
3. **Validator** checks if funds were actually burnt in the **Blockchain B smart contract.**
4. If they were, the Validator sends its signature to the **User**.
5. **User** sends the signature to the **Blockchain A smart contract.**
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

![](/files/Iv3mLkp9hpq8KOX1ObIz)

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

{% tab title="2. Delegate Receiving to the bridge" %}

{% embed url="<https://www.youtube.com/watch?t=6s&v=WBD7PYZOoMI>" %}

### 5 entities in the cross-chain token transfer process

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

![](/files/SRVLvWRqn9vF5l24PadT)

### The process of finishing the transfer for a user

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

When **Allbridge 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](/allbridge-overview/networks-and-tokens.md) as the [Bridge Fee](/allbridge-overview/bridge-fee.md).

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 |
| {% endtab %}  |        |       |

{% tab title="3. XRPL bridge" %}
{% embed url="<https://www.youtube.com/watch?t=6s&v=eQucgiziWSU>" %}

### **5 entities in the cross-chain token transfer process**

1. **User (Sender / Receiver)** - EOA (Externally Owned Account) / Wallet from which the token X is transferred from one chain to another.
2. **Non-XRPL chain smart contract** - a bridge smart contract on blockchains other than XRPL.
3. **Outgoing Transactions Ledger on NEAR** - a bridge smart contract on the NEAR blockchain.
4. **Allbridge Validator** - an off-chain entity responsible for verifying Lock and Burn transactions on the bridge smart contracts.
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**

![](/files/5jZMtbjTTDbfg6U4Pe4W)

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. When a user clicks the “Receive” button on the bridge UI, the **User** asks **Validator** to receive the X tokens on the XRPL.
3. **Validator** checks if funds were actually locked/burnt on the **non-XRPL chain smart contract.**
4. If they were, the **Validator** sends an Unlock/Mint transaction to the **Outgoing Transaction Ledger on NEAR**.
5. After that, the **Validator** triggers **XRPL Sender.**
6. **XRPL Sender** checks the finality of the Unlock/Mint transaction on **NEAR OTL.**
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**

![](/files/FHHjJt9wXEDi6rI5Tz7U)

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. With the **Receive** transaction, the **User** asks **Validator** to check the request log.
3. **Validator** checks if funds were actually sent (locked/burnt) to the **XRPL**.
4. If they were, the **Validator** sends its signature to the **User**.
5. **User** sends the signature to the **non-XRPL chain smart contract.**
6. **Non-XRPL chain smart contract** unlocks/mints the requested X tokens and sends them to the **User** immediately.
   {% endtab %}
   {% endtabs %}