# What is Allbridge Core? Allbridge Core is a cross-chain bridge designed for seamless transfers of dollar-pegged stablecoins. It enables users and applications to move liquidity across a wide range of blockchains, including most EVM networks as well as Tron, Solana, Sui, and Stellar. Unlike traditional bridges that rely on wrapped assets, Allbridge Core uses a unified virtual stablecoin model to connect independent liquidity pools on different chains. This approach delivers a faster, safer, and more capital-efficient way to move stablecoins between ecosystems. The system is fully non-custodial. Smart contracts on each supported chain hold all liquidity, execute stable-swap conversions, and enforce the invariant that binds the pools together. Allbridge never has access to user funds—only the pool contracts can move assets. ## Key Features ### Native cross-chain transfers powered by multi-chain liquidity pools Allbridge Core moves stablecoins natively between blockchains without wrapping. Each supported network has its own stablecoin pool, and these pools are connected through a virtual asset (vUsd). This architecture allows transfers to execute through a stable-swap mechanism while all assets always remain native to their chains. Transfers use invariant-based stable-swap math to ensure predictable execution and efficient pricing. Pool imbalances naturally create arbitrage opportunities, helping keep liquidity aligned across all chains. ### Flexible fee payment and optional gas top-up Users can pay bridge fees either in the gas token or in the stablecoin being transferred. Transfers can also include an optional gas top-up, sending a small amount of the destination chain’s gas token to ensure the user can cover their first transactions after bridging. ### Real-time rewards for liquidity providers Liquidity providers earn 80% of all transfer fees. Rewards are added instantly with each transaction, without lockups or withdrawal restrictions. Historical performance data helps LPs evaluate volume and yield trends for each pool. ### Additional transfer options on selected routes (CCTP & OFT) Where supported, Allbridge Core can route transfers through Circle’s CCTP or LayerZero’s OFT standards. These options provide alternative transfer mechanisms for assets that support their own native cross-chain standards, such as USDC via CCTP and USDT via OFT. ### Non-custodial and audited All liquidity is held directly by smart contracts on each chain, not by Allbridge. The protocol has undergone multiple independent audits, with ongoing monitoring to maintain security across all supported networks. ## Supported Blockchains Allbridge Core supports major blockchain ecosystems used for stablecoin transfers, including: * EVM chains (Ethereum, BNB Chain, Polygon, Avalanche, Arbitrum, Base, Celo, Optimism, Linea, Unichain, Sonic) * Tron * Solana * Sui * Stellar The main stablecoin assets supported are USDT and USDC and new pools and assets are added over time as the network expands. Please check [https://core.allbridge.io](https://core.allbridge.io/) for currently supported assets on each blockchain. # How does Allbridge Core work? Allbridge Core enables native stablecoin transfers between blockchains by connecting independent liquidity pools through a virtual stable-swap mechanism. Instead of minting wrapped tokens or relying on custodial accounts, the protocol uses smart contracts on every supported chain to hold liquidity, process swaps, and coordinate cross-chain messages. At the center of the system is a virtual asset called vUsd. It acts as the common reference point between all pools and allows the protocol to apply stable-swap mathematics across multiple blockchains. This lets users transfer stablecoins from one chain to another while the underlying liquidity stays within the protocol’s non-custodial smart contracts. The following sections break down each part of the system in more detail. ## Single-Asset Pools with Virtual Balances Each supported chain has a single-token liquidity pool—either USDT or USDC depending on the chain.\ Internally, however, every pool also maintains a balance of vUsd. When liquidity is added, the pool splits it into two parts: the deposited stablecoin and an equivalent amount of vUsd. This creates a virtual two-asset pair that behaves like a stable-swap pool, even though only one token exists on-chain. This design allows every pool to independently use an invariant-based pricing model without requiring two real assets on each chain. ## Stable-Swap Logic Across Multiple Blockchains The pool uses stable-swap mechanics to determine the exchange rate between the stablecoin and vUsd. When a user initiates a transfer: 1. The transferred stablecoin is added to the source pool. 2. The pool performs a stable-swap from the stablecoin into vUsd. 3. The amount of vUsd obtained becomes the value carried across chains. On the destination chain, the pool performs the reverse operation—swapping vUsd into the local stablecoin and releasing it to the user. Because each pool tracks both real and virtual balances, the invariant remains consistent across all pools. When liquidity shifts from one chain to another, prices adjust automatically: pools with excess stablecoins become more expensive to deposit to, and pools with shortages become cheaper. This naturally creates arbitrage incentives that help restore balance. ## Cross-Chain Messaging To complete a transfer, Allbridge Core passes a message from the source chain to the destination containing: * the amount of vUsd sent from the source * the target chain and token * recipient address and optional extra gas amount Smart contracts on the destination chain receive the message and finalize the swap back to stablecoins. This mechanism ensures that transfers always complete based on the state of the pools, without custodial intermediaries. Some routes additionally support alternative transfer methods, such as CCTP or LayerZero OFT, for assets with official native bridging standards. When available, these options can be selected directly in the UI. ## Keeping Pools Balanced Since each transfer shifts liquidity from one chain to another, pools can become imbalanced over time. Allbridge Core’s pricing automatically reflects this. A pool running low on stablecoins becomes more expensive to withdraw from in terms of vUsd, and a pool with excess stablecoins becomes cheaper. These price differences create arbitrage opportunities for traders, which in turn move liquidity back toward equilibrium. In practice, these balance shifts mean that the amount a user receives may differ slightly from the nominal value of the transfer. This difference comes from the pool’s current state and the stable-swap calculation—it is not a protocol fee. When arbitrage activity brings pools closer to balance, rates return toward neutral levels. This mechanism allows Allbridge Core to operate across many chains without manual rebalancing by the protocol itself. This continuous rebalancing is a key part of the design and ensures that liquidity remains available for both regular users and liquidity providers. ## Liquidity Provider Rewards Liquidity providers earn 80% of all fees collected by the swap pools. Rewards accrue automatically with every transaction and are distributed continuously. There are no lockups—LPs may withdraw their liquidity at any time. Because rewards depend on actual volume rather than fixed emissions, yields vary between pools. The Allbridge Core interface includes historical charts so providers can evaluate pool performance and volatility. You can check live data and deposit liquidity into Allbridge Core here: . # Fees Allbridge Core supports two types of transfer mechanisms, and the fee structure depends on which one is used: * Pool-based transfers (default for most routes) * CCTP / OFT transfers (available for specific assets and chains) The Allbridge Core interface always displays the full fee breakdown before a transfer is executed. Users should also verify the confirmation dialog in their wallet to see the exact fees charged by the blockchain. ## Pool-Based Transfers Pool-based transfers use Allbridge Core liquidity pools and the virtual stable-swap mechanism.\ The following fees apply: ### Relayer Fee Covers the cost of executing the transaction on the destination chain. This fee varies depending on destination chain gas price and overall transaction costs there. Transfers to chains with higher gas costs will require a higher relayer fee. ### Liquidity Provider Fee A total fee of 0.3% is applied by the pools: 0.15% on the sending side and 0.15% on the receiving side. 80% of this fee is distributed to liquidity providers in real time. ### Optional Gas Purchase Users may choose to add a small extra amount to receive native gas tokens on the destination chain.\ This “gas top-up” is convenient when bridging to a network where the user has no gas balance. ### Price Impact from Pool Balances (Not a Fee) Pool-based transfers use stable-swap mechanics. Depending on the current pool balance, the swap result may be: * positive (user receives slightly more), or * negative (user receives slightly less) These differences are not fees! They reflect the state of the liquidity pool and can be arbitraged back to balanced conditions by external traders. Important note about this price impact is that it might differ from the one displayed in the UI when the transfer starts. This happens because when the receive transaction is submitted on the target chain the state of the pool may differ from the state when the transfer was initiated. ## CCTP / OFT Transfers For routes using Circle’s CCTP or LayerZero’s OFT, the fee structure differs because the transfer does not interact with Allbridge Core liquidity pools. The following fees apply: ### Relayer Fee Same as in pool-based transfers. This fee covers the cost of completing the transaction on the destination chain. ### Service Fee A flat 0.1% fee applied to the transferred amount when using CCTP or OFT routes. ### Optional Gas Purchase Same optional gas top-up mechanism available for pool-based transfers. There is no LP fee and no pool price impact because liquidity pools are not involved. ## Paying Fees: Gas Token or Stablecoin Both pool-based transfers and CCTP/OFT transfers support flexible fee payment: * Fees may be paid in the native gas token of the source chain, or * Deducted from the stablecoins being transferred This applies to relayer fees and optional extra gas purchase fees. The user can choose the preferred option in the interface before sending the transfer. ## Checking Fees Before Transfer Fees differ between chains, assets, and transfer types. To avoid surprises, users should always: * Review the fee breakdown in the Allbridge Core UI * Confirm the details shown in their wallet’s transaction dialog Both reflect the exact fee configuration for the selected route at the time of transfer. # Messaging protocols Messaging is the middle step in the Allbridge Core transfer flow. Every pool-based transfer follows the same sequence: 1. Swap on the source chain: the user’s stablecoins are deposited into the source pool and swapped into vUsd. 2. Message sent to the destination chain: this message carries the information needed to complete the transfer. 3. Swap on the destination chain: the destination pool swaps vUsd into the local stablecoin and sends it to the recipient. Messaging does not move tokens across chains—it only provides the instructions that allow the destination chain to finalize the transfer. ## Messaging Options Depending on the route, the UI may allow users to choose between different messaging providers. These include: * Allbridge Messaging — a proprietary messaging layer optimized to be cost-effective. * Wormhole Messaging — uses the Wormhole network to pass the transfer message between chains. It is more expensive and not available on all blockchains supported by Allbridge. The UI shows which options are available for the selected route. Take note on the relayer fee and expected transfer time difference when you select a particular messaging protocol. ## CCTP and OFT Although CCTP, CCTP V2, and OFT appear in the same UI area as messaging options, they are not messaging choices for pool-based transfers. They represent separate transfer mechanisms that bypass Allbridge liquidity pools entirely: * CCTP / CCTP V2 use Circle’s official USDC burn-and-mint flow. * OFT (Omnichain Fungible Token) uses [LayerZero](https://layerzero.network/)’s OFT standard These routes do not use the swap–message–swap process and do not involve Allbridge Core pool mechanics. # Allbridge Core contracts ## Main Bridge Contracts
BlockchainChain IDContract
Ethereum10x609c690e8F7D68a59885c9132e812eEbDaAf0c9e
BNB Chain20x3C4FA639c8D7E65c603145adaD8bD12F2358312f
Tron3TAuErcuAtU6BPt6YwL51JZ4RpDCPQASCU2
Solana4BrdgN2RPzEMWF96ZbnnJaUtQDQx7VRXYaHHbYCBvceWB
Polygon50x7775d63836987f444E2F14AA0fA2602204D7D3E0
Arbitrum60x9Ce3447B58D58e8602B7306316A5fF011B92d189
Stellar7CBQ6GW7QCFFE252QEVENUNG45KYHHBRO4IZIWFJOXEFANHPQUXX5NFWV
Avalanche80x9068E1C28941D0A680197Cc03be8aFe27ccaeea9
Base90x001E3f136c2f804854581Da55Ad7660a2b35DEf7
OP Mainnet100x97E5BF5068eA6a9604Ee25851e6c9780Ff50d5ab
Celo110x80858f5F8EFD2Ab6485Aba1A0B9557ED46C6ba0e
Sonic120x801217549ab4b0860bb506b1cbff90f42819a116
Sui130x83d6f864a6b0f16898376b486699aa6321eb6466d1daf6a2e3764a51908fe99d
Unichain140x782e918ED2b3d161e90c5E154fed3E93D705C598
Algorand15KB2YJBRULWSHID77HLX4XKATV7CR56AQD7UCDXJQOXGA2BIXTD7JLKGRRU
Stacks16SPN9GJ5CK3F3X4NPR7FNEQ72TAAHA0EGB9A7DEG5.bridge
Linea170xf3Dd9d692A9b4Df331E3bb1C8f322BA0B299B907
## CCTP Interface Contracts
BlockchainContract
Arbitrum0x23e1aec13c92158643cf2aa17e155d27a792ccdb
Avalanche 0x65dE05Fccce36Ce7FdDd668Ef4348D9e933B57Ff
Base0x1eFE2C85989D97fEBbD0743cdd79B9F0826314f6
Ethereum0xC51397b75B783E31469bFaADE79913F3f82210d6
OP Mainnet0x08391edF36f41f05d27A1e0fD7a29448417C1CD0
Polygon0x710282BfeB554Ed0A34dFaD061C7c343221AC82C
SolanaCctpV8uRiXws7KZxpUXfPWy9BhCiWaeBRzsJgELvQKvu
Sui0xf68268c3d9b1df3215f2439400c1c4ea08ac4ef4bb7d6f3ca6a2a239e17510af
## CCTP v2 Interface Contracts
BlockchainContract
Ethereum0x7972d6907739593C00e6284c53C83dB3ECd15c33
Arbitrum0x7ED5343dFC95dc3eBe5B6de64F5B5423A888Ca18
Avalanche 0x5FBf8d23fa705A0bADb6f398fDcdC28FCCB521c0
Base0x214D972b8c869cfcE50D55B595adC7eF336D7FAd
## OFT Interface Contracts
BlockchainContract
Ethereum0xeC455fFC19811e573eb5700a1bDff6ee1C47AB7B
Arbitrum0xB074e73e637E778BE6411c3732bD58D44194FDEa
TronTWPziSAroSacAjDuL52ByQzU86s9mP2gPr
## Liquidity Pools
BlockchainTokenContract
AlgorandUSDC3Z4IGPCUEH6SSWPLJHKHN4WE2VTTEISBXL454VBT7QUWBFC3RYKOZ57AXA
ArbitrumUSDC0x690e66fc0F8be8964d40e55EdE6aEBdfcB8A21Df
USDT0x47235cB71107CC66B12aF6f8b8a9260ea38472c7
USDe0x5d3a1Ff2b6BAb83b63cd9AD0787074081a52ef34
AvalancheUSDC0xe827352A0552fFC835c181ab5Bf1D7794038eC9f
USDT0x2d2f460d7a1e7a4fcC4Ddab599451480728b5784
BaseUSDC0xDA6bb1ec3BaBA68B26bEa0508d6f81c9ec5e96d5
BNB ChainUSDT0xf833afA46fCD100e62365a0fDb0734b7c4537811
USDC0x731822532CbC1c7C48462c9e5Dc0c04A1Ff29953
CeloUSDT0xfb2C7c10e731EBe96Dabdf4A96D656Bfe8e2b5Af
EthereumUSDC0xa7062bbA94c91d565Ae33B893Ab5dFAF1Fc57C4d
USDT0x7DBF07Ad92Ed4e26D5511b4F285508eBF174135D
USDe0x4c9EDD5852cd905f086C759E8383e09bff1E68B3
LineaUSDC0x39A421B7483e9fEF39945a047637f8BaD260E2c4
OP MainnetUSDC0x3B96F88b2b9EB87964b852874D41B633e0f1f68F
USDT0xb24A05d54fcAcfe1FC00c59209470d4cafB0deEA
PolygonUSDC0x4C42DfDBb8Ad654b42F66E0bD4dbdC71B52EB0A6
USDC.e (deprecated)0x58Cc621c62b0aa9bABfae5651202A932279437DA
USDT0x0394c4f17738A10096510832beaB89a9DD090791
SolanaUSDCG6Qo3WW7RbWpSmACAocTBVgx6JW5kgRpUhABphEoDMfP
USDTEs9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB
StacksUSDCxSPN9GJ5CK3F3X4NPR7FNEQ72TAAHA0EGB9A7DEG5.pool-usdc
StellarUSDCCAOTMWRKNMV5GWSVOMWCTCM5ZZFEQFUSWNLCZXA2KAXD4YG5A4DIPNFT
TronUSDTTAC21biCBL9agjuUyzd4gZr356zRgJq61b
SuiUSDC0xbeefbb4e4b435ba0c0dc12fa6369859715b600d38fd9c4924b9a526b89b3ce2c
SonicUSDC0xCA0dc31BdA6B7588590a742b2Ae6A4F67b43c71F
UnichainUSDC0xBA2FBA24B0dD81a67BBdD95bB7a9d0336ea094D7
USDT0xD0a1Ff86C2f1c3522f183400fDE355f6B3d9fCE1
## Core Yield Contracts
Celo0xbEFF0CA03F5a9d4eb79057c81d2596265a63120d
## ABR0 Token Contracts
BlockchainAddress
Arbitrum0xd450dB3188b7Fbf52C670eee30372ba74B4c5857
Avalanche0xd450dB3188b7Fbf52C670eee30372ba74B4c5857
Base0xd450dB3188b7Fbf52C670eee30372ba74B4c5857
BNB Chain0xd450dB3188b7Fbf52C670eee30372ba74B4c5857
Celo0xd450dB3188b7Fbf52C670eee30372ba74B4c5857
Ethereum0xd450dB3188b7Fbf52C670eee30372ba74B4c5857
OP Mainnet0xd450dB3188b7Fbf52C670eee30372ba74B4c5857
Polygon0xd450dB3188b7Fbf52C670eee30372ba74B4c5857
Solana4WRBAuvUfpuJmDhWcsQFRoiaFrbGN3s5j2LtwXQjFVo2
Sonic0xd450dB3188b7Fbf52C670eee30372ba74B4c5857
Unichain0xd450dB3188b7Fbf52C670eee30372ba74B4c5857
# Liquidity provision Allbridge Core allows users to supply stablecoins to liquidity pools on supported chains. These pools enable cross-chain transfers and earn fees from transfer activity. Liquidity is always held in smart contracts, and there are no lockups or staking requirements. ## Adding Liquidity Users can add liquidity to any available pool by depositing the supported stablecoin for that chain.\ When liquidity is added: * The pool records the deposit as a combination of real stablecoins and virtual vUsd. * The depositor receives pool tokens representing their proportional share of the pool. * There are no restrictions on how long liquidity must remain in the pool. Each deposit immediately starts contributing to processing future transfers on that chain. Important: always check how many LP points you're going to receive for the liquidity provided. On pools out of balance LP point amount can be lower than the balance you deposit. You can deposit to liquidity pools here: . ## Withdrawing Liquidity Liquidity can be withdrawn at any time. Unlike with liquidity deposit the user will always receive 1:1 underlying stable coins to the amount of LP points sent for withdrawal. The state of the pool does not affect this amount. ## Rewards Liquidity providers earn a share of the fees generated by pool-based transfers. Specifically: * LPs receive 80% of the 0.3% pool fee (0.15% on the sending side and 0.15% on the receiving side). * Rewards accumulate continuously as transfers occur. * Accumulated rewards are separate from the main liquidity and require claiming and re-depositing to be added to the pool. Or you can use [Allbridge Core Yield](/product/allbridge-core-yield) feature (not yet available for all chains) which takes care of redepositing accumulated rewards automatically. * Yields vary depending on transfer volume and the size of the pool. The interface displays annualized APY estimates based on recent activity (7-day or 30-day lookback) to help providers evaluate expected performance. ## Risks and Considerations Liquidity provision in Allbridge Core does not involve impermanent loss, and withdrawal amounts always match the LP’s share of the pool. However, rewards depend on actual transfer volume, which may vary over time. Periods of lower activity will result in reduced fee earnings, while activity spikes can increase returns. Conditions on individual blockchains—such as gas costs, congestion, or changes in available routes—may also affect the overall experience of adding or removing liquidity. Users should regularly review pool statistics and historical performance to understand how these factors may influence their returns. # FAQ In this section you can find answers to the most common questions regarding Allbridge Core # How to transfer assets? Swap page is the first screen you will see when opening [https://core.allbridge.io](https://core.allbridge.io/). Here is a short guide on how to use it and brief information on its elements.
* Enter amount to send (1) * Choose asset and blockchain to send the tokens from (2) * Connect source wallet (3) * Select destination blockchain and token (4) * Connect destination wallet (5) or simply paste (6) an address on destination chain to receive the tokens * (Optional) Drop some gas tokens to the destination address (7), this is especially useful if it is a new wallet address and you need to fund its first several transactions * (Optional) Configure how you want to pay for the relayer fee (8), either with gas tokens on the source chain or from the stablecoin amount you're sending * Push Send button (9) to start the transfer, after confirming transaction in your wallet the transfer will be on its way There are some other UI elements on this page you might find useful: * Button (10) to open the Best Rates panel. Since stablecoin rates are fluctuating on Allbridge Core (read more about this [here](/product/how-does-allbridge-core-work#stable-swap-logic-across-multiple-blockchains)), you might want to see which bridging direction will give you the best exchange rate and the Best Rates panel will provide this information. * Button (11) to open the transfer Details panel. This panel has a breakdown on all the fees as well as allowing you to select the messaging protocol you want to use for sending your transfer. * Approximate transfer time (12) informs you about how long the transfer will take (based on the historical data). This is not a guarantee (the transfer can take longer or be faster), but it is always a good estimation. * And finally, because the pool state on the receiving side might change once the transfer reaches the destination, the amount you receive could be slightly more or less than you expected considering all the fees. With the Minimum Receive field (13) we show you probabilistically the worst case, the minimum expected amount you might receive based on other transfers currently processing. Once you send the transfer you will be redirected to the transfer progress screen.
This is a simple progress screen for you to monitor all transfer stages: 1. Sending transaction making it way to the blockchain 2. Message with transfer details being confirmed on the source chain (you can read more about messaging [here](/product/how-does-allbridge-core-work/messaging-protocols)) 3. Message receiving on the destination chain 4. Final token receiving transaction on the destination chain Unless you're transferring to Stellar you can safely close this transfer screen and do other important things while your transfer is being processed. On Stellar you might need to create a trustline to be able to receive the token on the destination wallet. In this case the transfer progress screen will prompt you to sign a trustline creation transaction. And soon enough your transfer is finished and you see the success screen.
You can always find your past transfers visiting the History window, accessible with history button on the toolbar in the top right corner of your screen (or just open ). If you need any help with starting the transfer or with ongoing transfers, just contact our support (look for the friendly Need help? button on the bottom right).
# How to provide liquidity? Allbridge Core liquidity pools are accessible here: . Once you open the page you can see the list of pools where you can earn rewards for providing liquidity. You can read more about liquidity provision and how rewards are generated [here](/product/faq/how-to-provide-liquidity). Each pool card contains information about pool status and your contribution to the pool (once the wallet providing the liquidity is connected). Let's do a quick overview.
* You can see pool TVL (total value locked), which is a total amount of tokens already in the pool and its imbalance (1). Please note that depositing liquidity in a pool with high imbalance (more than 10%) will net you less LP points * Then you can see historical performance (2) of the pool. The reward amount is not guaranteed and depends on the bridging activity of the pool. The APR (annual percentage rate) displayed there is calculated based on the last 30 days of activity (you can switch between 7 days and 30 days in the UI). There is also a button to open [Pool Performance](#pool-performance). * There is an area which shows your contribution to the pool (3). There you can see the total amount of LP tokens provided, rewards amount ready to be claimed and Claim button to do so. This area will populate only if you connect the wallet already contributing to the pool. And finally Manage button (4) opens a screen to manage (deposit or withdraw) liquidity in the pool.
* You can enter amount (1) you want to deposit to the pool * It is important to verify how much LP points you will get (2). If the pool is imbalanced (see above) this value can be lower than the amount in tokens. And you can also see a projected APR for your new contribution based on a historical pool activity. Click Deposit button (3) to initiate the deposit. On EVM chains the wallet can prompt you to allow pool contract access to your tokens first (you can read more about it [here](/product/faq/what-is-an-approve-transaction)). ## Liquidity Withdrawal Once the funds are deposited you can withdraw them any time, there are no locks on the liquidity. And on withdrawal LP points are always converted 1:1 to the underlying stable coin.
Here you can enter the amount you want to withdraw (1), consult the preview of the result (2) of the withdrawal (the amount of stable coins and accumulated rewards you're going to receive) and click the Withdraw button (3) to initiate the process. ## Pool Performance To give you more insight into the historical data we've added this advanced tool to see different stats on different liquidity pools for different time intervals and compare them.
* In the pool selection panel (1) you can filter and select one or several liquidity pools to compare * Metric selection panel (2) allows you to switch displaying APR, absolute rewards amount, volume and TVL of the pool * Interval selection (3) triggers loading different time intervals to display: 7 days, 30 days or 3 months * And on the graph itself we also plot the average value (4) for each of the pool across the time interval selected Overall Pool Performance is a great tool to assess the rewards volatility across different pools and help you decide where you want to provide liquidity with the best and most consistent returns. # What is an Approve Transaction? On EVM blockchains (Ethereum, BNB Chain, Polygon, Arbitrum, Base, etc.) and on Tron, you cannot simply send tokens together with a smart-contract call. You must first give the contract permission to access a specific amount of your tokens. When using Allbridge Core, you will see an Approve prompt before sending tokens or providing liquidity. To minimize security risk, Allbridge Core only requests approval for the exact amount needed. Some other dApps ask for unlimited access to your tokens, but we avoid this approach. In most wallets you can also review and, in many cases, edit the exact amount being approved before confirming the transaction. Please note that approving exact amounts means you will need to sign and pay for an approval transaction each time you interact with Allbridge Core. On blockchains like Solana, Stellar, and Sui, tokens are transferred to smart contracts in a different way, so no approval step is required there. # Security audits ## Kudelski Security [Access the full report here](https://kudelskisecurity.com/blockchain-archive/allbridge-core-security-assessment) ## Quarkslab [Access the full report here](https://allbridge.io/assets/docs/reports/24-01-1500-REP-Allbridge%20Soroban%20Bridge-v1.2.pdf) ## Sherlock [Access the full report here](https://allbridge.io/assets/docs/reports/allbridge-public-audit-contest-report.pdf) # Ecosystem reports ## Latest Report [October, 2025](https://drive.google.com/file/d/1GOouBWkJ2saKR_vWqP8D6fvx5VWrb5R8/view?usp=drive_link) ## Archive * 2025: [January](https://drive.google.com/file/d/1aPkm2N5OCSmTrFSSadhS06CWMyu66oSm/view?usp=drive_link), [February](https://drive.google.com/file/d/1CJa2cWyMwU2AMvsOBIx6fKb6UQYphjiR/view?usp=drive_link), [March](https://drive.google.com/file/d/1oNRq0H62ih1cEkBUJa2Vg8JsqeZRTj3f/view?usp=drive_link), [April](https://drive.google.com/file/d/1e5UeUZKtEvHyW5UQO80fgbzWELVtKRYE/view?usp=drive_link), [May](https://drive.google.com/file/d/17bBA6ZqYCrnf-EaV1cxRo_BgKbjyjucS/view?usp=drive_link), [June](https://drive.google.com/file/d/19LOGJ2cvh8ymeFpUFiiV3JP1I1epv0ch/view?usp=drive_link), [July](https://drive.google.com/file/d/1ruRle8tuysuY4I0DN9D0b-bciNdxuQI0/view?usp=drive_link), [August](https://drive.google.com/file/d/1qAxyhXdr5lwTP6vKHkbCY5n4VRR6pKuD/view?usp=drive_link), [September](https://drive.google.com/file/d/1xij6NMTQPa7vgljd76JFqh0aV31sKzp_/view?usp=drive_link) * [2024](https://drive.google.com/file/d/1KTGwtX96EQpLRLqboiZVlVNEVkuCVd4r/view?usp=drive_link): [January](https://drive.google.com/file/d/1QjRoEriFBov3a8CXZesRzYJxymUoFgu_/view?usp=drive_link), [February](https://drive.google.com/file/d/1QsjTXqsl8JOhV22J2mQJlmuSREwq84GO/view?usp=drive_link), [March](https://drive.google.com/file/d/1BuVUx0O0z8sVYiTxMzGOUU2DFkiWKJPT/view?usp=drive_link), [April](https://drive.google.com/file/d/14Dszas99WLgrVRXzgQ79rhtZLI1PU5VT/view?usp=drive_link), [May](https://drive.google.com/file/d/1lE-zwbrmNgVEDVa5t2pRCo9AiI2vvex3/view?usp=drive_link), [June](https://drive.google.com/file/d/1aPr2yb-MUVIh6DD7F6d3eU2R41_TIWjp/view?usp=drive_link), [July](https://drive.google.com/file/d/1gZ2KcBPNM_JC_xstw4_dUYWkJSZRQy7L/view?usp=drive_link), [August](https://drive.google.com/file/d/1mXVSesTrv8nOrgDPMf-gCvqmP4eY34Jm/view?usp=drive_link), September, [October](https://drive.google.com/file/d/1asIGjDM8sBcI4xr15uiDgBuL4R4OsXka/view?usp=drive_link), [November](https://drive.google.com/file/d/1JugtjUUBP7CxlFzgQt4Dntkt2s-URzLH/view?usp=drive_link), [December](https://drive.google.com/file/d/1l5XMZSRNAtPOkwVWeG77KRL1a-4azXb9/view?usp=drive_link) * 2023: [January](https://drive.google.com/file/d/1VMGz8sGGp2uKWJ6GqEdDVQovsyc19BWY/view?usp=drive_link), [February](https://drive.google.com/file/d/1teENtaU43DwTxsEtT5m9-Z-3nSHKHPVz/view?usp=drive_link), [March](https://drive.google.com/file/d/17lbyLEA5scVkpW3c4eyiGfiUnd8IHUwg/view?usp=drive_link), April, May, June, [July](https://drive.google.com/file/d/1IJ_A0gByOrhlCE3_1N8NlATjXIYFQpUf/view?usp=drive_link), [August](https://drive.google.com/file/d/1PEWA7Lx2xe8KlvyOznWFLYfrR-45wW2W/view?usp=drive_link), [September](https://drive.google.com/file/d/1kxJ4IOIL_qBeg-RYRIU9I53mQF-1cWnb/view?usp=drive_link), [October](https://drive.google.com/file/d/1z8QJmz9XxwMEQfGUpiBCOCuA2JWiDZB5/view?usp=drive_link), [November](https://drive.google.com/file/d/1PjOD7QGXQd8wObFYvHG-jVO_6qnWwLrX/view?usp=drive_link), [December](https://drive.google.com/file/d/1e09doc8JXEB3Y9M4QOo9c8Uk4aefkJ8Y/view?usp=drive_link) * 2022: [January](https://drive.google.com/file/d/1tUK-oKF7MAZj-ylZq9RKAzHGiKX2xK-D/view?usp=drive_link), [February](https://drive.google.com/file/d/1xhWWWO1g9h6XGkxUsfeHybsFen0tCwuV/view?usp=drive_link), [March](https://drive.google.com/file/d/1Dp0uRpqlWXnPi0oynvd-0mbEg8GhdCH9/view?usp=drive_link), [April](https://drive.google.com/file/d/1zklH6nN5t-IDVabM_OUHqdawNmlaboX6/view?usp=drive_link), [May](https://drive.google.com/file/d/1bQLQ9tabTu7zQTYlgER_4mJVirHvdoC-/view?usp=drive_link), [June](https://drive.google.com/file/d/1Hlr270j5VkrCiW-0SEA02IvJGleCy6P4/view?usp=drive_link), [July](https://drive.google.com/file/d/1TtPYmE5kwEpcLjChlDZDjicrxpJ8qOeM/view?usp=drive_link), [August](https://drive.google.com/file/d/1_X2r4QpoWlOFax3fZGy8X1IEphWNqU9-/view?usp=drive_link), [September](https://drive.google.com/file/d/1U_lajhCK7RejsS33z6Imc9aBhaDpn2lf/view?usp=drive_link), October, [November](https://drive.google.com/file/d/1BXMBzh_sSZzGIEa9y5oBWl8MHT6cYuD_/view?usp=drive_link), [December](https://drive.google.com/file/d/1MCj6XdjHbyHW8_L02PFskHca9_G8xRrA/view?usp=drive_link) * 2021: [October](https://drive.google.com/file/d/1-9MXVxitgxwZ7kNT4vK0YiuaqgekYsL5/view?usp=drive_link), [November](https://drive.google.com/file/d/1N_1alLXnSnJdDDyUwslnI3_AMpGkXoS4/view?usp=drive_link), [December](https://drive.google.com/file/d/1JIK5p2r7BBNuDm-Ci8MSVzrYh6VRh0ho/view?usp=drive_link) # ABR0 Token ABR0 Token is a main token of Allbridge Core. It can be used to pay relayer fees with a discount for cheaper transfers via Allbridge Core. ABR0 if an omnichain fungible token, deployed according to the OFT standard by LayerZero. You can read more about the standard [here](https://docs.layerzero.network/v2/concepts/applications/oft-standard). To pay relayer fees in ABR0 choose it as an option when creating a transfer.
## How to get ABR0? If you are a holder of our legacy token ABR, you can migrate it to the new ABR0 as a 1:1 migration [here](https://token.allbridge.io/migrate). For the new holders we've set up several liquidity pools where you can buy ABR0 on-chain: * Ethereum: * Solana: After you get ABR0 tokens you might need to bridge them to other blockchains. To do this please use our official ABR0 bridge: . To make sure you're buying the correct token you can reference ABR0 Token Contract address from our [Contracts page](https://docs-core.allbridge.io/product/how-does-allbridge-core-work/allbridge-core-contracts#abr0-token-contracts). # Leaderboard ## Overview #### What is the Allbridge Core Leaderboard? The Allbridge Core Leaderboard is a feature that tracks and ranks the most active users based on their platform engagement, such as transaction volume and event participation. It fosters a sense of competition and community by encouraging users to stay active and compare their performance with others through a clear ranking system, enhancing overall user experience and involvement. #### How Can I Access the Leaderboard? The Leaderboard can be found on the Allbridge Core website by visiting[ core.allbridge.io](https://core.allbridge.io/) and navigating to the "Ranks" section or going directly to [core.allbridge.io/leaderboard](https://core.allbridge.io/leaderboard) and registering there. ## Guide Below, you will find detailed instructions on how to connect to the Allbridge Core Leaderboard. 1. Head over to [Allbridge Core “Ranks”](https://core.allbridge.io/leaderboard)
2. Sign in 3. Select your preferred chain and wallet (for the purposes of this guide, we used Ethereum)
4. Confirm the action in your wallet
5. Proceed to Registration to choose your profile picture and username 6. When you are done, Finish your registration
7. Congrats, you are now a part of the Leaderboard community
How to link more wallets? In Leaderboards, you can link any number of new wallets and combine your total score under one profile 1. To add more wallets, go over to your profile.
2. Select Link wallet
3. Choose the desired chain and link your address
4. Lastly, confirm the action in your wallet
## Leaderboard Functionality **How does the Leaderboard work?** Allbridge Core Leaderboard functions by tracking users' activities on the platform and awarding points based on specific actions. Users earn points for bridging or providing the liquidity, and these points are then multiplied according to the user's level on the platform. The Leaderboard dynamically updates with every new transaction, reflecting the latest standings. **What data is displayed on the Leaderboard?**\ \ The Allbridge Core Leaderboard displays key information about the registered players. This includes the user's level, username, current score, and overall standings. The leaderboard provides a clear overview of who the top performers are, allowing users to see where they rank relative to others in the community. **How frequently is the data on the Leaderboard updated?** The data on the Allbridge Core Leaderboard is updated in real time. This means that every time there is a new transaction on the platform, the leaderboard instantly reflects the latest standings. Continuous updates ensure that users always see the most current rankings based on their and others' activities. **How do user levels work?** User levels on the Leaderboard are designed to reflect the user's overall engagement and activity. Users who participate in activities earn points that contribute to leveling up. Each level has a specific score threshold that users must reach to advance to the next level. Levels are capped at 10, providing a structured progression system. Additionally, as users level up, their profile picture changes, adding a unique visual flavor to their profile that reflects their current level. **What are level bonuses?** Level bonuses on the Allbridge Core platform offer both visual enhancements and ranking advantages as you progress through the levels. Specific levels award you with point multipliers, boosting your ability to accumulate points faster. ## Referral program **Referral bonus** When you refer someone to the platform, you receive 10% of the total points earned by the person that you referred (including their multiplier). This means that as your invitee levels up, the points you earn from them increase, helping you to climb the Leaderboard more quickly and effectively. **Reward calculation algorithm** Every $1 spent on relayer and liquidity fees or claimed from liquidity provision rewards you with ≈100 Leaderboard points. The level multiplier can further amplify this number, increasing the total number of points received. The multipliers are structured as follows: at level 2, you receive a 10% bonus; at level 4, a 20% bonus; at level 7, a 30% bonus; and at level 10, a 50% bonus. These multipliers accelerate your point acquisition, making it easier to climb the Leaderboard and achieve higher rankings. **Examples** 1. Scenario:\ Level 1 Referrer spends $5 on liquidity fees\ \ Rewards:\ This will earn him ≈ 5 \* 100 ≈ 500 points since no multiplier is applied 2. Scenario:\ Level 2 Invitee claims $3 from liquidity provision\ \ Rewards:\ Invitee will receive ≈ 3 \* 100 + 300 \* 0.1 ≈ 330 points (applying the 10% multiplier from Level 2)\ Referrer will receive 330 \* 0.1 ≈ 33 points 3. Scenario:\ Level 8 Invitee spent $7 on referral fees\ \ Rewards:\ Invitee will receive ≈ 7 \* 100 + 700 \* 0.3 ≈ 910 (applying the 30% bonus from Level 8)\ Referrer will receive 910 \* 0.1 ≈ 91 points ## Frequently Asked Questions (FAQ) **Q: What should I do to receive points on the Leaderboard?**\ A: To receive points on the Allbridge Core Leaderboard, you need to interact with the platform by either bridging assets or providing liquidity. Additionally, referring more people to the platform can also earn you points. **Q: How do I register/link my other wallets?**\ A: To register or link your other wallets, please refer to our detailed guide provided in the previous section of the documentation. This guide will walk you through the process step-by-step, ensuring that you can seamlessly sync your wallets with your user profile. **Q: I have registered 2 or more times, how to merge my accounts into one?**\ A: If you have registered multiple times and need to merge your accounts into one, please contact our support team. They will assist you in merging the accounts manually to ensure that all your activities and points are consolidated under a single account. **Q: How often is the data updated?**\ A: The data on the Allbridge Core Leaderboard is updated in real time with every new transfer made on the platform. This ensures that the rankings reflect the most current activities and transactions, allowing users to see their standings and progress as soon as they engage with the platform. **Q: How are the points calculated?**\ A: Allbridge Core Leaderboard points are calculated for each $1 spent on relayer fees and liquidity fees as well as for each $1 claimed from providing the liquidity. Additionally, your rewards are influenced by your user level, with a level multiplier applied to the points you accumulate. This means that the higher your level, the more points you receive for your activities, enhancing your overall ranking on the Leaderboard. **Q: How can I remove my account?**\ A: Currently, Leaderboard accounts cannot be removed. Once you have registered and started using the platform, your account, and its associated data remain active. No private information is stored about the user, just the anonymous address.
# Allbridge Core Yield ## What is Allbridge Core Yield? Allbridge Core Yield is a yield-generating smart-contract system integrated directly with our liquidity pools. When you deposit stablecoins into the Core Yield contract, you receive a representative dollar-pegged token, CYD (Core Yield Dollar). Unlike traditional interest-bearing tokens whose value increases over time, CYD maintains a stable peg. Instead, your CYD balance grows automatically as rewards are accrued, claimed, and reinvested by the protocol. This mechanism allows you to benefit from continuous, automatic compounding on our liquidity pools. ## How it works? 1\. Deposit stablecoins into the Core Yield contract 2\. Receive CYD Tokens 3\. The rewards are accrued automatically on CYD tokens ## Supported networks Allbridge Core Yield is live as a pilot on the Celo blockchain, allowing users to experience automatic yield compounding within the Allbridge Core ecosystem. You can try it now at[ core.allbridge.io/yield](https://core.allbridge.io/yield?utm_source=chatgpt.com) — simply connect your wallet, deposit supported stablecoins, and let rewards compound automatically. Support for additional blockchains will be introduced in future updates, expanding Core Yield across the wider Allbridge Core network. ## FAQ ### How to see CYD balance in my wallet? Some wallets require importing CYD token manually for it to show its balance. For example, in MetaMask you have to select "Import Tokens" menu command, then enter token contract address which can be found [here](/product/how-does-allbridge-core-work/allbridge-core-contracts#core-yield-contracts).
Alternatively you can click the MetaMask icon in the Core Yield UI to open Import tokens screen with token address already pre-filled.
### When CYD balance gets updated? If you see activity on the pool, but your CYD balance is not changing, it means there was no on-chain activity for the CYD token during this time interval. For CYD balance to change Core Yield pool must claim and re-deposit all the pending rewards. It happens when: * Any user deposits or withdraws funds from the CYD pool * CYD token is transferred between users # Deposit Addresses ## Overview Deposit Addresses are personal, cross-chain entry points that allow you to receive stablecoins on multiple blockchains and automatically bridge them to a single destination wallet. Instead of managing separate wallets, gas tokens, and manual bridge transactions on every chain, you can generate a set of Deposit Addresses. Any funds sent to these addresses are automatically detected and bridged to your main wallet on your chosen destination chain. Deposit Addresses are fully non-custodial. They are virtual constructs controlled by smart contracts, not by Allbridge servers. * No Private Keys: These addresses do not have private keys. Instead, they encode the routing logic (destination chain, recipient wallet, token type) directly into their structure. * Trustless: Only the smart contracts can move funds, and they can only move them to the pre-defined destination wallet you set up. ## Use Cases * Unified Payments: Accept stablecoin payments from users on Ethereum, BNB Chain, or Solana without needing to maintain active wallets on those chains. * Donations: Share a single deposit address for a specific chain to collect donations that auto-settle to your main account. * CEX Withdrawals: Withdraw funds from a centralized exchange directly to a Deposit Address to have them bridged to your preferred chain automatically. * Project Revenue: Separate revenue streams by generating different deposit addresses for different clients or projects, all routing to one treasury wallet. ## Supported Chains & Assets Deposit Addresses are currently deployed most of the EVM Chains supported by Allbridge: Ethereum, BNB Chain, Polygon, Avalanche, Arbitrum, Optimism, Base, Celo. Support for the rest of the EVM networks, Solana and Tron is planned soon. ## Fees and Limits ### Creation Fee There is a one-time gas fee to generate a Deposit Address. This pays for the on-chain registration of the address logic. You do not pay any monthly service fees. ### Bridging Fee When funds are auto-bridged, the standard Allbridge Core bridging fee applies (relayer fees and Liquidity Providers fees). There are no extra surcharges for using Deposit Addresses. ### Minimum Transfer Amount To prevent small deposits from being consumed entirely by fees, you must set a Minimum Transfer Amount (e.g., $10 or $50) during setup. * If a deposit is below this amount, it remains on the Deposit Address until more funds arrive to cross the threshold. * Once the threshold is met, the auto-bridge transaction triggers. ## Step-by-Step Guide #### 1. Connect Wallet Navigate to the Deposit Addresses tab in the Allbridge Core app and connect the wallet where you ultimately want to receive funds (Destination). Alternatively you can open this link: . Then push "Create Address" button.
#### 2. Configure Settings Choose the networks you want to accept deposits from (e.g., "I want to receive funds from BNB Chain and Polygon"). Then verify destination wallet address, choose the asset you want to receive there. And configure the Minimum Transfer amount.
#### 3. Generate Addresses Click Create. You will be prompted to sign a transaction to pay the one-time generation gas fee. Once confirmed, your unique Deposit Address will appear. #### 4. Start Receiving
Copy the address and use it to receive funds. You can monitor auto-transfers by opening Deposit Addresses in Allbridge Explorer. # Get started Allbridge Core SDK enables you to onboard cross-chain functionality into your protocol. Follow these instructions to get started using our SDK. ### Installation instructions Using npm: ```bash $ npm install @allbridge/bridge-core-sdk ``` Using yarn: ```bash $ yarn add @allbridge/bridge-core-sdk ``` Using pnpm: ```bash $ pnpm add @allbridge/bridge-core-sdk ``` **Initialize the SDK instance with your node RPC URLs** ```ts import { AllbridgeCoreSdk, nodeRpcUrlsDefault } from "@allbridge/bridge-core-sdk"; // Connections to blockchains will be made through your rpc-urls passed during initialization const sdk = new AllbridgeCoreSdk({ ...nodeRpcUrlsDefault, TRX: "your trx-rpc-url", ETH: "your eth-rpc-url" }); ``` Visit our [GitHub repository](https://github.com/allbridge-public/allbridge-core-js-sdk). # Guides Below you will find some helpful tips that will simplify the integration process. You can find general information about creating transfers with Allbridge Core in [General](/sdk/guides/general) page. For details about each particular blockchain go to the sections on: * [EVM](/sdk/guides/evm) * [Solana](/sdk/guides/solana) * [Stellar](/sdk/guides/stellar) * [Sui](/sdk/guides/sui) * [Algorand](/sdk/guides/algorand) And finally, some helpful additional resources on how to query fees, transfer time and other topics can be found in [Utilities](/sdk/guides/utilities) section. # General [Token info](/sdk/guides/general/token-info) - how to get info about all tokens [Send](/sdk/guides/general/send) - how to send a common transaction [Swap](/sdk/guides/general/swap) - how to create a swap transaction [Fee with stables](/sdk/guides/general/paying-fees-with-stables) - how to pay fees with stables # Token info To get token info you just have to call a [chainDetailsMap](https://bridge-core-sdk.web.app/classes/AllbridgeCoreSdk.html#chainDetailsMap) method. It returns a map with keys as a chain symbol, and values as [ChainDetailsWithTokens](https://bridge-core-sdk.web.app/interfaces/ChainDetailsWithTokens.html). It has a field named "tokens" that is a map of [TokenWithChainDetails](https://bridge-core-sdk.web.app/interfaces/TokenWithChainDetails.html). You should use this object to identify a token. ```typescript import { AllbridgeCoreSdk, nodeRpcUrlsDefault } from "@allbridge/bridge-core-sdk"; const sdk = new AllbridgeCoreSdk(nodeRpcUrlsDefault); const chains = await sdk.chainDetailsMap(); console.log("Chain details map =", JSON.stringify(chains, null, 2)); const tokens = await sdk.tokens(); console.log("Tokens =", JSON.stringify(tokens, null, 2)); // selecting tokens const sourceChain = chains[ChainSymbol.SOL]; const sourceTokenInfo = sourceChain.tokens.find((tokenInfo) => tokenInfo.symbol === "USDC"); const destinationChain = chains[ChainSymbol.POL]; const destinationTokenInfo = destinationChain.tokens.find((tokenInfo) => tokenInfo.symbol === "USDC"); ``` # Send The most common and important action in SDK is sending a transfer. To make it first of all you have to build a transaction. For that, you need to call the [send](https://bridge-core-sdk.web.app/interfaces/BridgeService.html#send)[ ](https://bridge-core-sdk.web.app/interfaces/RawBridgeTransactionBuilder.html#send)method. It has the following fields: amount: (string) - total amount to send in float format. If you pay a fee with stables also includes fee and extra gas amount. destinationToken: token you want to send has got from [token info](/sdk/guides/general/token-info) sourceToken: token you want to receive have got from [token info](/sdk/guides/general/token-info) extraGas: (string, optional) If you want to receive extra gas tokens on a destination chain, you have to add this field. Limits for extra gas you can get [here](/sdk/guides/utilities/extra-gas-limits) extraGasFormat: ([AmountFormat](https://bridge-core-sdk.web.app/enums/AmountFormat.html) enum INT or FLOAT. Default: INT) Define the format of the extraGas field fee: (string, optional) to set manually amount of the fee to pay for the transfer. If it is not specified, the fee is set according to [getGasFeeOptions](https://bridge-core-sdk.web.app/classes/AllbridgeCoreSdk.html#getGasFeeOptions) method. Value currency depends on gasFeePaymentMethod field - NATIVE\_CURRENCY or STABLECOIN respectively feeFormat: ([AmountFormat](https://bridge-core-sdk.web.app/enums/AmountFormat.html) enum INT or FLOAT. Default: INT) Define the format of the fee field fromAccountAddress: (string) sender address toAccountAddress: (string) recipient address gasFeePaymentMethod: ([enum](https://bridge-core-sdk.web.app/enums/FeePaymentMethod.html), optional, default: WITH\_NATIVE\_CURRENCY) WITH\_NATIVE\_CURRENCY - gas fee and extra gas will be added to the transaction as native token value \ WITH\_STABLECOIN - gas fee and extra gas will be deducted from the amount field messenger: ([enum](https://bridge-core-sdk.web.app/enums/Messenger.html)) Could be ALLBRIDGE, WORMHOLE, CCTP. Not all chains and tokens support all messengers. To check it you can call [getAverageTransferTime](/sdk/guides/utilities/transfer-time) method, and if the messenger is not supported it returns null txFeeParams: ([object](https://bridge-core-sdk.web.app/interfaces/TxFeeParams.html), optional) additional fee for sending transaction blockchain. Now used only for Solana to add extra fee instructions in the transaction. For more details see [docs](https://bridge-core-sdk.web.app/interfaces/TxFeeParams.html) ```typescript const rawTx = await sdk.bridge.rawTxBuilder.send(sendParams); ``` The method will return a [raw transaction](https://bridge-core-sdk.web.app/types/RawTransaction.html) accounting to the source chain. You need only to sign and send it. If you want to build a swap transaction you have to use this method also, but with the tokens on the same chain and more simpler [args](https://bridge-core-sdk.web.app/interfaces/SwapParams.html) # Swap If you want to swap tokens on the same chain ```typescript // initiate transfer const swapParams: SwapParams = { amount: amount, fromAccountAddress: fromAddress, toAccountAddress: toAddress, sourceToken: sourceTokenInfo, destinationToken: destinationTokenInfo, minimumReceiveAmount: await sdk.getAmountToBeReceived(amount, sourceTokenInfo, destinationTokenInfo), }; const rawTransactionTransfer = await sdk.bridge.rawTxBuilder.send(swapParams) as RawEvmTransaction; console.log(`Swaping ${amount} ${sourceTokenInfo.symbol}`); const txReceipt = await sendRawTransaction(rawTransactionTransfer); console.log("tx id:", txReceipt.transactionHash); ``` [Full example](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/evm/evm-build-swap-tx.ts) # Paying fees with stables By default you the transaction charges fee in network's gas tokens, but you may opt into paying fees with stables instead: For this you have to use [getGasFeeOptions](https://bridge-core-sdk.web.app/classes/AllbridgeCoreSdk.html#getGasFeeOptions) metod ```typescript const gasFeeOptions = await sdk.getGasFeeOptions(sourceTokenInfo, destinationTokenInfo, Messenger.ALLBRIDGE); const gasFeeAmount = gasFeeOptions[FeePaymentMethod.WITH_STABLECOIN]; // initiate transfer const rawTransactionTransfer = await sdk.bridge.rawTxBuilder.send( { amount: totalAmountFloat, fromAccountAddress: fromAddress, toAccountAddress: toAddress, sourceToken: sourceTokenInfo, destinationToken: destinationTokenInfo, messenger: Messenger.ALLBRIDGE, gasFeePaymentMethod: FeePaymentMethod.WITH_STABLECOIN, fee: gasFeeAmount.int, } ); ``` [Full example](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/evm/evm-build-send-tx-gas-fee-with-stables.ts) # EVM [Transfer](/sdk/guides/evm/transfer) - how to create and send transaction from EVM [Allowance and approve](/sdk/guides/evm/allowance-and-approve) - how to check and update allowance # Transfer #### Approve the token transfer Before sending tokens, the bridge has to be authorized to use the tokens of the owner. This is done by calling the `approve` method on the SDK instance. *For Ethereum USDT (due to the specifics of the USDT contract):*\ If the current allowance is not 0, this function will perform an additional transaction to set the allowance to 0 before setting the new allowance value. ```ts const rawTransactionApprove = await sdk.bridge.rawTxBuilder.approve({ token: sourceToken, owner: accountAddress, }); const approveTxReceipt = await sendRawTransaction(rawTransactionApprove as RawEvmTransaction); console.log("approve tx id:", approveTxReceipt.transactionHash); ``` #### Send Tokens Initiate the raw transaction of token transfer with the SDK instance: ```ts const rawTransaction = sdk.bridge.rawTxBuilder.send({ amount: "1.01", fromAccountAddress: fromAddress, toAccountAddress: toAddress, sourceToken: sourceToken, destinationToken: destinationToken, messenger: Messenger.ALLBRIDGE, }); const txReceipt = await sendRawTransaction(rawTransactionApprove as RawEvmTransaction); console.log("tx id:", txReceipt.transactionHash); ``` #### [Full example](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/evm/evm-build-send-tx.ts) # Allowance and approve This is an example demonstrating how to use the Allbridge Core SDK to check the allowance and create an approval. ```typescript if ( // check if tokens already approved await sdk.bridge.checkAllowance({ token: sourceTokenInfo, owner: fromAddress, gasFeePaymentMethod: gasFeePaymentMethod, amount: totalAmountFloat, }) ) { console.log("The granted allowance is enough for the transaction"); } else { console.log("The granted allowance is NOT enough for the transaction"); } ``` To make approve transaction ```typescript // authorize the bridge to transfer tokens from the sender's address const rawTransactionApprove = await sdk.bridge.rawTxBuilder.approve({ token: sourceTokenInfo, owner: fromAddress, }); const approveTxReceipt = await sendRawTransaction(rawTransactionApprove as as RawEvmTransaction); console.log("approve tx id:", approveTxReceipt.transactionHash); ``` [Full example](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/evm/evm-build-send-tx.ts) # Sui [Transfer](/sdk/guides/sui/transfer) - how to create and send a transaction from Sui # Transfer Initiate the raw transaction of token transfer with the SDK instance: ```ts const xdr = (await sdk.bridge.rawTxBuilder.send({ amount: amount, fromAccountAddress: accountAddress, toAccountAddress: toAddress, sourceToken: sourceToken, destinationToken: destinationToken, messenger: Messenger.ALLBRIDGE, // gasFeePaymentMethod: FeePaymentMethod.WITH_STABLECOIN, })) as RawSuiTransaction; const txReceipt = await sendSuiRawTransaction(xdr); console.log("tx id:", txReceipt); ``` #### [Full example ](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/sui/sui-build-send-tx.ts) # Solana [Transfer](/sdk/guides/solana/transfer) - how to create and send transaction from Solana [Swap](/sdk/guides/solana/swap) - how to make a swap on Solana # Transfer Initiate raw transaction for the token transfer with this SDK instance: ```typescript // initiate transfer using Messenger.WORMHOLE const transaction = (await sdk.bridge.rawTxBuilder.send({ amount: "0.2", fromAccountAddress: fromAddress, toAccountAddress: toAddressPol, sourceToken: sourceTokenInfo, destinationToken: destinationTokenInfoPol, messenger: Messenger.WORMHOLE, txFeeParams: { solana: SolanaAutoTxFee, }, })) as RawBridgeSolanaTransaction; const keypair = solanaWeb3.Keypair.fromSecretKey(bs58.decode(privateKey)); transaction.sign([keypair]); const connection = new solanaWeb3.Connection(nodeUrlsDefault.solanaRpcUrl, "confirmed"); const txId = await connection.sendTransaction(transaction); console.log(`https://explorer.solana.com/tx/${txId}`); ``` [Allbrdige and Wormhole messaging full example](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/solana/sol-build-send-tx.ts) # Swap Swap makes the same way as a transfer, but you have to specify tokens from the one chain ```typescript // initiate transfer using Messenger.WORMHOLE const amount = "10"; const transaction = (await sdk.bridge.rawTxBuilder.send({ amount: amount, fromAccountAddress: accountAddress, toAccountAddress: accountAddress, sourceToken: sourceTokenInfo, destinationToken: destinationTokenInfo, minimumReceiveAmount: await sdk.getAmountToBeReceived(amount, sourceTokenInfo, destinationTokenInfo), })) as RawSolanaTransaction; const keypair = solanaWeb3.Keypair.fromSecretKey(bs58.decode(privateKey)); transaction.sign([keypair]); const connection = new solanaWeb3.Connection(nodeUrlsDefault.solanaRpcUrl, "confirmed"); const txId = await connection.sendTransaction(transaction); console.log(`https://explorer.solana.com/tx/${txId}`); ``` [Full example](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/solana/sol-build-swap-tx.ts) # Tron Tron has a similar workflow as EVM [Example - Approve and send transactions](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/trx/trx-build-send-tx.ts) [Example - Approve and send transactions paid with stables for gas](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/trx/trx-build-send-tx-gas-fee-with-stables.ts) [Example - Swap](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/trx/trx-build-swap-tx.ts) # Stellar [Transfer](/sdk/guides/stellar/transfer) - how to create and send transaction from Stellar # Transfer Tokens and parameters are compiled in the same way as for other chains: ```typescript const sdk = new AllbridgeCoreSdk(nodeRpcUrlsDefault); const chainDetailsMap = await sdk.chainDetailsMap(); const sourceToken = chainDetailsMap[ChainSymbol.SRB].tokens.find((t) => t.symbol == "USDT"); const destinationToken = chainDetailsMap[ChainSymbol.ETH].tokens.find((t) => t.symbol == "USDT"); const amount = "2"; const sendParams: SendParams = { amount, fromAccountAddress: fromAddress, toAccountAddress: toAddress, sourceToken, destinationToken, messenger: Messenger.ALLBRIDGE, extraGas: "1.15", extraGasFormat: AmountFormat.FLOAT, gasFeePaymentMethod: FeePaymentMethod.WITH_STABLECOIN, }; const xdrTx: string = (await sdk.bridge.rawTxBuilder.send(sendParams)) as string; ``` Simulate the transaction before sending it. If some data is archived on Stellar, you have to restore it before sending the transaction. The simulation method can return a restore transaction, in this case, you have to send it first: ```typescript // SendTx const srbKeypair = Keypair.fromSecret(privateKey); const transaction = TransactionBuilder.fromXDR(xdrTx, mainnet.sorobanNetworkPassphrase); transaction.sign(srbKeypair); const signedTx = transaction.toXDR(); const restoreXdrTx = await sdk.utils.srb.simulateAndCheckRestoreTxRequiredSoroban(signedTx, fromAddress); if (restoreXdrTx) { restoreXdrTx.sign(srbKeypair); const signedRestoreXdrTx = restoreXdrTx.toXDR(); const sentRestoreXdrTx = await sdk.utils.srb.sendTransactionSoroban(signedRestoreXdrTx); const confirmRestoreXdrTx = await sdk.utils.srb.confirmTx(sentRestoreXdrTx.hash); if (confirmRestoreXdrTx.status === SorobanRpc.Api.GetTransactionStatus.NOT_FOUND) { console.log( `Waited for Restore transaction to complete, but it did not. ` + `Check the transaction status manually. ` + `Hash: ${sentRestoreXdrTx.hash}` ); } else if (confirmRestoreXdrTx.status === SorobanRpc.Api.GetTransactionStatus.FAILED) { console.log(`Transaction Restore failed. Check the transaction manually.` + `Hash: ${sentRestoreXdrTx.hash}`); } else { console.log(`Transaction Restore Confirmed. Hash: ${sentRestoreXdrTx.hash}`); } //generate new tx with updated sequences const xdrTx2 = (await sdk.bridge.rawTxBuilder.send(sendParams)) as string; const transaction2 = TransactionBuilder.fromXDR(xdrTx2, mainnet.sorobanNetworkPassphrase); transaction2.sign(srbKeypair); signedTx = transaction2.toXDR(); } ``` Then you have to send the main transaction. Please note that if you send a restore transaction before, the transaction sequence will be changed, and you have to recompile it: ```typescript const sent = await sdk.utils.srb.sendTransactionSoroban(signedTx); const confirm = await sdk.utils.srb.confirmTx(sent.hash); if (confirm.status === SorobanRpc.Api.GetTransactionStatus.NOT_FOUND) { console.log( `Waited for transaction to complete, but it did not. ` + `Check the transaction status manually. ` + `Hash: ${sent.hash}` ); } else if (confirm.status === SorobanRpc.Api.GetTransactionStatus.FAILED) { console.log(`Transaction failed. Check the transaction manually.` + `Hash: ${sent.hash}`); } else { console.log(`Transaction Confirmed. Hash: ${sent.hash}`); } ``` Finally, if you make a transfer to Stellar, you have to ensure that you have trustlines for the destination token. Use the example below to check for the trustline/create it: ```typescript //TrustLine check and Set up for destinationToken if it is SRB const destinationTokenSBR = sourceToken; // simulate destination is srb const balanceLine = await sdk.utils.srb.getBalanceLine(fromAddress, destinationTokenSBR.tokenAddress); console.log(`BalanceLine:`, balanceLine); const notEnoughBalanceLine = !balanceLine || Big(balanceLine.balance).add(amount).gt(Big(balanceLine.limit)); if (notEnoughBalanceLine) { const xdrTx = await sdk.utils.srb.buildChangeTrustLineXdrTx({ sender: fromAddress, tokenAddress: destinationTokenSBR.tokenAddress, // limit: "1000000", }); //SignTx const keypair = StellarKeypair.fromSecret(privateKey); const transaction = StellarTransactionBuilder.fromXDR(xdrTx, mainnet.sorobanNetworkPassphrase); transaction.sign(keypair); const signedTrustLineTx = transaction.toXDR(); const submit = await sdk.utils.srb.submitTransactionStellar(signedTrustLineTx); console.log("Submitted change trust tx. Hash:", submit.hash); } ``` [Full example](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/srb/srb-send-full-example.ts) # Algorand Initiating transfers to Algorand is the same as for the other chains, you have to use chain symbol `ChainSymbol.ALG` as a destination chain. Make sure that the recipient wallet address opted in to receive the token (read more [here](https://dev.algorand.co/concepts/assets/asset-operations/#optin)). To send transfers from Algorand you have to initialize Allbridge Core SDK with Algorand node URL. ```typescript const sdk = new AllbridgeCoreSdk({ ...nodeRpcUrlsDefault, ALG: getEnvVar("ALG_PROVIDER_URL") }); ``` After the SDK is initialized you can create a token send transaction. ```typescript const rawTransactionTransfer = (await sdk.bridge.rawTxBuilder.send({ amount: amount, fromAccountAddress: fromAddress, toAccountAddress: toAddress, sourceToken: sourceToken, destinationToken: destinationToken, messenger: Messenger.ALLBRIDGE, // gasFeePaymentMethod: FeePaymentMethod.WITH_STABLECOIN })) as RawAlgTransaction; const txId = await sendAlgRawTransaction(rawTransactionTransfer); ``` You can construct transaction to pay the relayer fee either from the body of the transfer itself or with ALGO token (by specifying `gasFeePaymentMethod` parameter. In the example above the signing and sending of transaction is within the `sendAlgRawTransaction` function. You can check out the full code in our examples: * Sending transfers from Algorand: * Algorand utils: # Utilities [Amount and fee calculations](/sdk/guides/utilities/amount-and-fee-calculations) - how to calculate send/receive amount and fee [Transfer time](/sdk/guides/utilities/transfer-time) - how to calculate approximate transfer time [Extra gas limits](/sdk/guides/utilities/extra-gas-limits) - how to calculate limits for extra gas # Amount and fee calculations To calculate and get info about the receive amount, one has to call [getAmountToBeReceived](https://bridge-core-sdk.web.app/classes/AllbridgeCoreSdk.html#getAmountToBeReceived) method. ```typescript const amountToBeReceived = await sdk.getAmountToBeReceived(amount, sourceToken, destinationToken); console.log( "Send %d %s and %d %s (gas fee) on %s to receive %d %s on %s", amount, sourceToken.symbol, gasFeeOptions.native.int, sourceChainMinUnit, sourceToken.chainSymbol, amountToBeReceived, destinationToken.symbol, destinationToken.chainSymbol ); ``` If you selected pay with stables: ```typescript const gasFeeOptions = await sdk.getGasFeeOptions(sourceToken, destinationToken, Messenger.ALLBRIDGE); const floatGasFeeAmount = gasFeeOptions.stablecoin.float; console.log( "Send %d %s and %d %s (gas fee) on %s to receive %d %s on %s", amount, sourceToken.symbol, floatGasFeeAmount, sourceToken.symbol, sourceToken.chainSymbol, amountToBeReceived, destinationToken.symbol, destinationToken.chainSymbol ); ``` If you want to calculate how much you need to send to receive a specific amount use a [getAmountToSend](https://bridge-core-sdk.web.app/classes/AllbridgeCoreSdk.html#getAmountToSend) method: ```typescript const amountToSend = await sdk.getAmountToSend(amount, sourceToken, destinationToken); console.log( "Send %d %s and %d %s (gas fee) on %s to receive %d %s on %s", amountToSend, sourceToken.symbol, gasFeeOptions.native.int, sourceChainMinUnit, sourceToken.chainSymbol, amount, destinationToken.symbol, destinationToken.chainSymbol ); ``` If you want to receive additional data about fees, select [getAmountToBeReceivedAndGasFeeOptions](https://bridge-core-sdk.web.app/classes/AllbridgeCoreSdk.html#getAmountToBeReceivedAndGasFeeOptions) or [getAmountToSendAndGasFeeOptions](https://bridge-core-sdk.web.app/classes/AllbridgeCoreSdk.html#getAmountToSendAndGasFeeOptions) method instead: ```typescript const { amountToSendFloat, amountToBeReceivedFloat, gasFeeOptions } = await sdk.getAmountToBeReceivedAndGasFeeOptions( amount, sourceToken, destinationToken, Messenger.ALLBRIDGE ); console.log( "Send %d %s and %d %s (gas fee) on %s to receive %d %s on %s", amountToSendFloat, sourceToken.symbol, gasFeeOptions.native.int, sourceChainMinUnit, sourceToken.chainSymbol, amountToBeReceivedFloat, destinationToken.symbol, destinationToken.chainSymbol ); ``` [Full example](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/calculate-amounts.ts) # Transfer time You can calculate the approximate transfer time using [getAverageTransferTime](https://bridge-core-sdk.web.app/classes/AllbridgeCoreSdk.html#getAverageTransferTime) method ```typescript const transferTimeMs = sdk.getAverageTransferTime(sourceToken, destinationToken, Messenger.ALLBRIDGE); console.log( "Average transfer time from %s to %s is %s", sourceToken.chainSymbol, destinationToken.chainSymbol, msToTime(transferTimeMs) ); ``` [Full example](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/get-average-transfer-time.ts) # Extra gas limits Allbridge has limits for extra gas amount. To check the max value of extra gas you have to use the [getExtraGasMaxLimits](https://bridge-core-sdk.web.app/classes/AllbridgeCoreSdk.html#getExtraGasMaxLimits) method ```typescript const extraGasMax = await sdk.getExtraGasMaxLimits(sourceToken, destToken); console.log("extraGas Limits =", JSON.stringify(extraGasMax, null, 2)); ``` [Full example](https://github.com/allbridge-io/allbridge-core-js-sdk/blob/main/examples/src/examples/bridge/get-extra-gas-max-limits.ts) # Referral program ## Referral program Allbridge Core offers a referral program to the integration partners. Find out more by reaching out to . # Allbridge Core REST API Provides an easy integration with the Allbridge Core ChainBridgeService for DApps vie REST API. For detailed information and usage instructions, visit the [GitHub repository](https://github.com/allbridge-io/allbridge-core-rest-api) ### Table of Contents * [Configuration](#configuration) * [Networks](#networks) * [Environment variables](#environment-variables) * [How to get](#how-to-get) * [1. Use existing docker image](#id-1.-use-existing-docker-image) * [2. Build and run the docker image](#id-2.-build-and-run-the-docker-image) * [How to use](#how-to-use) * [Swagger](#swagger) * [Raw transactions](#raw-transactions) * [Tokens](#tokens) * [Pools](#pools) * [Transfers](#transfers) ### Configuration #### Networks The Allbridge Core REST API supports the following networks: * Ethereum (ETH) * Binance Smart Chain (BSC) * Tron (TRX) * Arbitrum (ARB) * Polygon (POL) * Avalanche (AVA) * Optimism (OPT) * Base (BAS) * Celo (CEL) * Solana (SOL) * Sonic (SNC) * Sui (SUI) * Stellar (STLR) & Soroban (SRB) #### Environment variables The Allbridge Core REST API requires the following environment variables: * `ENVIRONMENT` - The environment in which the API is running. Possible values are `development` and `production`. * `ETH_NODE_URL` - The JSON RPC URL of the Ethereum node. For example: * `https://ethereum-rpc.publicnode.com` * `https://mainnet.infura.io/v3/YOUR-PROJECT-ID` * ... * `BSC_NODE_URL` - The JSON RPC URL of the Binance Smart Chain node. For example: * `https://bsc-rpc.publicnode.com` * `https://bsc-dataseed1.binance.org` * ... * `TRX_NODE_URL` - The JSON RPC URL of the Tron node. For example: * `https://tron-rpc.publicnode.com` * `https://api.trongrid.io` * ... * `ARB_NODE_URL` - The JSON RPC URL of the Arbitrum node. For example: * `https://arbitrum-one-rpc.publicnode.com` * `https://arb1.arbitrum.io/rpc` * `https://arbitrum-mainnet.infura.io/v3/YOUR-PROJECT-ID` * ... * `POL_NODE_URL` - The JSON RPC URL of the Polygon node. For example: * `https://polygon-bor-rpc.publicnode.com` * `https://polygon-rpc.com` * ... * `AVA_NODE_URL` - The JSON RPC URL of the Avalanche node. For example: * `https://avalanche-c-chain-rpc.publicnode.com` * `https://api.avax.network/ext/bc/C/rpc` * `https://avalanche-mainnet.infura.io/v3/YOUR-PROJECT-ID` * ... * `OPT_NODE_URL` - The JSON RPC URL of the Optimism node. For example: * `https://optimism-rpc.publicnode.com` * `https://mainnet.optimism.io` * `https://optimism-mainnet.infura.io/v3/YOUR-PROJECT-ID` * ... * `BAS_NODE_URL` - The JSON RPC URL of the Base node. For example: * `https://base-rpc.publicnode.com` * `https://mainnet.base.org` * `https://base-mainnet.infura.io/v3/YOUR-PROJECT-ID` * ... * `CEL_NODE_URL` - The JSON RPC URL of the Celo node. For example: * `https://rpc.ankr.com/celo` * `https://forno.celo.org` * `https://celo-mainnet.infura.io/v3/YOUR-PROJECT-ID` * ... * `SOL_NODE_URL` - The JSON RPC URL of the Solana node. For example: * `https://api.mainnet-beta.solana.com` * `https://solana-api.projectserum.com` * `https://rpc.ankr.com/solana` * ... * `SNC_NODE_URL` - The JSON RPC URL of the Sonic node. For example: * `https://rpc.soniclabs.com` * `https://sonic.drpc.org` * ... * `SUI_NODE_URL` - The JSON RPC URL of the Sui node. For example: * `https://sui-rpc.publicnode.com` * `https://sui-mainnet-endpoint.blockvision.org/` * ... * `SRB_NODE_URL` - The JSON RPC URL of the Soroban node. For example: * `https://www.quicknode.com/stellar` (Soroban JSON RPC by QuickNode) * `https://www.blockdaemon.com/soroban` (Blockdaemon) * ... * `STLR_NODE_URL` - The JSON RPC URL of the Stellar node. For example: * `https://horizon.stellar.org` * `https://stellar-mainnet.rpcpool.com` * ... * `NETWORKS` - A list of supported networks. Possible values are `ETH`, `BSC`, `TRX`, `ARB`, `POL`, `AVA`, `OPT`, `BAS`, `CEL`, `SOL`, `SUI`, `SNC`, `SRB`, `STLR`. For Stellar network, you need to provide both `STLR` and `SRB` networks. * `HEADERS` - Headers for the API requests. For example: * `{"Authorization": "Bearer YOUR-TOKEN"}` * `TRON_JSON_RPC` - The JSON RPC URL of the Tron node. For example: * `https://api.trongrid.io/jsonrpc` * `JUPITER_URL` - The URL of the Jupiter API. For example: * `https://quote-api.jup.ag/v6` ### How to get #### 1. Use existing docker image The easiest way to use the Allbridge Core REST API is to use the existing docker image. You can pull the image from the Docker Hub and run it with the following command: ```bash docker run -p 3000:3000 \ -e ENVIRONMENT="production" \ -e ETH_NODE_URL="https://ethereum-rpc.publicnode.com" \ -e BSC_NODE_URL="https://bsc-rpc.publicnode.com" \ -e TRX_NODE_URL="https://tron-rpc.publicnode.com" \ -e ARB_NODE_URL="https://arbitrum-one-rpc.publicnode.com" \ -e POL_NODE_URL="https://polygon-bor-rpc.publicnode.com" \ -e AVA_NODE_URL="https://avalanche-c-chain-rpc.publicnode.com" \ -e OPT_NODE_URL="https://optimism-rpc.publicnode.com" \ -e BAS_NODE_URL="https://base-rpc.publicnode.com" \ -e CEL_NODE_URL="https://rpc.ankr.com/celo" \ -e SNC_NODE_URL="https://rpc.soniclabs.com" \ -e SUI_NODE_URL="https://sui-rpc.publicnode.com" \ -e SOL_NODE_URL="https://api.mainnet-beta.solana.com" \ -e SRB_NODE_URL="...soroban rpc node..." \ -e STLR_NODE_URL="https://horizon.stellar.org" \ -e NETWORKS="[\"ETH\",\"BSC\",\"TRX\",\"ARB\",\"POL\",\"AVA\",\"OPT\",\"BAS\",\"CEL\",\"SNC\",\"SUI\",\"SOL\",\"SRB\",\"STLR\"]" \ -d allbridge/io.allbridge.rest-api:latest ``` or use environment variables from the `.env` file: ```bash docker run -p 3000:3000 --env-file .env -d allbridge/io.allbridge.rest-api:latest ``` #### 2. Build and run the docker image ```bash docker build -t allbridge-core-rest-api . docker run -p 3000:3000 \ -e ENVIRONMENT="production" \ -e ETH_NODE_URL="https://ethereum-rpc.publicnode.com" \ -e BSC_NODE_URL="https://bsc-rpc.publicnode.com" \ -e TRX_NODE_URL="https://tron-rpc.publicnode.com" \ -e ARB_NODE_URL="https://arbitrum-one-rpc.publicnode.com" \ -e POL_NODE_URL="https://polygon-bor-rpc.publicnode.com" \ -e AVA_NODE_URL="https://avalanche-c-chain-rpc.publicnode.com" \ -e OPT_NODE_URL="https://optimism-rpc.publicnode.com" \ -e BAS_NODE_URL="https://base-rpc.publicnode.com" \ -e CEL_NODE_URL="https://rpc.ankr.com/celo" \ -e SNC_NODE_URL="https://rpc.soniclabs.com" \ -e SUI_NODE_URL="https://sui-rpc.publicnode.com" \ -e SOL_NODE_URL="https://api.mainnet-beta.solana.com" \ -e SRB_NODE_URL="...soroban rpc node..." \ -e STLR_NODE_URL="https://horizon.stellar.org" \ -e NETWORKS="[\"ETH\",\"BSC\",\"TRX\",\"ARB\",\"POL\",\"AVA\",\"OPT\",\"BAS\",\"CEL\",\"SNC\",\"SUI\",\"SOL\",\"SRB\",\"STLR\"]" \ -d allbridge-core-rest-api ``` ### How to use #### Swagger After running the docker image, you can access the swagger documentation at `http://localhost:3000/api`. The swagger documentation provides a detailed description of the available endpoints and their parameters. #### Raw transactions `GET /raw/approve` - Creates a Raw Transaction for approving tokens usage by the bridge `GET /raw/swap` - Creates a Raw Transaction for initiating the swap of tokens on one chain `GET /raw/bridge` - Creates a Raw Transaction for initiating the transfer of tokens from one chain to another. `GET /raw/deposit` - Creates a Raw Transaction for depositing tokens to Liquidity pool `GET /raw/withdraw` - Creates a Raw Transaction for withdrawing tokens from Liquidity pool `GET /raw/claim` - Creates a Raw Transaction for claiming rewards from Liquidity pool #### Tokens `GET /tokens` - Returns a list of supported tokens. `GET /chains` - Returns ChainDetailsMap containing a list of supported tokens groped by chain. `GET /token/balance` - Get token balance `GET /token/native/balance` - Get native (gas) token balance `GET /token/details` - Get token details `GET /gas/fee` - Fetches possible ways to pay the transfer gas fee. `GET /gas/balance` - Get gas balance `GET /gas/extra/limits` - Get possible limit of extra gas amount. #### Pools `GET /check/allowance` - Check if the amount of approved tokens is enough `GET /pool/info/server` - Gets information about the pool-info by token from server `GET /pool/info/blockchain` - Gets information about the pool-info by token from blockchain `GET /pool/allowance` - Get amount of tokens approved for poolInfo `GET /liquidity/details` - Get user balance info on liquidity pool `GET /liquidity/deposit/calculate` - Calculates the amount of LP tokens that will be deposited `GET /liquidity/withdrawn/calculate` - Calculates the amount of tokens will be withdrawn #### Transfers `GET /transfer/time` - Gets the average time in ms to complete a transfer for given tokens and messenger. `GET /transfer/status` - Fetches information about tokens transfer by chosen chainSymbol and transaction Id from the Allbridge Core API. `GET /pending/info` - Returns information about pending transactions for the same destination chain and the amount of tokens can be received as a result of transfer considering pending transactions. `GET /swap/details` - Show swap amount changes (fee and amount adjustment) during send through pools `GET /bridge/details` - Show bridge amount changes (fee and amount adjustment) during send through pools on source and destination chains `GET /bridge/receive/calculate` - Calculates the amount of tokens to be received as a result of transfer. `GET /bridge/send/calculate` - Calculates the amount of tokens to send based on requested tokens amount be received as a result of transfer. # Overview Allbridge uses two MCP products for AI-assisted bridge flows. ### Allbridge MCP Allbridge MCP is the coordination layer. It helps you: * plan the route * check balances * build the execution step * find the right docs or example * broadcast a payload that is already signed * track the transfer after submission ### Local Signer MCP Local Signer MCP is the local signing layer. It helps you: * sign the payload on the user's machine * keep private keys out of the network path * finish a flow that another system already prepared ### How they fit together In a normal flow: 1. Ask Allbridge MCP to plan the transfer. 2. Review the route, fee, and next step. 3. Send the unsigned payload to Local Signer MCP if signing is needed. 4. Broadcast the signed payload and track the transfer. ### What this gives you * Bridge planning can happen remotely. * Private keys stay local. * Docs lookup does not require wallet access. ### When to use which product * Use **Allbridge MCP** when you need to: * discover supported chains and tokens * plan a bridge route * check balances before execution * build the next execution step * look up docs, examples, and integration references * broadcast a payload that is already signed * Use **Local Signer MCP** when you need to: * sign a transaction locally * keep private keys off the network * connect a desktop MCP client to a local wallet * finish a flow prepared by another system ### Product links * Allbridge MCP repository: [allbridge-io/allbridge-mcp](https://github.com/allbridge-io/allbridge-mcp) * Allbridge MCP Docker image: [allbridge/io.allbridge.mcp](https://hub.docker.com/repository/docker/allbridge/io.allbridge.mcp/tags?name=latest) * Local Signer repository: [allbridge-io/local-signer-mcp](https://github.com/allbridge-io/local-signer-mcp) * Local Signer Docker image: [allbridge/local-signer-mcp](https://hub.docker.com/repository/docker/allbridge/local-signer-mcp/tags?name=latest) ### Product boundary * **Allbridge MCP** handles route planning, documentation, and bridge coordination. * **Local Signer MCP** handles local signing and local wallet execution. * Private keys stay with **Local Signer MCP**. * Orchestration and docs stay with **Allbridge MCP**. Start with the product page that matches the task you want to solve. # Allbridge MCP Allbridge MCP coordinates bridge flows and integration lookups. * Repository: [allbridge-io/allbridge-mcp](https://github.com/allbridge-io/allbridge-mcp) * Docker image: [allbridge/io.allbridge.mcp](https://hub.docker.com/repository/docker/allbridge/io.allbridge.mcp/tags?name=latest) ### What it is Use Allbridge MCP when you want an AI client to help with a bridge task without touching private keys. It can: * discover supported chains and tokens * plan a bridge route * check whether the sender can cover the transfer and fee * prepare destination prerequisites such as Stellar trustlines and Algorand opt-ins * build an execution job with the next step * broadcast a payload that is already signed * track the transfer after submission * search public explorer records by transfer hash or address * find the right docs, examples, and integration references ### What it is not Allbridge MCP does not: * hold private keys * sign transactions * pick a local wallet for the user Those responsibilities stay with Local Signer MCP. ### When to use it Use Allbridge MCP when you need help deciding: * which route to take * which token or chain pair is supported * whether balance is sufficient for the move * what step comes next in the flow * where the correct integration guide or example lives # Bridge Workflow This page shows the bridge flow from the user's point of view. ### Start with a plain request The user can describe the transfer in ordinary language: * “Bridge USDC from Solana to BSC” * “Move stablecoins from Ethereum to Tron” * “Send 5 USDC to this address” If the chain or token is not known yet, start with the catalog tools: * `list_supported_chains` * `list_supported_tokens` If you already know the pair and only need pricing or route comparison, use `find_bridge_routes` or `quote_bridge_transfer`. ### Plan the route Call `plan_bridge_transfer` with the source chain, destination chain, source token, amount, and any optional destination token. The response tells you: * which route is available * which messenger is recommended * which fee option is available * what the user is expected to receive * what the next step should be ### Check balances before execution Before you build the execution job, call `check_bridge_balances`. This verifies that the sender can cover: * the bridged amount * the selected fee If the check fails, stop and ask the user to top up. ### Build the execution job Once the route and balances are confirmed, call `create_bridge_execution_job`. The job gives you: * an ordered list of steps * raw transaction payloads * handoff metadata * wallet hints * transfer tracking details If the intended local wallet is already known, pass `walletId`. ### Prepare destination prerequisites Some destination chains require setup before a user can receive the bridged asset. Use these tools when the destination side needs an explicit prerequisite: * `check_stellar_trustline` * `build_stellar_trustline_transaction` * `check_algorand_optin` * `build_algorand_optin_transaction` The setup transaction is still unsigned. If it needs a local signature, hand it to Local Signer MCP the same way as a bridge execution step. ### Sign or broadcast There are two valid ways to finish the job: * hand the unsigned step to **Local Signer MCP** * broadcast a payload that is already signed with **Allbridge MCP** Choose the path that matches the step you received. ### Track the transfer After the source-chain transaction is sent, call `get_transfer_status`. That lets the client follow the transfer until the receive side is confirmed. ### In one sentence Allbridge MCP plans the route, checks the balance, builds the job, and tracks the transfer; Local Signer MCP handles the local signing step when needed. # Developer Assistant Allbridge MCP includes a read-only developer assistant for integration work. ### What it helps with Use it when you want to find the right source material for a question such as: * how Allbridge Core works * what a fee page explains * how the SDK handles a Solana transfer * how the REST API flow is structured * which example matches a given client or chain ### What it does The developer assistant narrows the search and points you at the right page, guide, or example. It is useful when you want to move from a product question to the exact documentation that answers it. ### How it works The normal flow is: 1. `search_allbridge_documentation` 2. `get_allbridge_product_summary` 3. `list_available_coding_resources` 4. `get_coding_resource_details` ### What it can search The assistant covers these content scopes: * `project-docs` for product pages, FAQs, audits, and ecosystem reports * `sdk-integration` for SDK guides and SDK-facing examples * `rest-api-integration` for REST API docs and implementation references * `examples` for local usage examples and client configuration samples ### Related tool groups * `bridge` for route planning, balance checks, execution jobs, and transfer tracking * `dev` for read-only documentation and integration guidance * `broadcast` for already signed transaction broadcast # HTTP and Auth Allbridge MCP supports two connection shapes. ### `stdio` Use `stdio` when the client can launch a local process. This is the default for: * Claude Desktop * Claude Code * Cursor * other local MCP clients ### `streamable-http` Use `streamable-http` when the client needs a URL. This is the right choice for: * hosted agents * remote connectors * deployments behind a trusted proxy or tunnel ### Authentication Hosted deployments can expose MCP discovery and auth endpoints so remote clients can authenticate. Point the client at the server URL for the deployment you actually want to use. A local process and a hosted endpoint are different connection targets. ### Security Allbridge MCP should stay read-only for docs, route planning, and balance checks. It should not need private keys to answer those requests. # Local Signing Allbridge MCP does not sign transactions. When bridge execution produces an unsigned payload, hand it off to Local Signer MCP on the user's machine. ### The handoff The normal flow is simple: * Allbridge MCP plans the route and returns the job * the job includes an unsigned step and wallet hints * Local Signer MCP signs that step locally * the signed result is then broadcast ### What to look for in the job The execution job usually includes: * `walletSelector` hints * `walletId` when one wallet should be pinned * the chain family of the source step * the transaction shape for the next step ### What this page does not cover * private key material * wallet signing logic * local account storage Keep signing in the separate signer project. Keep orchestration and route planning in Allbridge MCP. # Tool Reference Allbridge MCP is organized into three tool groups. ### Bridge Use the bridge tools when you are planning or finishing a transfer. * `list_supported_chains` - show the supported chain catalog * `list_supported_tokens` - show the supported token catalog * `find_bridge_routes` - search for available routes * `quote_bridge_transfer` - get a normalized quote for a known token pair * `plan_bridge_transfer` - plan the route from user-friendly input * `check_bridge_balances` - verify that the sender can cover the amount and selected fee * `create_bridge_execution_job` - build the ordered execution steps * `build_bridge_transactions` - return raw transactions for lower-level integrations * `check_stellar_trustline` - verify whether a Stellar account already has the required trustline * `build_stellar_trustline_transaction` - build the Stellar trustline transaction for a recipient account * `check_algorand_optin` - verify whether an Algorand account is already opted into the destination asset or app * `build_algorand_optin_transaction` - build the Algorand opt-in transaction for a recipient account * `get_transfer_status` - track the transfer after broadcast * `search_allbridge_transfers` - search the public explorer, resolve address or transfer hits, and list matching transfer records * `get_allbridge_transfer` - open a single transfer record from the public explorer ### Dev Use the dev tools when you need docs or integration references. * `search_allbridge_documentation` - search the curated docs and examples * `get_allbridge_product_summary` - get the short summary for a product group * `list_available_coding_resources` - list the resources for that product group * `get_coding_resource_details` - fetch the full content for a listed resource ### Broadcast Use the broadcast tools only when the payload is already signed. * `broadcast_signed_transaction` - broadcast a signed payload for a supported family # Local Signer MCP Local Signer MCP signs transactions on the user's machine. It keeps private keys local and only receives the unsigned payload that needs to be signed. * Repository: [allbridge-io/local-signer-mcp](https://github.com/allbridge-io/local-signer-mcp) * Docker image: [allbridge/local-signer-mcp:latest](https://hub.docker.com/repository/docker/allbridge/local-signer-mcp/tags?name=latest) ### What it does Use Local Signer MCP when you need to: * sign a transaction locally * sign and broadcast from a local wallet * keep private keys on the user's machine * work with desktop MCP clients * finish execution after another system prepares the unsigned payload ### What it does not do Local Signer MCP does not: * plan routes * quote transfers * discover docs * model bridge execution logic Those responsibilities stay with Allbridge MCP. ### Client integrations Use stdio when the client can launch a local process on the same machine. Typical local clients include Claude Desktop, Claude Code, Cursor, Windsurf, Continue, Zed, and Cline. For local setups, the config entry should add local-signer as one more registry entry instead of replacing the rest of the file. For Docker-based local setups, use docker run with --env-file so the signer variables stay in a host-side env file and do not appear as separate command-line flags. For remote connectors, use streamable-http only when the client actually requires a URL. ### Transport and security stdio is the default local shape. Docker is still local-first and useful when you want the same stdio entrypoint in a container. streamable-http is the URL-based shape and should be used only when needed. For GUI clients, prefer an explicit Node path instead of a bare node command. ### Wallet selection Local Signer MCP can expose more than one wallet, and the client should choose the intended one explicitly. Prefer the most specific identifier available: * walletId when the client already knows the configured local wallet * from when the flow is EVM-based and the sender address is enough to select the wallet * explicit wallet-family hints when the request is chain-specific Selection rules: * For EVM, choose the wallet that owns the sender address. * For Solana, Tron, Algorand, Stacks, Soroban / Stellar, and Sui, prefer the configured wallet entry for that family. * When more than one wallet exists, use walletId instead of guessing. ### Usage Local Signer MCP is used after another system has prepared an unsigned payload. The common flow is: 1. An orchestration layer creates an unsigned transaction or bridge step. 2. Local Signer MCP signs the payload locally. 3. The signed payload is broadcast by the appropriate system or client. Supported execution patterns: * sign only * sign and broadcast * broadcast an already signed transaction ### Examples Use the examples as starting points when you want a ready-made client config or a flow example. Canonical starting points: * Claude Code registration * Claude Desktop config * Cursor or similar client config * Docker-based registration For Docker, the key idea is simple: keep secrets in --env-file and keep the command line short. # Client Integrations This page shows how to connect Local Signer MCP from common clients. ### Local clients Use `stdio` when the client can launch a local process on the same machine. Typical local clients: * Claude Desktop * Claude Code * Cursor * Windsurf * Continue * Zed * Cline * other local MCP clients Recommended local config entry: ```json { "mcpServers": { "local-signer": { "command": "NODE_BINARY_PATH", "args": ["SIGNER_ENTRYPOINT_PATH"], "env": { "LOCAL_SIGNER_EVM_PRIVATE_KEY": "YOUR_EVM_PRIVATE_KEY", "LOCAL_SIGNER_EVM_RPC_URL": "YOUR_RPC_URL" } } } } ``` If the client can launch `docker`, use a container wrapper instead of a direct binary path: ```json { "mcpServers": { "local-signer": { "command": "docker", "args": [ "run", "-i", "--rm", "--env-file", "LOCAL_SIGNER_ENV_FILE", "allbridge/local-signer-mcp:latest", "node", "dist/index.js" ], "env": {} } } } ``` This keeps the command line short and moves the signer variables into a host-side env file. ### Remote connectors Use `streamable-http` only when the client requires a URL. If the client insists on `https://`, place TLS in front of the signer or expose the signer through a trusted proxy. Recommended remote config entry: ```json { "mcpServers": { "local-signer": { "url": "https://your-signer.example.com/mcp" } } } ``` ### Claude Desktop Open `Settings` -> `Developer` -> `Local MCP servers` -> `Edit Config`. Add `local-signer` as another entry in `mcpServers`; do not overwrite existing servers. ### What to remember * add `local-signer` as one more entry in the registry * do not replace the rest of the config file * keep secret values outside the command line # Examples Use these examples as starting points when you want a ready-made client config or a flow example. ### What belongs here * Claude Desktop config examples * Claude Code registration examples * Cursor and Windsurf JSON snippets * Docker-based registration examples * remote connector examples * Node path examples ### What should not belong here * bridge-planning docs * route quotation docs * docs for Allbridge Core integration logic * private-key management outside the local signer scope ### Canonical snippets #### Claude Code ```bash claude mcp add local-signer -- node SIGNER_ENTRYPOINT_PATH ``` #### Claude Desktop ```json { "mcpServers": { "local-signer": { "command": "NODE_BINARY_PATH", "args": ["SIGNER_ENTRYPOINT_PATH"], "env": { "LOCAL_SIGNER_EVM_PRIVATE_KEY": "YOUR_EVM_PRIVATE_KEY", "LOCAL_SIGNER_EVM_RPC_URL": "YOUR_RPC_URL" } } } } ``` #### Cursor or similar client ```json { "mcpServers": { "local-signer": { "command": "docker", "args": [ "run", "-i", "--rm", "--env-file", "LOCAL_SIGNER_ENV_FILE", "allbridge/local-signer-mcp:latest", "node", "dist/index.js" ], "env": {} } } } ``` #### What this page is for This page is a quick index for copy-paste starting points. For full setup guidance, use: * Client Integrations * Transport and Security * Usage # Transport and Security Local Signer MCP is designed to keep signing local. ### `stdio` Use `stdio` for local tools and desktop clients. Properties: * no HTTP endpoint * no TLS * no network exposure * best default for private keys ### Docker Use Docker when you want the same `stdio` entrypoint in a container. Properties: * still local-first * useful for reproducible local setups * pass secrets with `--env-file LOCAL_SIGNER_ENV_FILE` * keep the env file on the host and do not commit it * do not spell out private keys in the command line ### `streamable-http` Use `streamable-http` only when you need a URL-based connector. Properties: * HTTP transport exposed on a host and port * optional TLS via certificate and private key files * suitable for a trusted proxy or tunnel If the client requires `https://`, use TLS termination. Keep the signer local unless you intentionally expose it through a trusted edge. HTTP mode is unauthenticated. Bind it to `127.0.0.1` unless a trusted tunnel or reverse proxy controls access. ### Node runtime For GUI clients, prefer an absolute Node path instead of a bare `node` command. After selecting the desired Node version, run `which node` and use that path in the client config. # Usage Local Signer MCP is used after another system has prepared an unsigned payload. ### Common flow 1. An orchestration layer creates an unsigned transaction or bridge step. 2. Local Signer MCP signs the payload locally. 3. The signed payload is broadcast by the appropriate system or client. ### Supported execution patterns * sign only * sign and broadcast * broadcast an already signed transaction ### Tools * `get_wallet_capabilities` shows which wallet families and accounts are configured. * `get_accounts` returns configured local account addresses. * `sign_transaction` signs an unsigned transaction and returns the signed payload. * `broadcast_transaction` submits an already signed payload. * `sign_and_broadcast_transaction` signs locally and submits in one step. ### Operational rule Do not move signing logic into the orchestration layer. Keep bridge planning in Allbridge MCP and local execution in Local Signer MCP. # Wallet Selection Local Signer MCP can expose more than one wallet, and the client should choose the intended one explicitly. ### How to choose a wallet Prefer explicit wallet selection when the client supports it. Use the most specific identifier available: * `walletId` when the client already knows the configured local wallet * `from` when the flow is EVM-based and the sender address is enough to select the wallet * explicit wallet-family hints when the request is chain-specific ### Selection rules * For EVM, use `walletId` first, then `from` when the sender address is enough to select the wallet. * For Solana, Tron, Algorand, Stacks, Soroban / Stellar, and Sui, use the configured wallet entry for that family. * When more than one wallet exists, use `walletId` instead of guessing. ### EVM selection order For EVM, the signer resolves credentials in this order: 1. `walletId` on the transaction, if provided 2. `from` on the transaction, if provided 3. `LOCAL_SIGNER_EVM_WALLET__PRIVATE_KEY` / `LOCAL_SIGNER_EVM_WALLET__RPC_URL` 4. `LOCAL_SIGNER_EVM_PRIVATE_KEY_` / `LOCAL_SIGNER_EVM_RPC_URL_` 5. `LOCAL_SIGNER_EVM_PRIVATE_KEY_` / `LOCAL_SIGNER_EVM_RPC_URL_` 6. `LOCAL_SIGNER_EVM_PRIVATE_KEY` / `LOCAL_SIGNER_EVM_RPC_URL` ### Safety Never infer a wallet selection that would point to an unexpected account when the request can be resolved explicitly. # Allbridge Classic Allbridge Classic is a cross-chain bridge between 11 EVM and 8 non-EVM compatible blockchains. Since the mainnet launch in July 2021, it has bridged over $6.3 billion. Allbridge Classic specializes in unique integrations with non-EVM chains, with the upcoming support of Tezos, Waves, and more networks in the future. Website: [allbridge.io ](https://allbridge.io/) Documentation: [docs.allbridge.io](https://docs.allbridge.io/)