# Introduction Brotocol Bridge is a MPC-based hybrid bi-directional bridge that acts as a 'connector' between Bitcoin and other blockchains, enabling seamless asset transfers and swaps between Bitcoin and its Layer 2 networks (L2s) as well as other blockchain ecosystems. **Brotocol currently offers two key features:** * [BroBridge](/what-can-you-do/broswap) * [BroSwap](/what-can-you-do/broswap) ## Key Features * **Bi-Directional Asset Transfers**: Easily transfer assets between Bitcoin and L2s, as well as non-Bitcoin chains. * **Secure and Decentralized**: Utilizes multisigs and decentralized validators to secure all transfers. * **User-Friendly Interface**: Designed to provide a smooth experience for both novice and experienced users. * **Cross-Chain Interoperability**: Supports multiple blockchains including Bitcoin, Stacks, and EVM-compatible chains. Brotocol plays a crucial role in projects building on Bitcoin, offering a 'native-like' DeFi experience by enabling users to interact with smart contracts on L2s using native BTC or other Bitcoin L1 assets. ## Support For assistance, feel free to join our community on [Discord](https://discord.com/invite/xlink). # What is Brotocol? Brotocol: Bridge Better, Bro—Best Rates, Seamless Security! With L1s and L2s multiplying, Brotocol makes cross-chain bridging simple, affordable, and secure—no matter your preferred blockchain. Get the **best rates** with Brotocol Bridge!
### What is Brotocol? Brotocol [BroBridge](/what-can-you-do/brobridge) is a **MPC-based hybrid bi-directional bridge** that acts as a '**connector**' between Bitcoin and other blockchains, enabling anyone to move between chains beyond the limitation of just EVM-based bridges. ### Why Brotocol?
Bridging shouldn’t suck—high fees and sketchy paths are out. Brotocol’s your **crypto bro**, offering: * **Lowest Fees:** Just **0.1%** to bridge native Bitcoin to EVM chains. * **Most Bridge Paths:** Supports **18+ networks**, including non-EVM. * **Rock-Solid Security:** MPC-based for stress-free transfers. * **Seamless Swaps Across Chains:** Allowing users to swap to any assets from native Bitcoin to EVM tokens back and forth. ### Brotocol’s Rate is Unbeatable! If you are bridging 1 $BTC—how much do you keep, let’s see the table below:
***🔴:** No direct bridge but requires the use of CEX deposit/withdrawal and does not include withdrawal fees* Beyond the savings, Brotocol has the most BTC-friendly route possible!
### How does Brotocol Work? When you want to move assets (like Bitcoin) from one network to another, Brotocol handles the process, making sure everything happens securely. **Here’s how it work:** * You start by deciding how much you want to bridge on our UI (e.g: Native $BTC → Arb’s $WBTC) * We lock that amount in a multisig wallet. * Once network confirmed, our validators unlock the equivalent on your target chain (e.g., $WBTC on Arbitrum). * Done—You pay 0.1% fee once. ### Brotocol by the Numbers!
**Here are Brotocol numbers by the numbers (As of 25th March):** * **Total Bridged Volume:** $336.5M+ * **TVL:** $51.1M+ * **Supported Chains:** 18 * **Total Bridge TXs:** 44.8K+ * **Unique User Counts:** 20.1K+ > **Do you know?** The ALEX Multichain Launchpad uses Brotocol which helps anyone to participate in IDO in a click without the need to do manual bridging! ### Bridge Challenges Today
* **Limited Network Support:** Most centralized exchanges (CEXs) don’t support depositing $WBTC on Arbitrum or other low-TVL EVM chains, reducing liquidity and options. * **High and Unpredictable Costs:** Moving $BTC across EVM and non-EVM chains is expensive and inconsistent due to fees (bridging, swapping, withdrawals) and liquidity issues. * **Complex CEX Workarounds:** Users must either bridge Arbitrum’s $WBTC to Ethereum’s $WBTC and deposit/withdraw via CEX, or swap to $ETH, deposit, trade, and withdraw—both costly and often requiring KYC. * **Lack of Bridge Options:** Popular bridges (e.g., Wormhole, Stargate) rarely offer consistent paths between chains like Arbitrum, BNB, or Ethereum for $BTC variants. * **Poor User Experience:** Different $BTC versions vary in support, cost, and ease of movement, creating a confusing and inefficient onboarding process that limits chain adoption.
Let’s take Arbitrum’s $WBTC as a quick example. Arbitrum’s $WBTC moves **$1.3B/month** on Uniswap and holds **$243M** in Aave deposits (March 25, 2025). Bridging it to native BTC? A mess—until Brotocol: * **Old Way:** CEX swaps, high fees, or no paths. * **Brotocol Way:** 0.1% fee, direct to BTC, 18+ chain options. Demand for EVM BTC is huge—Brotocol makes it flow. ### Brotocol’s Proof of Reserve & Audits To check Brotocol’s Proof of Reserve, you can visit here:
All Brotocol audits are available here: [**Brotocol Audit Reports**](https://github.com/xlink-network/xlink-docs/blob/main/developers/security-audits.md) # What is Bonbori?
Bonbori is a cross-chain messaging and consensus layer designed specifically for Bitcoin's off-chain computation ecosystem. The system: * Creates a standardized framework for validating on-chain events across multiple protocols, such as BRC20, Runes, and Staking * Enables secure message exchange between different off-chain computation engines * Provides a decentralized validation mechanism with cryptographic attestations * Maintains a complete audit trail for all validations Bonbori serves as the critical foundation for each of Brotocol's core products: 1. **Multi-Chain Connector**: When Brotocol facilitates movement of stablecoins and other assets onto Bitcoin, Bonbori validates these cross-chain transfers through its threshold-based consensus system, ensuring all assets maintain integrity and security. 2. **Account Abstraction DEX**: Brotocol's DEX relies on Bonbori to securely tap into liquidity pools across chains like Base and Arbitrum. When a Bitcoin user initiates a trade from their Bitcoin wallet, Bonbori validates the transaction parameters before execution, ensuring optimal rates without compromising security. 3. **Payment Protocol**: As Brotocol enables non-Bitcoin users to purchase Bitcoin assets using currencies like USDC or ETH, Bonbori provides the attestation layer that verifies these cross-chain payment flows, allowing merchants to confidently receive BTC while buyers use their preferred currency. ### What does Bonbori do for Brotocol? Here’s how Bonbori supports Brotocol’s core products: **🔁 For BroBridge:** * Validates asset transfers across Bitcoin, Stacks, EVM chains, and beyond. * Produces cryptographic attestations confirming peg-in and peg-out events. * Ensures that bridging is secure, atomic, and cryptographically verifiable. * Supports threshold-based consensus (customizable per integration) to validate user intents and unlock assets on destination chains. **💱 For BroSwap:** * Verifies cross-chain trade intents expressed by Bitcoin users. * Ensures that DEX aggregations and swaps are executed only after proper consensus is reached on transaction validity. * Confirms final trade state and delivers assets back to Bitcoin wallets after cross-chain execution. **💸 For BroPay:** * Validates cross-chain payment flows when non-Bitcoin users pay with tokens like USDC or ETH. * Confirms that a user's payment has been correctly routed and converted before releasing pure BTC to the merchant. * Ensures end-to-end accountability and enables seamless refunds in case of failure. **🛡️ As Infrastructure:** * Provides **standardized validation and messaging** across all Brotocol integrations (Bitcoin L1, Bitcoin L2s, EVMs). * Allows validators and verifiers to **observe and attest** to on-chain events. * Lets **relayers submit proofs** and verifiers double-check them before releasing funds or confirming transactions. * Supports **OP\_RETURN-based automations** triggered directly from Bitcoin L1. ### What Bonbori Means Bonbori (雪洞) refers to traditional Japanese paper lanterns that illuminate pathways during festivals and ceremonies. Much like these lanterns guide people through darkness, Bonbori guides blockchain data across protocols with clarity and security—illuminating the path for Bitcoin's cross-chain communications. # Why Bonbori? ### **Why Bonbori is Essential for Bitcoin's DeFi Evolution** The crypto ecosystem has spent years trying to transform Bitcoin into something it was never meant to be—a smart contract platform. But Bitcoin’s true power lies in its unmatched security and decentralization as a settlement layer. Rather than reshaping Bitcoin to fit DeFi, Brotocol brings DeFi to Bitcoin, preserving its core ethos. To make this inversion possible, Brotocol needs a consensus and messaging infrastructure that aligns with Bitcoin’s principles. This is where Bonbori comes in: a cross-chain validation and communication layer that makes Bitcoin-native interoperability possible—without compromise. Bonbori is the connective tissue that allows Bitcoin to participate in DeFi as Bitcoin, not as an imitation of an EVM. *** ### **What Does Bonbori Solve?** Bonbori tackles one of the hardest problems in crypto: how to enable secure, flexible cross-chain activity without violating Bitcoin’s minimalist, non-Turing-complete architecture. Here’s what it enables: * **Cross-Chain Communication Without Exiting Bitcoin**\ Bonbori ensures that DeFi can reach into Bitcoin’s ecosystem—without extracting BTC or forcing it to operate in foreign formats. * **Customizable Trust Models**\ Whether a project needs federated security or trustless staking-based validation, Bonbori’s threshold consensus system adapts to the risk tolerance of each integration. * **Lightweight, Scalable Consensus**\ With threshold sampling, Bonbori doesn’t require every validator to process all data—making it efficient without sacrificing cryptographic proof. * **Programmable Bitcoin Interactions**\ Through support for OP\_RETURN data and direct validation of Bitcoin events, users can trigger complex workflows from a simple Bitcoin transaction. * **A Single Validation Layer for All Assets**\ BTC, BRC-20, EVM tokens, and more can all route through Bonbori’s unified validation logic, simplifying cross-chain logic across protocols. *** ### **Why Bonbori?** Because Bitcoin doesn’t need to change. Bonbori exists to let the rest of the crypto ecosystem meet Bitcoin on its terms. Where other bridges seek to extract BTC or wrap it for other chains, Bonbori keeps Bitcoin at the center—treating it as the anchor, not an afterthought. Bonbori offers: * **True Alignment with Bitcoin’s Ethos**\ It honors Bitcoin’s architecture, while still unlocking full DeFi utility through smart design and L2 integrations. * **Battle-Tested Security Architecture**\ Powered by multisig custody, cryptographic attestations, decentralized validators, and optional verifiers. * **Builder-Friendly Design**\ Whether you’re an L2 team, a DeFi dev, or a payments protocol, Bonbori gives you the modularity to design your own trust and validation flow. * **Scalability Without Compromise**\ Bonbori’s sampling and modular validator framework means it can scale across assets and chains without losing sight of security. Put simply: Bonbori is not just a bridge protocol. It’s the layer that lets Bitcoin stay Bitcoin—while still joining the broader DeFi world. # Bonbori Consensus Model
Bonbori uses '**Flexible Threshold-based Consensus Model**' which empowers Bitcoin builders with a customizable consensus framework that balances security needs with practical considerations: ### "M-of-N" Threshold Configuration Bonbori's threshold configuration allows end consumers to tailor consensus requirements to their specific needs. Developers can define both required (trusted) validators and optional validators within their consensus model, then set specific agreement thresholds (such as requiring 51% of all validators to concur). This customizable approach enables applications to fine-tune their security parameters based on their unique risk profiles, transaction values, and operational requirements. ### Consensus Flexibility Bonbori offers multiple consensus approaches to accommodate diverse security philosophies. Applications can implement a federated option that relies solely on required validators, prioritizing trust relationships to minimize security costs. Alternatively, they can choose a fully trustless option that utilizes optional validators with staking/slashing mechanisms for a permissionless system. Most applications benefit from hybrid approaches that combine trusted entities with broader validation, striking an optimal balance between security guarantees and operational efficiency. ### Threshold Sampling for Efficiency Bonbori achieves consensus efficiently through its innovative threshold sampling approach. Rather than requiring validators to download and process all consensus data, the system conducts multiple rounds of random sampling across network nodes. With each successful round, consensus confidence grows incrementally until reaching a predetermined threshold. This progressive sampling dramatically reduces bandwidth and computational requirements while maintaining security integrity. The final validation always incorporates verification by trusted nodes, ensuring that efficiency never comes at the expense of reliability. # Reserves
Click here to access or monitor the reserves real-time at the [**Brotocol Reserve**](https://app.xlink.network/bridge/reserve). The Brotocol **Reserve** currently holds approximately 16 different assets, which include: * [aBTC](/overview/reserves/what-is-abtc) * uBTC * [aUSD](/overview/reserves/what-is-ausd) * ALEX * STX * vLiaBTC * CHAX * $B20 * ORDG * ORNJ * TRIO * TX20 * DOG•GO•TO•THE•MOON * BILLION•DOLLAR•CAT * PUPS•WORLD•PEACE * TANUKI•WISDOM # What is aBTC? ## aBTC: Unifying Bitcoin Across Blockchain Ecosystems As part of Brotocol's mission to position Bitcoin at the center of the DeFi landscape, aBTC emerges as a critical connecting layer between native Bitcoin and its wrapped representations across multiple blockchain ecosystems. Building on the same robust foundation as aUSD, aBTC serves as the synthetic bridge that enables seamless interoperability between Bitcoin and its various wrapped forms. ### What is aBTC? aBTC is a synthetic Bitcoin token issued by Brotocol that maintains a 1:1 backing with Bitcoin. Like its stablecoin counterpart aUSD, aBTC exists across multiple chains and serves as the connectivity asset that unifies the fragmented Bitcoin ecosystem. The primary purpose of aBTC is to create a seamless bridge between native Bitcoin and wrapped Bitcoin tokens on various chains, including: * WBTC on Ethereum * WBTC on Arbitrum * BTCB on BSC * cbBTC on Base ### How aBTC Works: The Unified Bitcoin Standard Built on the same security infrastructure as aUSD, aBTC leverages Brotocol's cross-chain architecture to create a unified Bitcoin representation across the cryptocurrency landscape: 1. **Institutional-Grade Security**: Reserve assets backing aBTC are secured through partnerships with established custodians including Fireblocks and Cobo 2. **Cross-Chain Integrity**: When aBTC moves between chains, tokens are burned on the source chain and minted on the destination chain, maintaining consistent total supply 3. **Decentralized Validation**: Bonbori, Brotocol's validator network, ensures secure cross-chain operations 4. **Multi-Party Computation**: Advanced MPC wallet technology secures the underlying assets ### aBTC's Role in the Brotocol Ecosystem Within Brotocol's vision of a Bitcoin-centric DeFi ecosystem, aBTC serves several critical functions: #### 1. Unified Bitcoin Connectivity The Bitcoin ecosystem currently exists in fragmented forms across multiple blockchains. aBTC creates a standardized synthetic asset that can seamlessly connect to WBTC, BTCB, cbBTC, and other wrapped Bitcoin tokens. This unification enables: * Movement between native BTC and wrapped tokens without repeated wrapping/unwrapping processes * Access to liquidity from multiple ecosystems through a single synthetic asset * Simplified trading experience across chains #### 2. Enhanced Interoperability for BroSwap When integrated with BroSwap, aBTC enables native Bitcoin users to tap into liquidity pools that contain wrapped Bitcoin tokens on other chains. This functionality: * Increases available trading depth for Bitcoin-based pairs * Improves price discovery across the entire Bitcoin ecosystem * Reduces fragmentation between Bitcoin markets #### 3. Complementary Role with aUSD Together with aUSD, aBTC creates a comprehensive foundation for Bitcoin-centric trading across the DeFi landscape: * aBTC provides connectivity for Bitcoin-denominated assets * aUSD provides connectivity for USD-denominated stablecoins * The pair creates a complete trading infrastructure that keeps Bitcoin at the center ### Conclusion: Building Bitcoin's Cross-Chain Future aBTC represents a critical infrastructure component that connects Bitcoin's native environment with its wrapped representations across multiple blockchain ecosystems. By creating a unified synthetic asset that bridges these disparate environments, Brotocol enables Bitcoin to maintain its position as the foundational layer while accessing the liquidity and functionality that exists in other ecosystems. As the cryptocurrency landscape continues to evolve, aBTC will play an increasingly important role in ensuring that Bitcoin remains at the center of the financial ecosystem—connecting rather than competing with developments on other chains and strengthening Bitcoin's position as the ultimate settlement layer for digital assets. # What is aUSD?
## aUSD: Bridging Bitcoin to Stablecoin Liquidity in the Brotocol Ecosystem As Bitcoin continues its journey toward becoming the center of the DeFi ecosystem, one critical component has been missing: seamless access to stablecoin liquidity directly from Bitcoin wallets. With the upcoming launch of BroSwap, Brotocol introduces aUSD, a fully-backed synthetic stablecoin designed to serve as the foundational base asset for BTC/USD trading—creating an immediate bridge between Bitcoin and the global stablecoin ecosystem. ### What is aUSD? aUSD is a synthetic stablecoin issued by Brotocol with a 1:1 backing from established stablecoins USDT and USDC. This innovative asset exists across multiple chains, including Bitcoin (as the [Runes](https://www.oklink.com/bitcoin/token/runes/895623-492) token "USD•BY•BROTOCOL" and the [BRC20](https://www.oklink.com/bitcoin/token/brc20/80977467) token "AUSD$"), providing users with a consistent and reliable USD-pegged asset regardless of which blockchain they're using. The core value proposition of aUSD lies in its ability to create immediate stablecoin liquidity on Bitcoin without waiting for major stablecoin issuers to deploy natively. This approach aligns perfectly with Brotocol's philosophy of bringing DeFi functionality to Bitcoin rather than forcing Bitcoin users to leave their preferred ecosystem. Like its companion asset aBTC, which connects native Bitcoin with wrapped Bitcoin versions across chains, aUSD creates a standardized synthetic asset that connects to various stablecoins while maintaining Bitcoin as the home base. ### How aUSD Works: Robust Security and Reserve Management aUSD maintains a full 1:1 backing with reserve assets held by institutional-grade custodians. The reserve structure includes: * USDT on Ethereum * USDT on BSC * USDC on Base * USDC on Arbitrum These reserves are secured through multiple layers of protection: 1. **Institutional-Grade Custody**: Reserve assets are held by established custodians including Fireblocks and Cobo, utilizing advanced MPC wallet technology 2. **Transparent Reserve Reporting**: Up-to-date reserve figures are publicly available at [brotocol.xyz/reserves](https://www.brotocol.xyz/reserves) 3. **Cross-Chain Integrity**: When aUSD moves between chains, the token is burned on the source chain and minted on the destination chain, maintaining consistent total supply 4. **Decentralized Validation**: Bonbori, Brotocol's validator network, ensures secure cross-chain operations ### aUSD as the Foundation for BroSwap's Launch When BroSwap launches, aUSD will serve as the critical base asset that enables immediate trading between Bitcoin and stablecoins without requiring Bitcoin users to leave their native environment. This approach delivers several key benefits: #### 1. Immediate BTC/USD Liquidity Rather than waiting for stablecoin issuers to deploy natively on Bitcoin, aUSD provides day-one access to deep stablecoin liquidity. From launch, Bitcoin users will be able to trade BTC to and from aUSD directly from their Bitcoin wallets, with BroSwap's architecture connecting to established liquidity pools across multiple chains. #### 2. Seamless Cross-Chain Connectivity aUSD serves as the connectivity asset that enables fungible movement between stablecoin ecosystems. When a user swaps BTC for aUSD on BroSwap, the system can utilize liquidity from any of the supported reserve assets (USDT on Ethereum, USDC on Base, etc.) while abstracting away the complexity from the user. #### 3. Foundation for the Bitcoin DeFi Ecosystem By providing a reliable USD-pegged asset on Bitcoin from day one, aUSD creates a foundation for broader DeFi activities. Bitcoin users can maintain stablecoin exposure without leaving the Bitcoin ecosystem, enabling activities like: * Hedging BTC volatility * Trading between BTC and stable value * Maintaining purchasing power * Preparing for the broader arrival of DeFi on Bitcoin ### The Pathway to USDT Integration While aUSD provides immediate stablecoin functionality on Bitcoin, Brotocol recognizes the importance of native stablecoin deployments. The upcoming launch of Tether's USDT on Bitcoin through Taproot assets represents a significant milestone for the ecosystem, and Brotocol has designed aUSD with this transition in mind. When USDT launches on Bitcoin, Brotocol will immediately integrate it as an aUSD reserve asset. This approach provides several advantages: 1. **Immediate Utility**: Bitcoin USDT will instantly connect to Brotocol's cross-chain infrastructure 2. **Enhanced Liquidity**: USDT on Bitcoin will benefit from connection to existing liquidity pools 3. **Seamless User Experience**: Users can choose between aUSD and native USDT based on their preferences 4. **Gradual Transition**: As USDT on Bitcoin gains adoption, users can naturally shift between the assets In the longer term, BroSwap plans to add direct BTC/USDT trading pairs, giving users the option to trade with either synthetic (aUSD) or native (USDT) stablecoins according to their preferences. This flexibility ensures that Bitcoin users maintain choice while benefiting from the deepest possible liquidity. ### aUSD's Role in Brotocol's Broader Vision aUSD exemplifies Brotocol's core mission of bringing DeFi functionality to Bitcoin rather than forcing Bitcoin to adapt to existing DeFi paradigms. By creating a synthetic stablecoin that lives natively on Bitcoin while connecting to established stablecoin ecosystems, Brotocol enables Bitcoin users to access stable value without sacrificing sovereignty or security. This approach complements Brotocol's other core products: * **BroBridge**: The cross-chain connectivity layer that facilitates aUSD's movement between ecosystems * **BroSwap**: The DEX that enables trading between BTC and aUSD (among other assets) * **BroPay**: The payment solution that allows non-Bitcoin users to interact with the Bitcoin ecosystem Together, these products create a comprehensive infrastructure that positions Bitcoin at the center of the DeFi ecosystem rather than as a peripheral participant. ### Conclusion: Building Bridges to Bitcoin's DeFi Future aUSD represents a critical bridge between Bitcoin and the broader stablecoin ecosystem—one that enables immediate functionality while paving the way for native solutions like USDT on Bitcoin. By providing Bitcoin users with day-one access to stablecoin liquidity without requiring them to leave their native environment, aUSD removes one of the major barriers that has historically limited Bitcoin's role in decentralized finance. As the ecosystem evolves and native stablecoins like USDT arrive on Bitcoin, aUSD's role will adapt, continuing to serve as a connectivity layer that brings the best of DeFi to Bitcoin users. This flexible approach ensures that Bitcoin users can access stable value on their own terms, maintaining the security and sovereignty that drew them to Bitcoin in the first place. In the coming "Bitcoin DeFi Summer," aUSD will play a foundational role in accelerating adoption and enabling new use cases—contributing to Brotocol's vision of a Bitcoin-centric financial ecosystem where "the Road to Bitcoin" leads to a more connected, efficient, and user-friendly experience for all. # How to Connect Your Wallet Follow these steps to connect your wallet to Brotocol App. [**🌁 Connect to Brotocol and Start Bridging Now!**](https://brotocol.xyz/bridge/cross-bridge) ### Step 1: Open the Wallet Manager First, click on the **Wallet Manager** located in the top right corner of the Brotocol app. This is where you’ll manage all your wallet connections. ![Select Wallet Manager](/files/Un3krtbS02UyL9fFhlr7) ### Step 2: Choose the Blockchain and Wallet In the Wallet Manager, select the blockchain you are using (e.g., **Stacks Chain**, **Bitcoin Chain** or **EVM Chain**), then choose the wallet that you want to connect. Supported wallets include Leather, Xverse, and others listed in [Supported Wallets](https://github.com/xlink-network/xlink-docs/blob/main/docs/getting-started/README.md). For this example we will choose **Bitcoin Chain** and **Leather** wallet. ![Select Wallet](/files/cmcOjfk9007pHIfXbfnE) ### Step 3: Enter Your Password After selecting your wallet, you will be prompted to enter your wallet’s password. ![Enter Password](/files/Y7Ge4zJxuxgwLBiQsfYX) ### Step 4: Select Your Account Once the password is entered, choose the specific account you want to connect. This account will be used for executing transactions on the bridge. ![Select Account](/files/5YKIDBNYRiEl1N4sN2Sm) ### Step 5: Confirm Your Connection Once the wallet is successfully connected, you will notice the blockchain icon colored in the top right corner of the screen, confirming that your wallet has been successfully linked. ![Check Wallet Connection](/files/zwp9q8dMsQOC8IkmrJ7b) {% hint style="info" %} Keep in mind that, for bridging, you will need to connect wallets for both the source and destination blockchains (e.g., Stacks, Bitcoin, and EVM). Once connected, you will see the respective blockchain icons in the top right corner of the app. {% endhint %} # Supported Wallets Before using Brotocol to bridge your assets across blockchains, you need to ensure that you have a compatible wallet set up and the necessary funds for transaction fees. ## Supported Wallets Brotocol supports various wallets depending on the blockchain, browser, or device you are using. Below is a list of the available wallets for each supported chain, along with information on compatible browsers and mobile devices.
Wallet (Download URL)StacksBitcoinEVMBrowserMobile
Asigna✅❌❌❌
Bitget Wallet❌✅❌✅
BTC Connect❌❌✅¹✅¹
Leather✅✅❌❌
MetaMask❌❌✅✅
OKX✅✅❌✅
Phantom❌❌✅✅
UniSat❌✅❌✅
Xverse✅✅❌✅
Orange✅❌❌✅
Magic Eden❌✅✅✅
Keplr❌❌✅✅
Cosmostation❌❌✅✅
SubWallet❌❌✅✅
Rabby Wallet❌❌✅✅
Brave Wallet❌❌✅✅
Wallet Connect❌❌✅✅
¹ BTC Connect enables connection through Bitget, OKX, UniSat, and Xverse wallets. # Active Notifications
Not all chains are lightning fast—especially for those unfamiliar with Bitcoin’s native network speed, transactions may take some time to complete. But fret not! Brotocol includes **active notifications** to keep you informed about ongoing transactions in real time.
If you have at least one pending notification, your '[**Explorer**](broken://pages/4pWxVjcrQyog9kzQ55N2)' button will be updated to look like the screenshot above.
By clicking 'My records only', you will be able to see the status of your transaction. # BroSwap Swap directly from native Bitcoin to any assets; including EVM and non-EVM assets without restriction!
With BroSwap, you would initiate a swap directly from your Bitcoin wallet to any assets you would like to swap to. **BroSwap currently supports:** * Bitcoin native network * BRC-20 * Runes Swap from BTC to aUSD (Wrapped version of USDT) back and forth or even purchase Runes with stables (aUSD)! If you haven't try BroSwap, try it now here: ## Explore {% content-ref url="/pages/E1A13m4dLzYDsy8I5ihS" %} [Key Concepts](/what-can-you-do/broswap/key-concepts) {% endcontent-ref %} {% content-ref url="/pages/ZsLSFsvMRlVIZx0qPeAm" %} [How to Swap](/what-can-you-do/broswap/how-to-swap) {% endcontent-ref %} {% content-ref url="/pages/p0qUpbBnXFR2J3roCruM" %} [How to Swap Non-Bridgeable Tokens](/what-can-you-do/broswap/how-to-swap-non-bridgeable-tokens) {% endcontent-ref %} ## Support For assistance, please reach out to our Community Managers on [Discord](https://discord.gg/brotocol). # Key Concepts ## DEX Aggregation
To ensure you get the best possible deal for your swaps directly on the native Bitcoin network, BroSwap aggregates liquidity from multiple sources, including Kyber, ALEX, 0xMatcha, and more, tapping into over 100 liquidity pools. This means you avoid high fees, excessive slippage, and the need to use multiple services. You’ll always receive the most optimal rate for your Bitcoin swaps.
For example, in the screenshot above showing a BTC to aUSD swap, the displayed route uses Kyber to offer the best available rate. # How to Swap {% hint style="info" %} Be sure to [connect your wallet first](/getting-started/how-to-connect-your-wallet) before using BroSwap! {% endhint %} ### Step 1: Select the Asset You'd Like to Swap From
BroSwap currently supports up to three different networks to swap to and from: * Bitcoin * BRC-20 * Runes To start, click on the Asset Selection A (The first option) as shown in the screenshot above) to pick the asset you want to swap from. ### Step 2: Select the Asset You'd Like to Swap To
After you have selected the asset you want to swap from, click on the Asset Selection (The second option) as shown in the screenshot above) to pick the asset you want to want to swap to. ### Step 3: Choose the Token you want to Swap From / To
In the Asset Selection pop-up (as shown in the screenshot above), you’ll notice a ‘**⮂ ₿**’ symbol next to certain assets. This indicates that the asset is available for swapping. In our example, I have selected $BTC -> $aUSD; Native Bitcoin network to BRC-20's $aUSD. If the symbol is not shown, that asset cannot be swapped to. ### Step 4: Checking the Rate, Network Fees, Slippages and Minimum Received
Once you’ve selected the assets you want to swap from and to, you can enter the amount you'd like to swap.\ BroSwap will then display an estimate of what you'll receive based on your input. On the same page, you can also adjust settings like **Network Fees**, **Slippage**, and **Route**. {% hint style="success" %} By default, BroSwap selects the most optimal route and network fee to ensure you get the best value for your swap! {% endhint %} ### (Optional) Step 5: Double Check your Fee Estimates, Price Impact and Minimum Received
Before you click Swap, you can check the section below the Swap button to get a good idea on how much you would receive for the Swap. **Important to note:** Our UI sets a default slippage of 4%, which may cause a slight difference between the *Minimum Received* and the *Estimated* amount shown. However, most transactions typically go through with less than 1% slippage—for example, swaps like $BTC <> $aUSD. ### Step 6: Swap it!
We’ll show you the details from Step #5 again before you click **Confirm** to swap. If you're not satisfied with the estimates, you can go back and adjust the slippage or network fee. Once you're happy with the rate, click **Confirm** to proceed. ### Step 7: Approve the Transaction on your Wallet

Xverse Transaction Confirmation Breakdown

On your wallet’s confirmation screen, you’ll see the amount that will be spent for the bridge. Depending on the wallet you’re using, the estimated fees will also be displayed. If everything looks good, go ahead and click **Confirm** to proceed. ### Step 8: All done! Just wait for your Swap to Complete!
You’ve successfully initiated your first swap! 🎉 A pop-up will appear in the upper-right corner of your screen, letting you know there’s a pending transaction. You’ll also notice the [**Explorer**](https://github.com/xlink-network/xlink-docs/blob/main/docs/features/explorer/README.md) button changes to '**1 Pending'**, indicating an active swap is in progress.
If you clicked 'My Records only', you will be able to see your pending transactions and all you have to do now, is just wait until it's completed, that's all! ## Support For assistance, please reach out to our Community Managers on [Discord](https://discord.gg/brotocol). # How to Swap Non-Bridgeable Tokens In some cases, certain tokens may not be supported by the Brotocol bridge due to compatibility limitations. If you are attempting to bridge a token that is not compatible with the Brotocol bridge, it is recommended to use **ALEX Swap** to exchange it for a bridgeable token. This ensures that you can proceed with your cross-chain activities without interruption. [**🔄 Swap your tokens now on ALEX Swap!**](https://app.alexlab.co/swap) ## Supported Tokens Swap your tokens for tokens that can be bridged in Brotocol. You can find a list of supported tokens in our [**Overview section**](https://github.com/xlink-network/xlink-docs/blob/main/docs/developers/supported-blockchains-and-tokens.md). ## Example Use Case
Let’s say you have **USDh**, a token that is not bridgeable via Brotocol. In this case, you can use **ALEX Swap** to exchange **USDh** for **aUSD**, which is compatible with the Brobridge. After the swap, you can proceed with bridging **aUSD** to another blockchain using Brotocol. For more detailed instructions on how to perform swaps on ALEX, visit the [**ALEX Swap documentation**](https://docs.alexlab.co/product-features/token-swaps/how-to). # BroBridge BroBridge is the best place to bridge from Bitcoin to any chains for lowest fees!
If you have not try BroBridge, try it now here: {% hint style="info" %} **Important:** Users can only bridge tokens that represent the **same asset** across different blockchains. For example, BTC can be transferred to its equivalent, WBTC, when moving from Bitcoin to an EVM network, as both represent the same asset on different chains. {% endhint %} ## Explore {% content-ref url="/pages/wwbEtqeU6Csk4SM9Pnff" %} [Key Concepts](/what-can-you-do/brobridge/key-concepts) {% endcontent-ref %} {% content-ref url="/pages/KXvZEvZRzLQqRSDTJmUi" %} [How to Bridge Assets](/what-can-you-do/brobridge/how-to-bridge) {% endcontent-ref %} ## Support For assistance, please reach out to our Community Managers on [Discord](https://discord.gg/brotocol). # Key Concepts ## How Brotocol Bridge Works? The Brotocol Bridge is a hybrid bi-directional bridge that acts as a '**connector**' between Bitcoin and other blockchains. When you want to move assets (like Bitcoin) from one network to another, Brotocol handles the process, making sure everything happens securely.
XLink Bridge
Brotocol works by using secure multisignature wallets (multisigs) and special checkpoints called Endpoints to manage the transfer of assets. For example, when you want to move your Bitcoin to another blockchain, Brotocol "locks" your Bitcoin in a multisig on the Bitcoin network. Then, an equivalent amount is unlocked on the other blockchain through an Endpoint, which is a smart contract responsible for handling the transfer. These Endpoints are owned by multisigs and operated by a decentralized network of validators and verifiers, ensuring that the process is secure and reliable. This system allows you to use your Bitcoin in different blockchain environments, like Ethereum or other layer 2 networks, while keeping your original assets safe. # How to Bridge Assets Follow these steps to bridge your assets between chains using Brotocol! ### Step 0: Connecting your Wallet Before using the bridge, you need to connect a wallet for the blockchain you are bridging from, as well as one for the blockchain you are bridging to (e.g., **Stacks Chain**, **Bitcoin Chain**, or **EVM Chain**). {% hint style="info" %} See the [Prerequisites](https://github.com/xlink-network/xlink-docs/blob/main/docs/introduction/getting-started/prerequisites/README.md) section for the list of **Supported Wallets** and their installation guides. {% endhint %} You can connect your wallet by clicking the **Wallet Manager** located in the top right corner of the Brotocol app. This is where you’ll manage all your wallet connections. ![Select Wallet Manager](/files/HRmrVqG0k9kOxGDVOrj0) In some cases, you can use the same wallet for both blockchains, but you must connect it separately for each blockchain to specify the source and destination accounts. In this example, we will use [Xverse](https://www.xverse.app/), as it supports both the Bitcoin and Stacks networks. Since we are bridging from native BTC to Arbitrum's WBTC, we also need to connect an EVM wallet; in this example, we are using [Rabby Wallet](https://rabby.io/). {% hint style="info" %} For a detailed explanation on how to connect your wallet, check our guide: [**How to Connect your Wallet**](https://github.com/xlink-network/xlink-docs/blob/main/docs/introduction/getting-started/prerequisites/how-to-connect-your-wallet.md). {% endhint %} Once you have connected both wallets, you will see them active in the **Wallet Manager**. ![Active Wallets](/files/m6iqsdbJT1cIP2n7nlws) #### Step 1: Select the Source Blockchain and Token To start, click on the '**From Asset Selection**'. ![To Token Selector](/files/SlPlIEK3aOab90APhvq0) Next, choose the **source blockchain** from which you want to bridge your assets (e.g., **Stacks Chain**). Then, select the **source token** you would like to bridge (e.g., **aUSD**).
{% hint style="info" %} Bridgable tokens for a specific blockchain are identified by the double arrow icon ⮂. You will only be able to select these tokens for bridging with the selected blockchain. {% endhint %} #### Step 2: Select the Destination Blockchain and Token First, click on the '**To Asset Selection**'. ![Select Destination Token](/files/Iqqgdxe3lESgZLX2Pmji) Next, select the **destination blockchain** where you brindge the assets (e.g., Native BTC -> Arbitrum's WBTC). Then, choose the corresponding **destination token** on this chain (e.g., **WBTC Arbitrum ERC-20**). {% hint style="info" %} While you need to select the same bridge asset for the swap, **aUSD can still be bridged to USDT or USDC—and back again!** {% endhint %} ![Select Blockchain and Token Destination](/files/7eruTiK7NMaIpPelvhhy) Important to remember, whichever chain you want to bridge to, you will be able to know if its available to bridge or not based on the green highlight shown above. If you do not see the '**⮂ ₿**' icon, it's mean it's not supported / available to bridge to. #### Step 3: Input the Amount to Bridge Enter the amount of tokens you would like to bridge. You can also use the **Max** button to select your full balance. ![Input Amount of Tokens](/files/AiHSotp5eGE9ekUPqM6f) If you would like to customize the network fee, you can do it so too as shown above! #### Step 4: Initiate the Bridge After confirming the selected blockchains and token amounts, click the **Bridge** button to begin the process. ![Click on Bridge](/files/COIj0H3Pfe5YDZa2JjSP) Before you click Bridge, if you need to check how much the fee breakdown and time required for the bridge, you can scroll down to check as shown below.
#### Step 5: Confirm the Transaction You will be prompted to confirm the bridging transaction. Review the details, ensure everything is correct, and click Confirm to proceed. ![Confirm the Bridge Transaction](/files/73sHNLUIswv5tIliHNU6) #### Step 6: Confirm Transaction After you click Confirm, you will be required to confirm the transaction on-chain by clicking "**Confirm**" on the Xverse Review Transaction pop-up page. ![Scroll Down to Transfer to Unwrap](/files/gToBbbbC2nlkcRPL14w3) ### Step 7: Wait for Confirmation Finally, wait for the transaction to be confirmed on the blockchain. The confirmation time can take anywhere from 10 to 30 minutes, depending on network conditions. Once the transaction is broadcasted, you should see the bridged tokens deposited in your destination wallet. ![Wait for Transaction Confirmation](/files/NOE4US6tiWQNDW94M2fR) {% hint style="info" %} You can monitor your transaction in real time by clicking the **Explorer** page or "**1 Pending**" as shown in the screenshot above. {% endhint %} ## Support For assistance, please reach out to our Community Managers on [Discord](https://discord.gg/brotocol). # Official Links 🌐 Website: 📝 Medium: 🎮 Discord: 💬 Telegram: 🐦 𝕏: 🎨 Download Brotocol Media Kit: # Terms and Conditions IN ACCESSING AND/OR USING BROTOCOL, YOU ACKNOWLEDGE AND AGREE THAT : (a) BROTOCOL IS/ARE PROVIDED ON AN “AS-IS” AND “AS AVAILABLE” BASIS, AND BROTOCOL (“OPERATOR”) AND ITS AFFILIATES (SAVE TO THE EXTENT PROHIBITED BY APPLICABLE LAWS) EXPRESSLY DISCLAIM ANY AND ALL REPRESENTATIONS, WARRANTIES AND/OR CONDITIONS OF ANY KIND IN RESPECT THEREOF, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING ALL WARRANTIES OR CONDITIONS OF MERCHANTABILITY, MERCHANTABLE QUALITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, QUIET ENJOYMENT, ACCURACY, OR NON-INFRINGEMENT. (b) OPERATOR AND ITS AFFILIATES HAS NOT MADE AND MAKES NO REPRESENTATION, WARRANTY AND/OR CONDITION OF ANY KIND THAT BROTOCOL WILL MEET YOUR REQUIREMENTS, OR WILL BE AVAILABLE ON AN UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE BASIS, OR WILL BE ACCURATE, RELIABLE, FREE OF VIRUSES OR OTHER HARMFUL CODE, COMPLETE, LEGAL, OR SAFE. (c) YOU SHALL HAVE NO CLAIM AGAINST OPERATOR AND/OR ITS AFFILIATES IN RESPECT OF ANY LOSS SUFFERED BY YOU IN RELATION TO OR ARISING FROM YOUR ACCESS AND/OR USE OF BROTOCOL. # Overview **Brotocol** is a Bitcoin-first cross-chain protocol that powers BTCFi with bridging, swapping, and payments—secured by Bonbori as the off-chain consensus and validation layer. ## About This documentation is designed for developers integrating with or building on top of the Brotocol ecosystem. Here you'll find: 🏗️ [Deployment information and contract addresses](/developers/deployments/contract-deployment) 🧬 [Integration guides](/developers/integrations/integrations) 🏛️ [Smart contracts documentation](/developers/brotocol-contracts/contracts) 🛡️ [Security audit reports](/developers/brotocol-contracts/security-audits) ## Need Help? If you have questions or need assistance, join our developer community on [GitHub](https://github.com/Brotocol-xyz) or reach out to our team through [Discord](https://discord.gg/brotocol). # How the Bitcoin Bridge Works ## Bitcoin On Bitcoin, users interact with Multisigs (operated by a decentralized network of validators and verifiers) to lock the assets to be bridged ("source asset"), and on the destination blockchain to receive the bridged asset ("destination asset"). Additionally, users on Bitcoin may provide additional data (`OP_RETURN`) to trigger certain smart contract interaction on their behalf automatically by Brotocol. Multisigs are Bitcoin wallets that are operated by multiple signers. In contrast to a typicall wallet requiring just one party to sign a transaction, a multisig requires multiple parties or signers to sign a transaction. ## Bitcoin L2s, EVM and Non-EVM Chains On L2s or non-Bitcoin chains, users interact with "Endpoints" on the source blockchain to lock the assets to be bridged ("source asset"), and on the destination blockchain to receive the bridged asset ("destination asset"). Endpoints are the smart contracts that handle the asset transfers. They are owned by multisig contracts (for example, [Gnosis Safe](https://safe.global/) on Ethereum and [Executor DAO](https://explorer.stacks.co/txid/0xf4bd95ea0486e6a50ae632c613f1d72b2a5bbbc4211b494cd0f1d3443658544d?chain=mainnet) on Stacks) operated by a decentralized network of validators and verifiers. Users use Endpoints to trigger transfer of source assets. The destination assets are then sent by a relayer by producing cryptographic proofs. That the assets are held by contracts owned by multisig contracts is important because this minimises the risk of a malicious actor stealing the private key and assets sent by users. # Overview This section outlines Brotocol contract deployments across supported blockchains. ## Chain-Specific Deployments Brotocol's cross-chain system relies on dedicated contract deployments per chain. These typically include endpoint contracts, registry and helper contracts, and token contracts. For a deeper look at Brotocol's contract architecture, see [Brotocol Contracts](/developers/brotocol-contracts/contracts). ### Stacks Deployments information for Stacks include: * [**Chains Information**](/developers/deployments/chains/stacks/stacks-chains-info) - Maps Stacks chain IDs to their corresponding network names. * [**Token Approved Pairs**](/developers/deployments/chains/stacks/stacks-token-approved-pairs) - Lists approved token pairs for cross-chain transfers from Stacks. * [**Tokens Information**](/developers/deployments/chains/stacks/stacks-tokens-info) - Details supported tokens and their configurations on Stacks. ### EVM Deployments information for EVM-compatible blockchains include: * [**Contract Addresses**](/developers/deployments/chains/evm/ethereum-contract-addresses) - Lists contract addresses for supported EVM networks. * [**Tokens Information**](/developers/deployments/chains/evm/ethereum-tokens-info) - Details supported tokens and their configurations on each EVM chain. ### Adding New Chains As Brotocol expands to support additional blockchain networks, deployment information for new chains will be documented here using the same structure. # Chains # Stacks # Chains Information | Chain ID | Name | Buffer Length | | -------- | -------- | ------------- | | 1n | Ethereum | 20n | | 2n | BSC | 20n | | 3n | CORE | 20n | | 4n | Bsquared | 20n | | 5n | BOB | 20n | | 6n | Bitlayer | 20n | | 7n | Lorenzo | 20n | | 8n | Merlin | 20n | | 9n | AILayer | 20n | | 10n | MODE | 20n | | 11n | Xlayer | 20n | | 12n | Arbitrum | 20n | | 13n | Aurora | 20n | | 14n | Manta | 20n | | 15n | Linea | 20n | | 16n | Base | 20n | | 17n | AVAX | 20n | | 18n | Mezo | 20n | | 19n | Solana | 64n | # Token Approved Pairs ## Table of Contents * [brc20-db20](#brc20-db20) * [bsc-ghiblicz](#bsc-ghiblicz) * [runes-dog](#runes-dog) * [runes-trump](#runes-trump) * [token-abtc](#token-abtc) * [token-alex](#token-alex) * [token-avax](#token-avax) * [token-eth](#token-eth) * [token-link](#token-link) * [token-nxpc](#token-nxpc) * [token-pepe](#token-pepe) * [token-slunr](#token-slunr) * [token-sol](#token-sol) * [token-spx6900](#token-spx6900) * [token-ssko](#token-ssko) * [token-susdt](#token-susdt) * [token-tbtc](#token-tbtc) * [token-ubtc](#token-ubtc) * [token-usdc](#token-usdc) * [token-usdg](#token-usdg) * [token-usdt](#token-usdt) * [token-wbtc](#token-wbtc) * [token-wstx-v2](#token-wstx-v2) * [token-wvlialex](#token-wvlialex) * [token-wvlqstx](#token-wvlqstx) * [token-xbtc](#token-xbtc) ## brc20-db20 | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ----------------- | ------------------ | ------------ | | 1n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 2n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 3n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 4n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 5n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 6n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 7n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 8n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 9n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 10n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 11n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 12n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 13n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 14n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 15n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | | 16n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 184.68664743 | ## bsc-ghiblicz | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ------------------ | ------------ | ------------ | | 2n | true | true | 0.40% | 128122998.07815502 | 128.12299807 | 128.12299807 | ## runes-dog | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ----------------- | ------------------ | ------------ | | 1n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 2n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 3n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 4n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 5n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 6n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 7n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 8n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 9n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 10n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 11n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 12n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 13n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 14n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 15n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | | 16n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 223.67383661 | ## runes-trump | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ------- | | 1n | true | false | 0.10% | 1000000 | 100 | 100 | | 2n | true | false | 0.10% | 1000000 | 100 | 100 | | 16n | true | false | 0.10% | 1000000 | 100 | 100 | ## token-abtc | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ---------- | | 1n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 2n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 3n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 4n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 5n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 6n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 7n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 8n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 9n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 10n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 11n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 12n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 13n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 14n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 15n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | | 16n | true | false | 0.10% | 9.999 | 10.001 | 0.00000919 | ## token-alex | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ----------- | | 1n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 2n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 3n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 4n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 5n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 6n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 7n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 8n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 9n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 10n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 11n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 12n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 13n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 14n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 15n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | | 16n | true | false | 0.10% | 49995000 | 50005000 | 55.91508958 | ## token-avax | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | -------------- | ---------- | ---------- | | 17n | true | true | 0.40% | 41876.04690117 | 0.04187604 | 0.04187604 | ## token-eth | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ------------ | ---------- | ---------- | | 1n | true | true | 0.40% | 555.55555555 | 0.00055555 | 0.00055555 | | 2n | true | true | 0.40% | 555.55555555 | 0.00055555 | 0.00055555 | | 12n | true | true | 0.40% | 555.55555555 | 0.00055555 | 0.00055555 | | 16n | true | true | 0.40% | 555.55555555 | 0.00055555 | 0.00055555 | | 17n | true | true | 0.40% | 555.55555555 | 0.00055555 | 0.00055555 | ## token-link | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | -------------- | ---------- | --------- | | 1n | true | true | 0.40% | 79872.20447284 | 0.0798722 | 0.0798722 | | 12n | true | true | 0.40% | 79872.20447284 | 0.0798722 | 0.0798722 | ## token-nxpc | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | -------------- | ---------- | ---------- | | 17n | true | true | 0.40% | 452488.6877828 | 0.45248868 | 0.45248868 | ## token-pepe | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ----------------- | -------------- | -------------- | | 1n | true | true | 0.40% | 72306579898.77079 | 72306.57989877 | 72306.57989877 | | 2n | true | true | 0.40% | 72306579898.77079 | 72306.57989877 | 72306.57989877 | | 12n | true | true | 0.40% | 72306579898.77079 | 72306.57989877 | 72306.57989877 | ## token-slunr | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ------- | | 1n | false | true | 0.40% | 50000000 | 100 | 100 | | 2n | false | true | 0.40% | 50000000 | 100 | 100 | ## token-sol | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ------------- | ---------- | ---------- | | 1n | true | true | 0.40% | 8236.55382587 | 0.00823655 | 0.00823655 | | 19n | true | true | 0.40% | 8236.55382587 | 0.00823655 | 0.00823655 | ## token-spx6900 | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | --------------- | ---------- | ---------- | | 1n | true | true | 0.40% | 877192.98245614 | 0.87719298 | 0.87719298 | ## token-ssko | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ----------------- | ------------- | ------------- | | 2n | true | true | 0.40% | 7864730676.561181 | 7864.73067656 | 7864.73067656 | ## token-susdt | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ------- | | 1n | true | false | 0.10% | 999900 | 1000100 | 1 | | 2n | true | false | 0.10% | 999900 | 1000100 | 1 | | 3n | true | false | 0.10% | 999900 | 1000100 | 1 | | 4n | true | false | 0.10% | 999900 | 1000100 | 1 | | 5n | true | false | 0.10% | 999900 | 1000100 | 1 | | 6n | true | false | 0.10% | 999900 | 1000100 | 1 | | 7n | true | false | 0.10% | 999900 | 1000100 | 1 | | 8n | true | false | 0.10% | 999900 | 1000100 | 1 | | 9n | true | false | 0.10% | 999900 | 1000100 | 1 | | 10n | true | false | 0.10% | 999900 | 1000100 | 1 | | 11n | true | false | 0.10% | 999900 | 1000100 | 1 | | 12n | true | false | 0.10% | 999900 | 1000100 | 1 | | 13n | true | false | 0.10% | 999900 | 1000100 | 1 | | 14n | true | false | 0.10% | 999900 | 1000100 | 1 | | 15n | true | false | 0.10% | 999900 | 1000100 | 1 | | 16n | true | false | 0.10% | 999900 | 1000100 | 1 | ## token-tbtc | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ------- | | 1n | true | true | 0.40% | 10 | 0.00001 | 0.00001 | | 18n | true | true | 0.40% | 10 | 0.00001 | 0.00001 | ## token-ubtc | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ----------- | ---------- | ---------- | | 1n | true | false | 0.25% | 100 | 0.00005 | 0.00005 | | 2n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 3n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 4n | true | true | 0.40% | 9.21854402 | 0.00000921 | 0.00000921 | | 5n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 6n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 7n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 8n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 9n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 10n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 11n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 12n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 13n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 14n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 15n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | | 16n | true | false | 0.10% | 11.69576964 | 0.00001169 | 0.00001169 | ## token-usdc | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ------- | | 12n | true | true | 0.40% | 1000000 | 1 | 1 | | 16n | true | true | 0.40% | 1000000 | 1 | 1 | | 17n | true | true | 0.40% | 1000000 | 1 | 1 | | 18n | true | true | 0.40% | 1000000 | 1 | 1 | | 19n | true | true | 0.40% | 1000000 | 1 | 1 | ## token-usdg | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ------- | | 19n | true | true | 0.40% | 1000000 | 1 | 1 | ## token-usdt | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ------- | | 1n | true | true | 0.40% | 1000000 | 1 | 1 | | 2n | true | true | 0.40% | 1000000 | 1 | 1 | | 12n | true | true | 0.40% | 1000000 | 1 | 1 | | 16n | true | true | 0.40% | 1000000 | 1 | 1 | | 17n | true | true | 0.40% | 1000000 | 1 | 1 | | 18n | true | true | 0.40% | 1000000 | 1 | 1 | | 19n | true | true | 0.40% | 1000000 | 1 | 1 | ## token-wbtc | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ---------- | | 1n | true | true | 0.40% | 9.21854402 | 0.00000921 | 0.00000921 | | 2n | true | true | 0.40% | 9.21854402 | 0.00000921 | 0.00000921 | | 12n | true | true | 0.40% | 9.21854402 | 0.00000921 | 0.00000921 | | 16n | true | true | 0.40% | 9.21854402 | 0.00000921 | 0.00000921 | | 17n | true | true | 0.40% | 9.21854402 | 0.00000921 | 0.00000921 | | 19n | true | true | 0.40% | 9.21854402 | 0.00000921 | 0.00000921 | ## token-wstx-v2 | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ----------------- | ------------------ | ---------- | | 1n | true | false | 0.10% | 213107416.8797954 | 213150042.62574596 | 1.43745489 | ## token-wvlialex | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ---------- | | 3n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 4n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 5n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 6n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 7n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 8n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 9n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 10n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 11n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 12n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 13n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 14n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 15n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | | 16n | true | false | 0.10% | 49995000 | 50005000 | 50.8626187 | ## token-wvlqstx | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------------- | ---------------- | --------- | | 3n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 4n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 5n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 6n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 7n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 8n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 9n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 10n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 11n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 12n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 13n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 14n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 15n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | | 16n | true | false | 0.10% | 1428428.57142857 | 1428714.28571428 | 1.2982172 | ## token-xbtc | Chain ID | Approved | Burnable | Fee | Max Amount | Min Amount | Min Fee | | -------- | -------- | -------- | ----- | ---------- | ---------- | ------- | | 19n | true | true | 0.40% | 10 | 0.00001 | 0.00001 | # Tokens Information | Token | Name | Decimals | Symbol | Token URI | Address | | -------------- | -------------------------- | -------- | -------- | -------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | brc20-db20 | $B20 (BRC20) | 8n | $B20 | [brc20-db20.json](https://cdn.alexlab.co/metadata/brc20-db20.json) | [SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-db20](https://explorer.stxer.xyz/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-db20) | | bsc-ghiblicz | GhibliCZ | 8n | Ghibli | [bsc-ghiblicz.json](https://cdn.alexlab.co/metadata/bsc-ghiblicz.json) | [SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.bsc-ghiblicz](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.bsc-ghiblicz) | | runes-dog | DOG GO TO THE MOON (RUNES) | 8n | DOG | [runes-dog.json](https://cdn.alexlab.co/metadata/runes-dog.json) | [SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.runes-dog](https://explorer.stxer.xyz/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.runes-dog) | | runes-trump | THE REAL TRUMP RUNE | 8n | TRUMP | [runes-trump.json](https://cdn.alexlab.co/metadata/runes-trump.json) | [SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.runes-trump](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.runes-trump) | | token-abtc | aBTC | 8n | aBTC | [token-abtc.json](https://cdn.alexlab.co/metadata/token-abtc.json) | [SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-abtc](https://explorer.stxer.xyz/txid/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-abtc) | | token-alex | ALEX Token | 8n | ALEX | [token-alex.json](https://cdn.alexlab.co/metadata/token-alex.json) | [SP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-alex](https://explorer.stxer.xyz/txid/SP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-alex) | | token-avax | AVAX | 8n | AVAX | [token-avax.json](https://cdn.brotocol.xyz/metadata/token-avax.json) | [SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-avax](https://explorer.stxer.xyz/txid/SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-avax) | | token-eth | ETH | 8n | ETH | [token-eth.json](https://cdn.alexlab.co/metadata/token-eth.json) | [SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-eth](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-eth) | | token-link | LINK | 8n | LINK | [token-link.json](https://cdn.alexlab.co/metadata/token-link.json) | [SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-link](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-link) | | token-nxpc | MapleStory Universe | 8n | NXPC | [token-nxpc.json](https://cdn.brotocol.xyz/metadata/token-nxpc.json) | [SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-nxpc](https://explorer.stxer.xyz/txid/SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-nxpc) | | token-pepe | PEPE the Frog | 8n | PEPE | [token-pepe.json](https://cdn.brotocol.xyz/metadata/token-pepe.json) | [SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-pepe](https://explorer.stxer.xyz/txid/SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-pepe) | | token-slunr | sLUNR | 8n | sLUNR | [token-slunr.json](https://cdn.alexlab.co/metadata/token-slunr.json) | [SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-slunr](https://explorer.stxer.xyz/txid/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-slunr) | | token-sol | SOL | 8n | SOL | [token-sol.json](https://cdn.alexlab.co/metadata/token-sol.json) | [SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-sol](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-sol) | | token-spx6900 | SPX6900 | 8n | SPX6900 | [token-spx6900.json](https://cdn.brotocol.xyz/metadata/token-spx6900.json) | [SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-spx6900](https://explorer.stxer.xyz/txid/SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-spx6900) | | token-ssko | SKO | 8n | SKO | [token-ssko.json](https://cdn.alexlab.co/metadata/token-ssko.json) | [SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-ssko](https://explorer.stxer.xyz/txid/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-ssko) | | token-susdt | aUSD | 8n | aUSD | [token-susdt.json](https://cdn.alexlab.co/metadata/token-susdt.json) | [SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-susdt](https://explorer.stxer.xyz/txid/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-susdt) | | token-tbtc | tBTC | 8n | tBTC | [token-abtc.json](https://cdn.alexlab.co/metadata/token-abtc.json) | [SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-tbtc](https://explorer.stxer.xyz/txid/SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-tbtc) | | token-ubtc | uBTC | 8n | uBTC | [token-ubtc.json](https://cdn.alexlab.co/metadata/token-ubtc.json) | [SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-ubtc](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-ubtc) | | token-usdc | USDC | 8n | USDC | [token-susdt.json](https://cdn.alexlab.co/metadata/token-susdt.json) | [SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-usdc](https://explorer.stxer.xyz/txid/SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-usdc) | | token-usdg | USDG | 8n | USDG | [token-susdt.json](https://cdn.alexlab.co/metadata/token-susdt.json) | [SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-usdg](https://explorer.stxer.xyz/txid/SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-usdg) | | token-usdt | USDT | 8n | USDT | [token-susdt.json](https://cdn.alexlab.co/metadata/token-susdt.json) | [SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-usdt](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-usdt) | | token-wbtc | WBTC | 8n | WBTC | [token-abtc.json](https://cdn.alexlab.co/metadata/token-abtc.json) | [SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-wbtc](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-wbtc) | | token-wstx-v2 | STX Wrapper | 8n | wstx | [token-wstx.json](https://cdn.alexlab.co/metadata/token-wstx.json) | [SP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wstx-v2](https://explorer.stxer.xyz/txid/SP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wstx-v2) | | token-wvlialex | vLiALEX Wrapper | 8n | wvlialex | [token-wvlialex.json](https://cdn.alexlab.co/metadata/token-wvlialex.json) | [SP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wvlialex](https://explorer.stxer.xyz/txid/SP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wvlialex) | | token-wvlqstx | vLiSTX Wrapper | 8n | wvlqstx | [token-wvlqstx.json](https://cdn.alexlab.co/metadata/token-wvlqstx.json) | [SP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wvlqstx](https://explorer.stxer.xyz/txid/SP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wvlqstx) | | token-xbtc | xBTC | 8n | xBTC | [token-abtc.json](https://cdn.alexlab.co/metadata/token-abtc.json) | [SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-xbtc](https://explorer.stxer.xyz/txid/SP2FGHFNGMH6NF2427Y20271Q6CKJ67FDX2V2JG6X.token-xbtc) | # EVM # Contract Addresses ## Table of Contents * [arbitrum](#arbitrum) * [avax](#avax) * [base](#base) * [bob](#bob) * [bsc](#bsc) * [bsquared](#bsquared) * [core](#core) * [core\_testnet](#core_testnet) * [ethereum](#ethereum) * [linea](#linea) * [mezo](#mezo) * [mode](#mode) * [sepolia](#sepolia) ## Contract Addresses ## arbitrum | Contract | Address | | ------------- | -------------------------------------------- | | ENDPOINT | `0x7a5912c6A188d7217dB285C890be61d8503A5baF` | | MULTISIG | `0xF162b6467Eaf066A513a4B9235009d60c1faCf44` | | REGISTRY | `0x88af5f4bDd601c1bd3674bF1aD2CC282a720D66C` | | TOKEN\_ABTC | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | | TOKEN\_ALEX | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | | TOKEN\_ATALEX | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | | TOKEN\_BTC | `0x2f2a2543B76A4166549F7aaB2e75Bef0aefC5B0f` | | TOKEN\_ETH | `0x82aF49447D8a07e3bd95BD0d56f35241523fBab1` | | TOKEN\_LINK | `0xf97f4df75117a78c1A5a0DBb814Af92458539FB4` | | TOKEN\_LISTX | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | | TOKEN\_PEPE | `0x25d887ce7a35172c62febfd67a1856f20faebb00` | | TOKEN\_SUSDT | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | | TOKEN\_USDC | `0xaf88d065e77c8cC2239327C5EDb3A432268e5831` | | TOKEN\_WUBTC | `0xAB01bbc2EE103d227f2EeE50b230506508b560c5` | ## avax | Contract | Address | | ----------- | -------------------------------------------- | | ENDPOINT | `0xd96F5d515A679d4a5343Eed73d26535a3326a060` | | MULTISIG | `0x62F7D5f4ADF9521cFc609bA452839dcb4e81e79C` | | REGISTRY | `0x88af5f4bDd601c1bd3674bF1aD2CC282a720D66C` | | TOKEN\_AVAX | `0xB31f66AA3C1e785363F0875A1B74E27b85FD66c7` | | TOKEN\_BTC | `0x152b9d0FdC40C096757F570A51E494bd4b943E50` | | TOKEN\_ETH | `0x49D5c2BdFfac6CE2BFdB6640F4F80f226bc10bAB` | | TOKEN\_NXPC | `0x5E0E90E268BC247Cc850c789A0DB0d5c7621fb59` | | TOKEN\_USDC | `0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E` | ## base | Contract | Address | | ------------- | -------------------------------------------- | | ENDPOINT | `0x18c05Ec3799EB15fe49A141ce844e55514438Fa7` | | MULTISIG | `0xF162b6467Eaf066A513a4B9235009d60c1faCf44` | | REGISTRY | `0x88af5f4bDd601c1bd3674bF1aD2CC282a720D66C` | | TOKEN\_ABTC | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | | TOKEN\_ALEX | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | | TOKEN\_ATALEX | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | | TOKEN\_BTC | `0xcbb7c0000ab88b473b1f5afd9ef808440eed33bf` | | TOKEN\_ETH | `0x4200000000000000000000000000000000000006` | | TOKEN\_LISTX | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | | TOKEN\_SUSDT | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | | TOKEN\_USDC | `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` | | TOKEN\_WUBTC | `0x9e801CB9ce84a84a563E5a74Cc2f3Ad55F914072` | ## bob | Contract | Address | | ------------------- | -------------------------------------------- | | ENDPOINT | `0x2AeD35A18Bc02472519Ca6F25b70a8e9fE938430` | | MIGRATE | `0xF5866c90CD07b565dF3Ec89CeC4c6a6078f05C3a` | | MIGRATE\_BOB\_L2 | `0x9dF50caFde832eda2857903265905627AC5A8522` | | MIGRATE\_BOB\_L2\_S | `0xa5171F62747dcD8EcB141874e6Ba7828576F1c9E` | | MULTISIG | `0x1A86fF397B58DB43ab019D336931E6a71CC56Ce5` | | REGISTRY | `0x88af5f4bDd601c1bd3674bF1aD2CC282a720D66C` | | TOKEN\_ABTC | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | | TOKEN\_ALEX | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | | TOKEN\_ATALEX | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | | TOKEN\_DB20 | `0x305A85e892E89Fa0a2bcD92337682d55559a6Ee9` | | TOKEN\_DOG | `0x916a82E34430804D9B65e0b5aE7D07Ae7439C81D` | | TOKEN\_LISTX | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | | TOKEN\_SUSDT | `0xf4A6170E827Ba17be9a3423b8662Cc82Eb273730` | | TOKEN\_WUBTC | `0x2E512BA02454FC48269A9589512239D64602CBC8` | ## bsc | Contract | Address | | --------------- | -------------------------------------------- | | ENDPOINT | `0x5298718429046b1d38106864bBfDc9326C840092` | | MIGRATE | `0xd15B997505739C02564DE7f0E010B42b2F81520d` | | MULTISIG | `0x4306374f07382b36AAe832A50831C8C5b26Cd41e` | | REGISTRY | `0xFFda60ed91039Dd4dE20492934bC163e0F61e7f5` | | TOKEN\_ABTC | `0x0F38ED043A1A2ec79B15d7F4FB8D25036680ce03` | | TOKEN\_ALEX | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | | TOKEN\_BTC | `0x7130d2a12b9bcbfae4f2634d864a1ee1ce3ead9c` | | TOKEN\_DB20 | `0x305A85e892E89Fa0a2bcD92337682d55559a6Ee9` | | TOKEN\_DOG | `0x916a82E34430804D9B65e0b5aE7D07Ae7439C81D` | | TOKEN\_ETH | `0x2170Ed0880ac9A755fd29B2688956BD959F933F8` | | TOKEN\_GHIBLICZ | `0x795D2710E383F33fbEbe980a155b29757b6703f3` | | TOKEN\_PEPE | `0x25d887ce7a35172c62febfd67a1856f20faebb00` | | TOKEN\_SKO | `0x9Bf543D8460583Ff8a669Aae01d9cDbeE4dEfE3c` | | TOKEN\_SUSDT | `0x18c05Ec3799EB15fe49A141ce844e55514438Fa7` | | TOKEN\_TRUMP | `0x5879CdD0a4880D5Dc37C5aa8Ee0d1f319711B231` | | TOKEN\_USDT | `0x55d398326f99059fF775485246999027B3197955` | | TOKEN\_WUBTC | `0x2E512BA02454FC48269A9589512239D64602CBC8` | ## bsquared | Contract | Address | | ------------- | -------------------------------------------- | | ENDPOINT | `0x916a82E34430804D9B65e0b5aE7D07Ae7439C81D` | | MIGRATE | `0xd491f20B3d443DbAA61536662Af22421B97bCAC9` | | MULTISIG | `0x10eeCCc43172458F0ff9Cc3E9730aB256fAEE32e` | | REGISTRY | `0x88af5f4bDd601c1bd3674bF1aD2CC282a720D66C` | | TOKEN\_ABTC | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | | TOKEN\_ALEX | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | | TOKEN\_ATALEX | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | | TOKEN\_DB20 | `0xBAcad57995eb9DF5B151bb30b5Ec6bA1D0A3C560` | | TOKEN\_DOG | `0xEC72D43EeA62F63E097751bfE9866650689FfcBc` | | TOKEN\_LISTX | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | | TOKEN\_SUSDT | `0x0CA7f9247932307c5e4b9Ffed88Ddc057DfAAaCC` | | TOKEN\_UBTC | `0x796e4D53067FF374B89b2Ac101ce0c1f72ccaAc2` | ## core | Contract | Address | | ------------- | -------------------------------------------- | | ENDPOINT | `0xE43599C50eeEDc4Ce1b05162B934e47136865cDF` | | MIGRATE | `0x10eeCCc43172458F0ff9Cc3E9730aB256fAEE32e` | | MULTISIG | `0xEC72D43EeA62F63E097751bfE9866650689FfcBc` | | REGISTRY | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | | TOKEN\_ABTC | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | | TOKEN\_ALEX | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | | TOKEN\_ATALEX | `0x9e801CB9ce84a84a563E5a74Cc2f3Ad55F914072` | | TOKEN\_DB20 | `0x80074f342764027f5C4e2f7CD7D0DED611Dfb7cD` | | TOKEN\_DOG | `0x3280A4031d7990D1905d7823E7725cb9ad649F37` | | TOKEN\_LISTX | `0xE67640ABD424d9456eF8A4160D5753Fe5833291d` | | TOKEN\_SUSDT | `0xe80e0C533D41343b0038a3eA74102B4b9fF13e7e` | | TOKEN\_WUBTC | `0xFc57d34855c9944BdBCC0cb3a18B6c7d345DEc8c` | ## core\_testnet | Contract | Address | | ---------------- | -------------------------------------------- | | ENDPOINT | `0x2722c11a7f5Fd5e8c36f508AE28e9a7305080841` | | ENDPOINT\_NATIVE | `0x6A7319452A958112877a44bc93f126c29B1Cd6ee` | | MULTISIG | `0x3Fac7caA7E60583CDd12D860f24a482765899526` | | REGISTRY | `0x05C05eA2cCe52656FB84842c3212f38AB58FaC6f` | | REGISTRY\_NATIVE | `0xBA7ee8346C48675A7Bce3CC89D4AD84362fd2708` | | TOKEN\_ABTC | `0xCa4E6271f3921B5f5A441D3de970c05f9fca200b` | | TOKEN\_ALEX | `0x2AcC30125690A2772a1E57A8196D248c4BdccD7b` | | TOKEN\_BTC | `0x0C4c099D5A00DD01b4543D604751351342B23Bad` | | TOKEN\_SUSDT | `0xa48486cB7eaF9A3B4880A5AC6EF3d26FE973cF02` | | TOKEN\_USDT | `0xb598aA2F0065081De44A15b0546f85e5DC79E374` | ## ethereum | Contract | Address | | -------------- | -------------------------------------------- | | ENDPOINT | `0xB1c34A9F630eDb880f289683cFac2f923B31C94d` | | MIGRATE | `0x4306374f07382b36AAe832A50831C8C5b26Cd41e` | | MIGRATE\_BOB | `0xA6420Eba9b8C514A5793429Ba2873274A63531Bb` | | MULTISIG | `0x65dFacfD08AfDD1CC02Caf3DE411661603394090` | | REGISTRY | `0x13b72A19e221275D3d18ed4D9235F8F859626673` | | TOKEN\_ABTC | `0x31761a152F1e96F966C041291644129144233b0B` | | TOKEN\_ALEX | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | | TOKEN\_BTC | `0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599` | | TOKEN\_DB20 | `0x2AeD35A18Bc02472519Ca6F25b70a8e9fE938430` | | TOKEN\_DOG | `0x7D4de6105595a5fCac3fbEAED5639624abDd1D9d` | | TOKEN\_ETH | `0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2` | | TOKEN\_LINK | `0x514910771AF9Ca656af840dff83E8264EcF986CA` | | TOKEN\_PEPE | `0x6982508145454ce325ddbe47a25d4ec3d2311933` | | TOKEN\_SOL | `0xD31a59c85aE9D8edEFeC411D448f90841571b89c` | | TOKEN\_SPX6900 | `0xe0f63a424a4439cbe457d80e4f4b51ad25b2c56c` | | TOKEN\_STX | `0x80074f342764027f5C4e2f7CD7D0DED611Dfb7cD` | | TOKEN\_SUSDT | `0x73F0f50815CA4698d8e722Cf1D054D223a217138` | | TOKEN\_TBTC | `0x18084fbA666a33d37592fA2633fD49a74DD93a88` | | TOKEN\_TRUMP | `0x51CDa809dC64a060F35F6c96EF6927CABc992D94` | | TOKEN\_USDT | `0xdAC17F958D2ee523a2206206994597C13D831ec7` | ## linea | Contract | Address | | ------------- | -------------------------------------------- | | ENDPOINT | `0x0F38ED043A1A2ec79B15d7F4FB8D25036680ce03` | | MULTISIG | `0x3280A4031d7990D1905d7823E7725cb9ad649F37` | | REGISTRY | `0x88af5f4bDd601c1bd3674bF1aD2CC282a720D66C` | | TOKEN\_ABTC | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | | TOKEN\_ALEX | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | | TOKEN\_ATALEX | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | | TOKEN\_DB20 | `0x24A44C95452df9feC1876f7B907E2dD2Adaa29A7` | | TOKEN\_DOG | `0xce83DD21264323c1D7D246f347Db84A8180970cb` | | TOKEN\_LISTX | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | | TOKEN\_SUSDT | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | | TOKEN\_WUBTC | `0x9e801CB9ce84a84a563E5a74Cc2f3Ad55F914072` | ## mezo | Contract | Address | | ----------- | -------------------------------------------- | | ENDPOINT | `0x79d1C91053baceced5C796aB8a765E4d5aB38e8a` | | MULTISIG | `0x62F7D5f4ADF9521cFc609bA452839dcb4e81e79C` | | REGISTRY | `0x88af5f4bDd601c1bd3674bF1aD2CC282a720D66C` | | TOKEN\_TBTC | `0x7b7C000000000000000000000000000000000000` | | TOKEN\_USDC | `0x04671C72Aab5AC02A03c1098314b1BB6B560c197` | | TOKEN\_USDT | `0xeB5a5d39dE4Ea42C2Aa6A57EcA2894376683bB8E` | ## mode | Contract | Address | | ------------- | -------------------------------------------- | | ENDPOINT | `0xa18d9690d03Dfbb18ea85588ec5Fd2A914b2aac9` | | MULTISIG | `0xF162b6467Eaf066A513a4B9235009d60c1faCf44` | | REGISTRY | `0x88af5f4bDd601c1bd3674bF1aD2CC282a720D66C` | | TOKEN\_ABTC | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | | TOKEN\_ALEX | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | | TOKEN\_ATALEX | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | | TOKEN\_DB20 | `0x0d3c781313B1d4abbb45459621f0168826A6cF07` | | TOKEN\_DOG | `0xd15B997505739C02564DE7f0E010B42b2F81520d` | | TOKEN\_LISTX | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | | TOKEN\_SUSDT | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | | TOKEN\_WUBTC | `0xd0d1b59CA62cE194E882455Fd36632d6277b192a` | ## sepolia | Contract | Address | | ---------------- | -------------------------------------------- | | ENDPOINT | `0x5210643E105a80322BBcE824B97A3c0B3a9d88F3` | | ENDPOINT\_NATIVE | `0x57b9B488A02bac0F9195fFeE164629b01d03FE4c` | | MULTISIG | `0x715f26cd7a009F3116c93e48DFBeDD1de55Bf829` | | REGISTRY | `0x950cfbC37CE718730baE088031D6699F1AA2C1dc` | | REGISTRY\_NATIVE | `0x19e64AD8aaB0B156b5AEAf24e28f6183c2d82c2F` | | TOKEN\_ABTC | `0xE1a512f9D89fdDcD2105Df4dB32ede4bc2ade33B` | | TOKEN\_ALEX | `0xA1c1f6D111339E26c9Fe61256c4751F539b40bd6` | | TOKEN\_BTC | `0x02111CF82133e29106767DC53ded318281dC84f3` | | TOKEN\_SUSDT | `0x108D36C7F09761cD77c7879710054a85e493835c` | | TOKEN\_USDT | `0x03c69eE62c86c220b5ff71f8212c45a20cA61154` | # Tokens Information ## Table of Contents * [TOKEN\_ABTC](#token_abtc) * [TOKEN\_ALEX](#token_alex) * [TOKEN\_ATALEX](#token_atalex) * [TOKEN\_AVAX](#token_avax) * [TOKEN\_BTC](#token_btc) * [TOKEN\_DB20](#token_db20) * [TOKEN\_DOG](#token_dog) * [TOKEN\_ETH](#token_eth) * [TOKEN\_GHIBLICZ](#token_ghiblicz) * [TOKEN\_LINK](#token_link) * [TOKEN\_LISTX](#token_listx) * [TOKEN\_NXPC](#token_nxpc) * [TOKEN\_PEPE](#token_pepe) * [TOKEN\_SKO](#token_sko) * [TOKEN\_SOL](#token_sol) * [TOKEN\_SPX6900](#token_spx6900) * [TOKEN\_STX](#token_stx) * [TOKEN\_SUSDT](#token_susdt) * [TOKEN\_TBTC](#token_tbtc) * [TOKEN\_TRUMP](#token_trump) * [TOKEN\_UBTC](#token_ubtc) * [TOKEN\_USDC](#token_usdc) * [TOKEN\_USDT](#token_usdt) * [TOKEN\_WUBTC](#token_wubtc) ## TOKEN\_ABTC | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | ------------- | -------------------------------------------- | ---- | ------ | -------- | ---------- | ----------- | -------- | ----- | ------- | | arbitrum | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | aBTC | aBTC | 18 | 0.00000905 | 9.04723562 | true | 0.00% | 0 | | base | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | aBTC | aBTC | 18 | 0.00000929 | 9.28979516 | true | 0.00% | 0 | | bob | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | aBTC | aBTC | 18 | 0.00001039 | 10.39490234 | true | 0.00% | 0 | | bsc | `0x0F38ED043A1A2ec79B15d7F4FB8D25036680ce03` | aBTC | aBTC | 18 | 0.00000905 | 9.05149395 | true | 0.00% | 0 | | bsquared | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | aBTC | aBTC | 18 | 0.0000104 | 10.40387857 | true | 0.00% | 0 | | core | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | aBTC | aBTC | 18 | 0.0000104 | 10.39803685 | true | 0.00% | 0 | | core\_testnet | `0xCa4E6271f3921B5f5A441D3de970c05f9fca200b` | aBTC | aBTC | 18 | 0 | 10000 | true | 0.10% | 0 | | ethereum | `0x31761a152F1e96F966C041291644129144233b0B` | aBTC | aBTC | 18 | 0.00000929 | 9.28867339 | true | 0.00% | 0 | | linea | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | aBTC | aBTC | 18 | 0.0000112 | 11.20460733 | true | 0.00% | 0 | | mode | `0x7A087e75807F2E5143C161a817E64dF6dC5EAFe0` | aBTC | aBTC | 18 | 0.00001041 | 10.40691019 | true | 0.00% | 0 | | sepolia | `0xE1a512f9D89fdDcD2105Df4dB32ede4bc2ade33B` | aBTC | aBTC | 18 | 0 | 10000 | true | 0.10% | 0 | ## TOKEN\_ALEX | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | ------------- | -------------------------------------------- | ---- | ------ | -------- | ------------ | ------------------ | -------- | ----- | ------- | | arbitrum | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | ALEX | ALEX | 18 | 185.16563992 | 185165639.92319328 | true | 0.00% | 0 | | base | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | ALEX | ALEX | 18 | 185.71516123 | 185715161.22861722 | true | 0.00% | 0 | | bob | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | ALEX | ALEX | 18 | 23.78048896 | 23780488.9649019 | true | 0.00% | 0 | | bsc | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | ALEX | ALEX | 18 | 55.45573523 | 55455735.2321377 | true | 0.00% | 0 | | bsquared | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | ALEX | ALEX | 18 | 23.78208381 | 23782083.81472234 | true | 0.00% | 0 | | core | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | ALEX | ALEX | 18 | 23.79170835 | 23791708.35172234 | true | 0.00% | 0 | | core\_testnet | `0x2AcC30125690A2772a1E57A8196D248c4BdccD7b` | ALEX | ALEX | 18 | 0 | 10000 | true | 0.10% | 0 | | ethereum | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | ALEX | ALEX | 18 | 55.29010163 | 55290101.63426483 | true | 0.00% | 0 | | linea | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | ALEX | ALEX | 18 | 27.90268103 | 27902681.02910668 | true | 0.00% | 0 | | mode | `0xdfd0660032c2D0D38a9092a43d1669D6568cAF71` | ALEX | ALEX | 18 | 23.7699073 | 23769907.29736154 | true | 0.00% | 0 | | sepolia | `0xA1c1f6D111339E26c9Fe61256c4751F539b40bd6` | ALEX | ALEX | 18 | 0 | 10000 | true | 0.10% | 0 | ## TOKEN\_ATALEX | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ------- | ------- | -------- | ------------ | ------------------ | -------- | ----- | ------- | | arbitrum | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | vLiALEX | vLiALEX | 18 | 165.46397702 | 165463977.02448028 | true | 0.00% | 0 | | base | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | vLiALEX | vLiALEX | 18 | 165.94455089 | 165944550.88535923 | true | 0.00% | 0 | | bob | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | vLiALEX | vLiALEX | 18 | 22.31510474 | 22315104.73751625 | true | 0.00% | 0 | | bsquared | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | vLiALEX | vLiALEX | 18 | 22.31660131 | 22316601.31064544 | true | 0.00% | 0 | | core | `0x9e801CB9ce84a84a563E5a74Cc2f3Ad55F914072` | vLiALEX | vLiALEX | 18 | 22.32563277 | 22325632.77133248 | true | 0.00% | 0 | | linea | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | vLiALEX | vLiALEX | 18 | 26.14591514 | 26145915.14091856 | true | 0.00% | 0 | | mode | `0xcd5ED0B0b1e107D331833715932B4a596bFbA378` | vLiALEX | vLiALEX | 18 | 22.30517513 | 22305175.12590023 | true | 0.00% | 0 | ## TOKEN\_AVAX | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | ------- | -------------------------------------------- | ------------ | ------ | -------- | ---------- | -------------- | -------- | ----- | ------- | | avax | `0xB31f66AA3C1e785363F0875A1B74E27b85FD66c7` | Wrapped AVAX | WAVAX | 18 | 0.04189359 | 41893.59028069 | false | 0.00% | 0 | ## TOKEN\_BTC | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | ------------- | -------------------------------------------- | -------------------- | ------- | -------- | ---------- | ---------- | -------- | ----- | ------- | | arbitrum | `0x2f2a2543B76A4166549F7aaB2e75Bef0aefC5B0f` | Wrapped BTC | WBTC | 8 | 0.00000905 | 9.04723562 | false | 0.00% | 0 | | avax | `0x152b9d0FdC40C096757F570A51E494bd4b943E50` | Bitcoin | BTC.b | 8 | 0.00000929 | 9.2852235 | false | 0.00% | 0 | | base | `0xcbb7c0000ab88b473b1f5afd9ef808440eed33bf` | Coinbase Wrapped BTC | cbBTC | 8 | 0.00000929 | 9.28979516 | false | 0.00% | 0 | | bsc | `0x7130d2a12b9bcbfae4f2634d864a1ee1ce3ead9c` | BTCB Token | BTCB | 18 | 0.00000905 | 9.05149395 | false | 0.00% | 0 | | core\_testnet | `0x0C4c099D5A00DD01b4543D604751351342B23Bad` | tBTC Non-Burnable | tBTC-NB | 18 | 0 | 100000 | false | 0.25% | 0 | | ethereum | `0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599` | Wrapped BTC | WBTC | 8 | 0.00000929 | 9.28867339 | false | 0.00% | 0 | | sepolia | `0x02111CF82133e29106767DC53ded318281dC84f3` | tBTC Non-Burnable | tBTC-NB | 18 | 0 | 100000 | false | 0.25% | 0 | ## TOKEN\_DB20 | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ---- | ------ | -------- | ------------ | ------------------ | -------- | ----- | ------- | | bob | `0x305A85e892E89Fa0a2bcD92337682d55559a6Ee9` | $B20 | $B20 | 18 | 73.56097906 | 73560979.06098582 | true | 0.00% | 0 | | bsc | `0x305A85e892E89Fa0a2bcD92337682d55559a6Ee9` | $B20 | $B20 | 18 | 187.35367727 | 187353677.27265626 | true | 0.00% | 0 | | bsquared | `0xBAcad57995eb9DF5B151bb30b5Ec6bA1D0A3C560` | $B20 | $B20 | 18 | 73.45859467 | 73458594.67091869 | true | 0.00% | 0 | | core | `0x80074f342764027f5C4e2f7CD7D0DED611Dfb7cD` | $B20 | $B20 | 18 | 73.54520904 | 73545209.0439724 | true | 0.00% | 0 | | ethereum | `0x2AeD35A18Bc02472519Ca6F25b70a8e9fE938430` | $B20 | $B20 | 18 | 186.54967386 | 186549673.86464229 | true | 0.00% | 0 | | linea | `0x24A44C95452df9feC1876f7B907E2dD2Adaa29A7` | $B20 | $B20 | 18 | 85.67594108 | 85675941.08295619 | true | 0.00% | 0 | | mode | `0x0d3c781313B1d4abbb45459621f0168826A6cF07` | $B20 | $B20 | 18 | 73.6163064 | 73616306.40481363 | true | 0.00% | 0 | ## TOKEN\_DOG | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ------------------ | ------ | -------- | ------------ | ------------------ | -------- | ----- | ------- | | bob | `0x916a82E34430804D9B65e0b5aE7D07Ae7439C81D` | DOG•GO•TO•THE•MOON | DOG | 18 | 342.83253604 | 342832536.03584015 | true | 0.00% | 0 | | bsc | `0x916a82E34430804D9B65e0b5aE7D07Ae7439C81D` | DOG•GO•TO•THE•MOON | DOG | 18 | 221.30404648 | 221304046.48000932 | true | 0.00% | 0 | | bsquared | `0xEC72D43EeA62F63E097751bfE9866650689FfcBc` | DOG•GO•TO•THE•MOON | DOG | 18 | 342.35537137 | 342355371.36857694 | true | 0.00% | 0 | | core | `0x3280A4031d7990D1905d7823E7725cb9ad649F37` | DOG•GO•TO•THE•MOON | DOG | 18 | 342.75903953 | 342759039.53001535 | true | 0.00% | 0 | | ethereum | `0x7D4de6105595a5fCac3fbEAED5639624abDd1D9d` | DOG•GO•TO•THE•MOON | DOG | 18 | 225.93014628 | 225930146.28130773 | true | 0.00% | 0 | | linea | `0xce83DD21264323c1D7D246f347Db84A8180970cb` | DOG•GO•TO•THE•MOON | DOG | 18 | 455.9428398 | 455942839.79514575 | true | 0.00% | 0 | | mode | `0xd15B997505739C02564DE7f0E010B42b2F81520d` | DOG•GO•TO•THE•MOON | DOG | 18 | 343.95182724 | 343951827.23805737 | true | 0.00% | 0 | ## TOKEN\_ETH | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | -------------- | ------ | -------- | ---------- | ------------ | -------- | ----- | ------- | | arbitrum | `0x82aF49447D8a07e3bd95BD0d56f35241523fBab1` | Wrapped Ether | WETH | 18 | 0.00055556 | 555.55555556 | false | 0.00% | 0 | | avax | `0x49D5c2BdFfac6CE2BFdB6640F4F80f226bc10bAB` | Wrapped Ether | WETH.e | 18 | 0.00055556 | 555.55555556 | false | 0.00% | 0 | | base | `0x4200000000000000000000000000000000000006` | Wrapped Ether | WETH | 18 | 0.00055556 | 555.55555556 | false | 0.00% | 0 | | bsc | `0x2170Ed0880ac9A755fd29B2688956BD959F933F8` | Ethereum Token | ETH | 18 | 0.00055556 | 555.55555556 | false | 0.00% | 0 | | ethereum | `0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2` | Wrapped Ether | WETH | 18 | 0.00055556 | 555.55555556 | false | 0.00% | 0 | ## TOKEN\_GHIBLICZ | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | ------- | -------------------------------------------- | -------- | ------ | -------- | ------------ | ------------------ | -------- | ----- | ------- | | bsc | `0x795D2710E383F33fbEbe980a155b29757b6703f3` | GhibliCZ | Ghibli | 18 | 128.12299808 | 128122998.07815503 | false | 0.00% | 0 | ## TOKEN\_LINK | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | --------------- | ------ | -------- | ---------- | -------------- | -------- | ----- | ------- | | arbitrum | `0xf97f4df75117a78c1A5a0DBb814Af92458539FB4` | ChainLink Token | LINK | 18 | 0.07993605 | 79936.05115907 | false | 0.00% | 0 | | ethereum | `0x514910771AF9Ca656af840dff83E8264EcF986CA` | ChainLink Token | LINK | 18 | 0.07993605 | 79936.05115907 | false | 0.00% | 0 | ## TOKEN\_LISTX | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ------ | ------ | -------- | ---------- | ---------------- | -------- | ----- | ------- | | arbitrum | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | vLiSTX | vLiSTX | 18 | 1.37352396 | 1373523.96383811 | true | 0.00% | 0 | | base | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | vLiSTX | vLiSTX | 18 | 1.36796085 | 1367960.84705441 | true | 0.00% | 0 | | bob | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | vLiSTX | vLiSTX | 18 | 0.99365401 | 993654.01065988 | true | 0.00% | 0 | | bsquared | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | vLiSTX | vLiSTX | 18 | 0.99227101 | 992271.01302829 | true | 0.00% | 0 | | core | `0xE67640ABD424d9456eF8A4160D5753Fe5833291d` | vLiSTX | vLiSTX | 18 | 0.99344099 | 993440.99091961 | true | 0.00% | 0 | | linea | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | vLiSTX | vLiSTX | 18 | 1.25026228 | 1250262.27980226 | true | 0.00% | 0 | | mode | `0x70727228DB8C7491bF0aD42C180dbf8D95B257e2` | vLiSTX | vLiSTX | 18 | 0.99440137 | 994401.36663306 | true | 0.00% | 0 | ## TOKEN\_NXPC | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | ------- | -------------------------------------------- | ---- | ------ | -------- | ---------- | --------------- | -------- | ----- | ------- | | avax | `0x5E0E90E268BC247Cc850c789A0DB0d5c7621fb59` | NXPC | NXPC | 18 | 0.47619048 | 476190.47619048 | false | 0.00% | 0 | ## TOKEN\_PEPE | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ---- | ------ | -------- | -------------- | ----------------- | -------- | ----- | ------- | | arbitrum | `0x25d887ce7a35172c62febfd67a1856f20faebb00` | Pepe | PEPE | 18 | 72306.57989877 | 72306579898.77078 | false | 0.00% | 0 | | bsc | `0x25d887ce7a35172c62febfd67a1856f20faebb00` | Pepe | PEPE | 18 | 72306.57989877 | 72306579898.77078 | false | 0.00% | 0 | | ethereum | `0x6982508145454ce325ddbe47a25d4ec3d2311933` | Pepe | PEPE | 18 | 72306.57989877 | 72306579898.77078 | false | 0.00% | 0 | ## TOKEN\_SKO | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | ------- | -------------------------------------------- | --------------------- | ------ | -------- | ------------- | ------------------ | -------- | ----- | ------- | | bsc | `0x9Bf543D8460583Ff8a669Aae01d9cDbeE4dEfE3c` | Sugar Kingdom Odyssey | SKO | 18 | 6300.64913794 | 6300649137.9421196 | false | 0.00% | 0 | ## TOKEN\_SOL | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ----------- | ------ | -------- | ---------- | ------------- | -------- | ----- | ------- | | ethereum | `0xD31a59c85aE9D8edEFeC411D448f90841571b89c` | Wrapped SOL | SOL | 9 | 0.00825423 | 8254.23029303 | false | 0.00% | 0 | ## TOKEN\_SPX6900 | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ------- | ------ | -------- | ---------- | --------------- | -------- | ----- | ------- | | ethereum | `0xe0f63a424a4439cbe457d80e4f4b51ad25b2c56c` | SPX6900 | SPX | 8 | 0.87719298 | 877192.98245614 | false | 0.00% | 0 | ## TOKEN\_STX | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ---- | ------ | -------- | ---------- | ---------------- | -------- | ----- | ------- | | ethereum | `0x80074f342764027f5C4e2f7CD7D0DED611Dfb7cD` | STX | STX | 18 | 1.5118415 | 1511841.49853729 | true | 0.00% | 0 | ## TOKEN\_SUSDT | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | ------------- | -------------------------------------------- | ----- | ------ | -------- | ---------- | ---------------- | -------- | ----- | ------- | | arbitrum | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | sUSDT | sUSDT | 18 | 1 | 1000000 | true | 0.00% | 0 | | base | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | sUSDT | sUSDT | 18 | 1 | 1000000 | true | 0.00% | 0 | | bob | `0xf4A6170E827Ba17be9a3423b8662Cc82Eb273730` | sUSDT | sUSDT | 18 | 1.00005 | 1000050.00250012 | true | 0.00% | 0 | | bsc | `0x18c05Ec3799EB15fe49A141ce844e55514438Fa7` | sUSDT | sUSDT | 18 | 1 | 1000000 | true | 0.00% | 0 | | bsquared | `0x0CA7f9247932307c5e4b9Ffed88Ddc057DfAAaCC` | sUSDT | sUSDT | 18 | 1.000044 | 1000044.00193609 | true | 0.00% | 0 | | core | `0xe80e0C533D41343b0038a3eA74102B4b9fF13e7e` | sUSDT | sUSDT | 18 | 1.000033 | 1000033.00108904 | true | 0.00% | 0 | | core\_testnet | `0xa48486cB7eaF9A3B4880A5AC6EF3d26FE973cF02` | USDT | USDT | 18 | 0 | 10000 | false | 0.10% | 0 | | ethereum | `0x73F0f50815CA4698d8e722Cf1D054D223a217138` | sUSDT | sUSDT | 18 | 1 | 1000000 | true | 0.00% | 0 | | linea | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | sUSDT | sUSDT | 18 | 1.00017003 | 1000170.02890491 | true | 0.00% | 0 | | mode | `0xA831a4E181F25D3B35949E582Ff27Cc44e703F37` | sUSDT | sUSDT | 18 | 1.000053 | 1000053.00280915 | true | 0.00% | 0 | | sepolia | `0x108D36C7F09761cD77c7879710054a85e493835c` | USDT | USDT | 18 | 0 | 10000 | false | 0.10% | 0 | ## TOKEN\_TBTC | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ------- | ------ | -------- | ---------- | ---------- | -------- | ----- | ------- | | ethereum | `0x18084fbA666a33d37592fA2633fD49a74DD93a88` | tBTC v2 | tBTC | 18 | 0.00001 | 10 | false | 0.00% | 0 | | mezo | `0x7b7C000000000000000000000000000000000000` | BTC | BTC | 18 | 0.00001 | 10 | false | 0.00% | 0 | ## TOKEN\_TRUMP | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ------------------- | ------ | -------- | ---------- | ---------- | -------- | ----- | ------- | | bsc | `0x5879CdD0a4880D5Dc37C5aa8Ee0d1f319711B231` | THE•REAL•TRUMP•RUNE | TRUMP | 18 | 100 | 1000000 | true | 0.00% | 100 | | ethereum | `0x51CDa809dC64a060F35F6c96EF6927CABc992D94` | THE•REAL•TRUMP•RUNE | TRUMP | 18 | 100 | 1000000 | true | 0.00% | 100 | ## TOKEN\_UBTC | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ---- | ------ | -------- | ---------- | ---------- | -------- | ----- | ------- | | bsquared | `0x796e4D53067FF374B89b2Ac101ce0c1f72ccaAc2` | uBTC | uBTC | 18 | 0.00001 | 10 | false | 0.10% | 0.00001 | ## TOKEN\_USDC | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ---------------- | ------ | -------- | ---------- | ---------- | -------- | ----- | ------- | | arbitrum | `0xaf88d065e77c8cC2239327C5EDb3A432268e5831` | USD Coin | USDC | 6 | 1 | 1000000 | false | 0.00% | 0 | | avax | `0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E` | USD Coin | USDC | 6 | 1 | 1000000 | false | 0.00% | 0 | | base | `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` | USD Coin | USDC | 6 | 1 | 1000000 | false | 0.00% | 0 | | mezo | `0x04671C72Aab5AC02A03c1098314b1BB6B560c197` | Mezo Circle USDC | mUSDC | 6 | 1 | 1000000 | false | 0.00% | 0 | ## TOKEN\_USDT | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | ------------- | -------------------------------------------- | ------------------ | -------- | -------- | ---------- | ---------- | -------- | ----- | ------- | | bsc | `0x55d398326f99059fF775485246999027B3197955` | Tether USD | USDT | 18 | 1 | 1000000 | false | 0.00% | 0 | | core\_testnet | `0xb598aA2F0065081De44A15b0546f85e5DC79E374` | tUSDT Non-Burnable | tUSDT-NB | 18 | 0 | 100000 | false | 0.25% | 0 | | ethereum | `0xdAC17F958D2ee523a2206206994597C13D831ec7` | Tether USD | USDT | 6 | 1 | 1000000 | false | 0.00% | 0 | | mezo | `0xeB5a5d39dE4Ea42C2Aa6A57EcA2894376683bB8E` | Mezo Tether USDT | mUSDT | 6 | 1 | 1000000 | false | 0.00% | 0 | | sepolia | `0x03c69eE62c86c220b5ff71f8212c45a20cA61154` | tUSDT Non-Burnable | tUSDT-NB | 18 | 0 | 100000 | false | 0.25% | 0 | ## TOKEN\_WUBTC | Network | Address | Name | Symbol | Decimals | Min Amount | Max Amount | Burnable | Fee % | Min Fee | | -------- | -------------------------------------------- | ---- | ------ | -------- | ---------- | ----------- | -------- | ----- | ------- | | arbitrum | `0xAB01bbc2EE103d227f2EeE50b230506508b560c5` | uBTC | uBTC | 18 | 0.00000905 | 9.04723562 | true | 0.00% | 0 | | base | `0x9e801CB9ce84a84a563E5a74Cc2f3Ad55F914072` | uBTC | uBTC | 18 | 0.00000929 | 9.28979516 | true | 0.00% | 0 | | bob | `0x2E512BA02454FC48269A9589512239D64602CBC8` | uBTC | uBTC | 18 | 0.00001039 | 10.39490234 | true | 0.00% | 0 | | bsc | `0x2E512BA02454FC48269A9589512239D64602CBC8` | uBTC | uBTC | 18 | 0.00000905 | 9.05149395 | true | 0.00% | 0 | | core | `0xFc57d34855c9944BdBCC0cb3a18B6c7d345DEc8c` | uBTC | uBTC | 18 | 0.0000104 | 10.39803685 | true | 0.00% | 0 | | linea | `0x9e801CB9ce84a84a563E5a74Cc2f3Ad55F914072` | uBTC | uBTC | 18 | 0.0000112 | 11.20460733 | true | 0.00% | 0 | | mode | `0xd0d1b59CA62cE194E882455Fd36632d6277b192a` | uBTC | uBTC | 18 | 0.00001041 | 10.40691019 | true | 0.00% | 0 | # Overview Integration requires a deployment of an endpoint smart contract on the target chain. For the list of currently supported chains, please visit [Brotocol Contract Deployment](https://github.com/Brotocol-xyz/xlink/blob/main/site/documentation/integrations/contract-deployment.md). Below is a typical integration process. ## Endpoint deployment Endpoints are the smart contracts that handle the asset transfers. They are owned by multisig contracts (for example, [Gnosis Safe](https://safe.global/) on Ethereum and [Executor DAO](https://explorer.stacks.co/txid/0xf4bd95ea0486e6a50ae632c613f1d72b2a5bbbc4211b494cd0f1d3443658544d?chain=mainnet) on Stacks) operated by a decentralised network of validators and verifiers. Users use Endpoints to trigger transfer of source assets. The destination assets are then sent by a relayer by producing cryptographic proofs. ## Configuration of endpoint Once the endpoint is deployed, it can be configured to meet the needs of the source chain. The configuration parameters include, among others,: * Approved list of tokens to be supported on the Endpoint, * Approved list of validators whose cryptographic proofs of token transfer event are accepted, * Approved list of relayers who can submit the cryptographic proofs from the validators, * Validator threshold, and * Fee schedule ## Integration with Bonbori Brotocol scales by partnering with [Bonbori](https://docs.alexgo.io/bitcoin-oracle/what-is-the-bitcoin-oracle) which runs the validator and verifier networks of Brotocol. Bonbori produces the consensus data based on the computation from the off-chain engines and provides a consensus model framework that allows the end consumer to customise their consensus model by optimising across the trust and the security budget. The validators of Bonbori observe every Endpoint on the Brotocol and produce a set of cryptographic proofs for the relevant destination chain to process. The relayers then aggregate those cryptographic proofs and submit to the relevant destination Endpoints upon meeting the validator threshold. The submissions by the relayers are verified by the verifiers, which act as the additional protection to the verification by the Endpoint. ## Synthetic asset deployment (optional) Where required, a synthetic asset may be deployed on the destination chains to allow the bridging of the asset from its source chain to the destimation chains. # Add BroWidget Customize and integrate the BroSwap and BroBridge widget for your dApp or website! ## Overview **BroWidget** makes it easy to integrate cross-chain functionality directly into your dApp or website — no complex setup required. It supports two features: * 🌉 **BroBridge**: Supports bridging between Bitcoin (including Runes and BRC20), Stacks, and EVM chains * 🔄 **BroSwap**: Supports swapping within Bitcoin-based assets (BTC, Runes, and BRC20) 💻✨ See the widget in our [**interactive demo**](https://widget-demo.brotocol.xyz/)! ## Integration Integrate the widget by adding two script tags to your HTML: 1. A configuration script 2. The widget loader script ### Examples {% tabs %} {% tab title="Runes" %} {% code lineNumbers="true" %} ```html ``` {% endcode %} Token format: `runes:CHAIN_ID:RUNE_ID:RUNE_NUMBER` {% endtab %} {% tab title="BRC20" %} {% code lineNumbers="true" %} ```html ``` {% endcode %} Token format: `brc20:CHAIN_ID:TOKEN_TICKER` {% endtab %} {% tab title="Stacks" %} {% code lineNumbers="true" %} ```html ``` {% endcode %} Token format: `stacks:CHAIN_ID:CONTRACT_ADDRESS.TOKEN_NAME` {% endtab %} {% tab title="EVM" %} On Ethereum: {% code lineNumbers="true" %} ```html ``` {% endcode %} Token format: `evm:CHAIN_ID:TOKEN_CONTRACT_ADDRESS` For more EVM Chains examples, checkout [here](https://widget-demo.brotocol.xyz/). {% endtab %} {% endtabs %} ## Need Help? For additional support, contact our team on [Discord](https://discord.com/invite/brotocol). # Add a New Chain
Want to bring your chain into the Brotocol ecosystem? Whether you're an L1, L2, or appchain team, integrating with Brotocol opens your users to native Bitcoin liquidity, cross-chain swaps, and secure bridging—all while preserving Bitcoin as the settlement layer. **Here’s how to get started:** *** ### 🧩 Overview To support a new chain, Brotocol deploys a smart contract called an **Endpoint**, which acts as the entry and exit point for cross-chain asset transfers. These Endpoints are governed by multisigs (e.g. Gnosis Safe, ExecutorDAO) and coordinated through the **Bonbori** consensus layer. Once deployed, your Endpoint becomes part of the BroBridge routing network—supporting swaps, payments, and bridging for supported assets. *** ### ✅ Integration Requirements To be eligible for integration, your chain should support: * ✅ Smart contract deployment (EVM-compatible or custom logic) * ✅ Reliable block finality for message validation * ✅ Token standards (ERC-20 or equivalent) for fungible assets * ✅ A relayer-friendly RPC interface for transaction submissions For Bitcoin L2s or non-EVM chains, custom integration paths are available. Reach out to the team for support. *** ### 🔧 Integration Steps #### 1. Contact the Brotocol Team Reach out via Discord or email to start the process. Provide basic info: * Chain name & website * RPC endpoints & explorers * Token assets you want to support * Dev contact for coordination #### 2. Deploy Endpoint Contract Brotocol will deploy an **Endpoint contract** to your chain. This contract: * Receives incoming assets * Validates cryptographic proofs from Bonbori validators * Releases assets to users or contracts Endpoints are owned by a multisig for security and flexibility. #### 3. Configure the Endpoint Once deployed, the following parameters are set: * Approved token list * Validator set & thresholds * Fee structure * Supported swap paths (optional) #### 4. Enable Relayer Support Brotocol relayers will monitor your chain’s Endpoint and submit proofs to/from other chains. #### 5. (Optional) Deploy Synthetic Assets If your chain doesn’t natively support a desired asset (e.g., BTC), a synthetic version (e.g., aBTC or aUSD) may be deployed and mapped to real assets via BroBridge. # Bonbori Consensus Model > **Info:** Looking for more user-focused documentation? Visit [What is Bonbori](https://docs.brotocol.xyz/overview/bonbori) in the User Docs. ## Cross-chain messaging and consensus layer for all and any off-chain computation engines Bonbori is a cross-chain messaging and consensus layer for all and any off-chain computation engines that builds on Bitcoin. Bonbori provides infrastructure that * allows two or more off-chain computation engines on Bitcoin to exchange messages, and * provides the consensus model to validate such cross-chain messages. The consensus is deemed to have reached when a minimum threshold (i.e. "*m-of-n*") of the relevant community agree to a particular event. End consumers can then verify the consensus before making a decision or taking an action with respect to that particular event, thus enhancing the security assumptions. For example, Bonbori secures [Brotocol](#example-brotocol). When Brotocol identifies a particular cross-chain transfer to process, it pulls the relevant consensus data from Bonbori, verify them using its smart contract before processing them on the relevant destination chain. ## Flexible threshold-based consensus model Using the "on-demand" consensus data, dapps and other end consumers of such data can reach the consensus based on a minimum threshold (i.e. "*m-of-n*") of the relevant community agree to a particular event. Bonbori provides a consensus model framework that allows the end consumer to customise their consensus model by optimising across the trust and the security budget. Each end consumer may specify a number of required (i.e. trusted) and optional (i.e. non-trusted) validators as its consensus model. For example, for each event to validate, the end consumer may specify that the required validators must agree and a certain threshold (say 51%) of all validators (including required and optional) must agree. A fast derivation of consensus is achieved through [Threshold Sampling](#threshold-sampling) among nodes. Some may choose to have only required validators, in which case, effectively, a federated concensus model is run. In this case, a trust element is introduced to eliminate the security budget constraint. Some others may choose to have only optional validators, but with staking/slashing mechanism. In this case, the security budget enabled by the staking/slashing mechanism means the consensus model can be run trustlessly. ### Threshold Sampling Threshold sampling allows Bonbori to derive consensus from the network of nodes without having to download all the consensus data from its data layer. Bonbori engages in several rounds of random sampling for subset of the network and, with each successful round, consensus confidence grows. When Bonbori achieves a set confidence threshold, an event is deemed to have reached consensus, subject to validation by all trusted nodes. ## Example - Brotocol [Brotocol](https://brotocol.xyz) is a key component of any projects building on Bitcoin that abstracts the difference between L1 and L2 from the user experience, i.e. providing the "native-like” Bitcoin DeFi experience on L1, whereby users can use native BTC or L1 assets issued on Bitcoin to interact with L2 smart contracts. Brotocol is bi-directional or “two-way” bridge, meaning you can freely transfer assets between Bitcoin and its L2s and vice versa. Brotocol incorporates a mixture of required and optional validators to secure its infrastructure, where the consensus (100% threshold) of the required validators must be met to validate the consensus (51% threshold) reached by all the validators.

Bonbori secures Brotocol

This model brings the following benefits: * It lowers the barrier to entry to join the validator network, encouraging more members of its community to participate in securing the Brotocol infrastructure. * Security budget is replaced with a set of trusted validators, which essentially acts as the secondary check against the consensus derived from the network. * Larger part of the incentives can be allocated to encouraging the community to join and actively participate in securing the network. * Smaller part of the incentives needs to be alloacted to the "insurance" fund. * 51% threshold and the lower barrier to entry to join the network means it is expensive for the required validators to take over the validator network. * Likewise, malicious actors cannot take over the validator network even if they own all optional validators (which is very unlikely) unless they also take over every required validator. # Overview Brotocol's core on-chain functionalities are implemented through a set of smart contracts deployed on Stacks and EVM-compatible networks (see complete list of EVM chains [here](/developers/deployments/chains/evm/ethereum-contract-addresses)). Their primary function is to provide a bridging mechanism, allowing the movement of assets between Bitcoin and other DeFi blockchain ecosystems. Additional features include Bitcoin swaps, cross-chain liquidity aggregation, integration of staking protocols and the Brotocol Governance System. The subsections below describe the purpose, scope and interactions of the Brotocol contracts. Each subsection provides a detailed overview of each smart contract and its main variables, features, error codes and events. ## Chains {% content-ref url="/pages/8Fa7T509jq5mqNYBWEct" %} [Stacks](/developers/brotocol-contracts/chains/stacks) {% endcontent-ref %} {% content-ref url="/pages/WrVUBRpUgwblfhTBLzaU" %} [EVM](/developers/brotocol-contracts/chains/evm) {% endcontent-ref %} # Chains # Stacks ## Introduction This document provides a technical overview of Brotocol's bridge built with Clarity smart contracts on the Stacks blockchain. The system enables secure cross-chain asset transfers through three core bridging mechanisms: * **Bitcoin Bridge**: Transfers BTC between the Bitcoin blockchain and the Stacks chain. BTC bridged to Stacks is represented as aBTC (bridged BTC), maintaining a 1:1 peg with native Bitcoin. * **Meta Bridge**: Transfers BRC-20 and Runes-compliant assets between the Bitcoin chain and the Stacks chain, converting them to SIP-010 compliant tokens. * **Cross Bridge**: Enables transfers between Stacks and other Brotocol supported networks, allowing interoperability with EVM-compatible blockchains. Each bridging pathway uses specialized endpoint contracts for handling incoming transactions (peg-in) and outgoing transactions (peg-out), with [supporting contracts](#auxiliary-contracts) (such as registries) to ensure security and proper transaction validation. ### Bitcoin Bridge (Bitcoin's BTC <-> Stacks' aBTC) ![This is a simplified representation on the BTC Bridge main goal.](/files/LUGYyu4olIOo9pU6X0gN) \*To see more information on registry contract see the [auxiliary contracts section](#auxiliary-contracts). #### BTC Peg-In Endpoints * Contract names: `btc-peg-in-endpoint-v2-05`, `btc-peg-in-endpoint-v2-05-lisa`, `btc-peg-in-v2-05-launchpad`, `btc-peg-in-v2-07-swap`, `btc-peg-in-v2-07a-agg`. * [Complete technical documentation](/developers/brotocol-contracts/chains/stacks/btc-peg-in-endpoint) Responsible for managing the bridging of BTC from Bitcoin chain into Stacks chain as bridged BTC (aBTC). #### BTC Peg-Out Endpoint * Contract name: `btc-peg-out-endpoint-v2-01` * [Complete technical documentation](/developers/brotocol-contracts/chains/stacks/btc-peg-out-endpoint) Responsible for managing the bridging of Stacks' aBTC back to the Bitcoin blockchain as native BTC. ### Meta Bridge (Bitcoin's BRC-20 <-> Stacks' SIP-010) ![This is a simplified representation on the Meta Bridge main goal.](/files/HEw27Ge17ZZIcwtZyg0N) \*To see more information on these contracts see the [auxiliary contracts section](#auxiliary-contracts). #### Meta Peg-In Endpoints * Contract names: `meta-peg-in-endpoint-v2-04`, `meta-peg-in-endpoint-v2-04-lisa`, `meta-peg-in-v2-06-swap`. * [Complete technical documentation](/developers/brotocol-contracts/chains/stacks/meta-peg-in-endpoint) Responsible for the bridging of assets that comply with the BRC-20 and Runes standards (on Bitcoin chain) into the corresponding tokens on the Stacks blockchain, complying with the Stacks `SIP-010` fungible token standard. #### Meta Peg-Out Endpoint * Contract name: `meta-peg-out-endpoint-v2-04` * [Complete technical documentation](/developers/brotocol-contracts/chains/stacks/meta-peg-out-endpoint) Manages the bridging of tokens from the Stacks chain back to the Bitcoin blockchain, where they are converted into BRC-20 or Runes compliant assets. ### Cross Bridge (EVM Chains' Tokens <-> Stacks' SIP-010) ![This is a simplified representation on the Cross Bridge main goal.](/files/N8G8ui3bF7ZvPQ08kEfR) \*To see more information on these contracts see the [auxiliary contracts section](#auxiliary-contracts). #### Cross Peg-In Endpoints * Contract names: `cross-peg-in-endpoint-v2-04`, `cross-peg-in-v2-04-launchpad`, `cross-peg-in-v2-04-swap`. * [Complete technical documentation](/developers/brotocol-contracts/chains/stacks/cross-peg-in-endpoint) Responsible for managing the transfer of assets from other EVM-like blockchains into the Stacks chain, where they are represented as `SIP-010` tokens. #### Cross Peg-Out Endpoint * Contract names: `cross-peg-out-endpoint-v2-01`, `cross-peg-out-v2-01-agg`. * [Complete technical documentation](/developers/brotocol-contracts/chains/stacks/cross-peg-out-endpoint) Responsible for managing the transfer of `SIP-010` tokens from the Stacks network to other supported networks (mostly EVM-like blockchains). ### Auxiliary Contracts These contracts do not include the implementation of any core functionality but they serve as a support for other contracts to facilitate calculations and common storage management. * **BTC Bridge Registry**: when a user wants to bridge BTC from Bitcoin chain into Stacks' aBTC or the other way around, this contract keeps record of the generated orders and their statuses, allowing those who interact with it to consult a bridging operation validity and update the records as well. Its current version can be found at `btc-bridge-registry`. * **Meta Bridge Registry**: this registry contains information about the approved tokens for bridging. It allows other modules to validate whether the BRC-20 token can be bridged into Stacks. The last version in use can be found at `meta-bridge` file. * **Cross Bridge Registry**: this registry allows other contracts to validate, among other things, if a specific token (from an EVM-like chain) can be bridged into Stacks. It also keeps record of the created bridging orders and their statuses. The current used version can be found at `cross-bridge-registry` file. * **Cross Router**: this contract is used to verify that a route between two tokens that gives as an output at least the expected minimum amount when swapping exists. It can, certainly, include intermediate exchanges to reach the desired token, meaning that if a user wants to swap token A to obtain token C, there may be some intermediate swaps needed such as `token A -> token B -> token C`(this is related to the existence or not of pools that includes the tokens of interest). It interacts with the `amm-pool-v2-01` contract to perform the swaps. Currently, it can be found at `cross-router` file. * **Bridge Common**: this contract provides common helper functions to all the others. These auxiliary functions facilitate order creation, transaction decoding, and cross-chain routing validations. Its implementation can be found at `bridge-common` file. * **Clarity Bitcoin**: this contract contains auxiliary functions that allows its users to interpret Bitcoin transactions and their content from a buffer. It can be found at `clarity-bitcoin` file. ## Governance At the top of the on-chain architecture is the Brotocol DAO, accounting for Brotocol's governance in a rule-based, modular and flexible manner. Built upon Marvin Janssen's ExecutorDAO project, it operates based on the following core principles: * Proposals are smart contracts. * The core executes, the extensions give form. * Ownership control happens via sending context. For technical details on the ExecutorDAO, refer to the project's [README.md](https://github.com/MarvinJanssen/executor-dao#readme). ## Brotocol Staking Brotocol also offers users the possibility to stake their tokens. To see detailed information on how the staking protocol works refer to the [Brotocol Staking Manager](/developers/brotocol-contracts/chains/stacks/xlink-staking) contract. # BTC Peg-In Endpoints * Location: `./packages/contracts/bridge-stacks/contracts` * Deployed contracts: [btc-peg-in-endpoint-v2-05](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.btc-peg-in-endpoint-v2-05?chain=mainnet), [btc-peg-in-endpoint-v2-05-lisa](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.btc-peg-in-endpoint-v2-05-lisa?chain=mainnet), [btc-peg-in-v2-05-launchpad](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.btc-peg-in-v2-05-launchpad?chain=mainnet), [btc-peg-in-v2-07-swap](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.btc-peg-in-v2-07-swap?chain=mainnet), [btc-peg-in-v2-07a-agg](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.btc-peg-in-v2-07a-agg?chain=mainnet) This technical document provides a detailed overview of the contracts responsible for managing the peg-in process, enabling the transfer of BTC from the Bitcoin network to the Stacks network. In this process, BTC is represented as bridged tokens on Stacks (aBTC). The module's core functionality is implemented through a series of public functions distributed across five specialized contracts. Each contract addresses specific aspects of the BTC peg-in process. This functionality is implemented and distributed across the following contracts: * `btc-peg-in-endpoint-v2-05`: handles bridging BTC into the Stacks network, leveraging cross-router to manage the routing of BTC to the appropriate destination. * `btc-peg-in-endpoint-v2-05-lisa`: extends Bitcoin peg-in operations by converting BTC into LiaBTC through intermediate bridging steps, ultimately enabling the issuance of BRC-20 tokens on Bitcoin. * `btc-peg-in-v2-05-launchpad`: facilitates BTC peg-ins specifically for participation in launchpad projects on Stacks. * `btc-peg-in-v2-07-swap`: enables the bridging of BTC into the Stacks network while enabling token swaps to convert BTC into other predefined assets during the process. * `btc-peg-in-v2-07a-agg`: facillitates the BTC peg-in process for swaps with non-ALEX liquidity aggregators. Liquidity aggregators optimize token exchanges by accessing multiple liquidity sources. This allows ALEX to execute swaps even when there are no ALEX pools for a specific token pair. ## Storage *All contracts include the following variables unless otherwise specified.* ### `fee-to-address` | Data | Type | | -------- | ----------- | | Variable | `principal` | The address where the fees collected from peg-in operations are transferred. By default, this address is set to the executor-dao responsible for governance. ### `peg-in-paused` | Data | Type | | -------- | ------ | | Variable | `bool` | A flag that indicates whether the peg-in process is paused. If set to `true`, all peg-in operations are suspended, preventing any new transactions. The contract is deployed in a paused state by default. ### `peg-in-fee` | Data | Type | | -------- | ------ | | Variable | `uint` | The percentage fee charged for peg-in transactions. By default, this value is `0`. ### `peg-in-min-fee` | Data | Type | | -------- | ------ | | Variable | `uint` | The minimum fee required for a peg-in transaction, regardless of the transaction amount. For each transaction, the fee is the maximum value between the calculated fee amount and the `peg-in-min-fee`. By default, this value is `0`. ### `btc-peg-outfee` *Only present in `btc-peg-in-v2-07-swap` and `btc-peg-in-v2-07a-agg`.* | Data | Type | | -------- | ------ | | Variable | `uint` | This variable represents the percentage fee applied to BTC peg-out operations during cross-swap transactions, where BTC is swapped and routed across chains to reach the final recipient. By default, it is initialized to `0` and can be updated via governance functions. ### `btc-peg-out-min-fee` *Only present in `btc-peg-in-v2-07-swap` and `btc-peg-in-v2-07a-agg`.* | Data | Type | | -------- | ------ | | Variable | `uint` | This variable sets the minimum fee required for BTC peg-out operations during cross-swap transactions. By default, it is initialized to `0`. ## Features #### `finalize-peg-in-cross` *In `btc-peg-in-endpoint-v2-05` contract.* This function manages the peg-in process for transferring BTC to Stacks with support for cross-chain routing. It validates the provided Bitcoin transaction (which represents the transfer of BTC to a peg-in address on the Bitcoin network), ensuring it has been mined and meets the necessary conditions including an approved peg-in address. The function also performs additional checks involving a "reveal transaction," which specifies the token and chain-id for the destination chain. Once the transaction is validated, the function calculates fees, verifies that the asset being transferred is approved for bridging operations in the `.btc-bridge-registry-v2-01` contract, and registers the transaction status. Once validated, the function mints bridged BTC tokens and sends them to the recipient specified in the transaction details via the `.cross-router-v2-03`. If the validation or routing fails, a refund is executed. **Parameters** ```lisp (tx (buff 32768)) (block { header: (buff 80), height: uint }) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (output-idx uint) (reveal-tx { tx: (buff 32768), order-idx: uint }) (reveal-block { header: (buff 80), height: uint }) (reveal-proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (token-out-trait ) ``` #### `finalize-peg-in-cross-swap` *In `btc-peg-in-v2-07-swap` contract.* This function mints bridged BTC tokens and swaps them according to routing instructions. Building upon the functionality of `finalize-peg-in-cross`, it adds token swapping capabilities during the peg-in process. In addition to the verifications performed in `finalize-peg-in-cross`, it ensures that routing configurations (e.g., minimum output amounts or token paths) are valid and meet the required conditions. During the process, the function temporarily modifies the `peg-out-fee` and `peg-out-min-fee` values within the `btc-peg-out-endpoint-v2-01` contract. These adjustments allow the transaction to apply specific fee values during the routing and swap operations. Once the process is completed, the original values are restored. It interacts with `.btc-bridge-registry-v2-01` contract to register transaction statuses. It also uses the `.cross-router-v2-03` to handle the cross operation and to perform token swaps through the `.amm-pool-v2-01` contract. The function mints bridged BTC tokens and swaps them according to routing instructions. **Parameters** ```lisp (tx (buff 32768)) (block { header: (buff 80), height: uint }) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (output-idx uint) (reveal-tx { tx: (buff 32768), order-idx: uint }) (routing-traits (list 5 )) (token-out-trait ) ``` #### `finalize-peg-in-mint-liabtc` *In `btc-peg-in-endpoint-v2-05-lisa` contract.* The main purpose of this function is to convert BTC into LiaBTC, with the ultimate goal of issuing it as a BRC-20 token in Bitcoin. To achieve this, the function goes through an intermediate bridging step: after locking the desired amount of BTC on the Bitcoin network, it converts it into aBTC within the Stacks ecosystem. The aBTC is then wrapped into `wvLiaBTC`, a tokenized form of LiaBTC within Stacks. Once the conversion is complete, the function initiates a peg-out operation using the `.meta-peg-out-endpoint-v2-04` contract. This step bridges the `wvLiaBTC` back to Bitcoin and issues it as BRC-20 tokens, sending it to a specific inscription address provided in the order. The function verifies both the validation of the Bitcoin transaction and the fulfillment of all LiaBTC minting conditions. It also registers the peg-in transaction in the `.btc-bridge-registry-v2-01` contract. In case of any error, the refund mechanism is triggered to return the corresponding funds to the sender. **Parameters** ```lisp (tx (buff 32768)) (block { header: (buff 80), height: uint }) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (output-idx uint) (order-idx uint) (message { token: principal, accrued-rewards: uint, update-block: uint }) (signature-packs (list 100 { signer: principal, message-hash: (buff 32), signature: (buff 65) })) ``` ### `finalize-peg-in-launchpad` *In `btc-peg-in-v2-05-launchpad` contract.* This function is tailored for peg-ins associated with launchpad projects on Stacks. It uses `.btc-bridge-registry-v2-01` to validate and register transaction details while ensuring compatibility with the project’s parameters. These parameters include fields such as `user`, `launch-id`, and `payment-token-trait`, which define the specifics of the launchpad operation. The function first mints bridged BTC tokens for the user and then registers the operation in the `.alex-launchpad-v2-03` contract. This registration involves transferring the minted bridged tokens assets to the launchpad contract on behalf of the user, where they are associated with the launchpad project. In case of any error, it invokes the internal [refund](#relevant-internal-functions) function and logs the issue. **Parameters** ```lisp (tx (buff 32768)) (block { header: (buff 80), height: uint }) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (output-idx uint) (order-idx uint) ``` ### `finalize-peg-in-agg` *In `btc-peg-in-v2-07a-agg` contract.* This function facilitates a BTC peg-in operation designed for aggregated cross-chain routing. Unlike standard peg-in processes where users receive aBTC directly on Stacks, this function integrates a routing mechanism that forwards the bridged tokens for immediate cross-chain processing. The process begins by verifying that the provided Bitcoin transaction has been mined and meets all peg-in validation criteria. It checks that the peg-in address is approved and calculates the required transaction fees. Once validated, the function mints aBTC for the net amount (after deducting fees) and registers the peg-in transaction in the `.btc-bridge-registry-v2-01` contract. Instead of keeping the minted aBTC within the Stacks ecosystem, this function directly transfers it to the `.cross-peg-out-v2-01-agg` contract. This interaction enables automated routing and potential asset swaps to facilitate seamless movement of assets across blockchains. The function logs transaction details and ensures that any failure in the process triggers a refund mechanism. **Parameters** ```lisp (tx (buff 32768)) (block { header: (buff 80), height: uint }) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (output-idx uint) (reveal-tx { tx: (buff 32768), order-idx: uint }) (reveal-block { header: (buff 80), height: uint }) (reveal-proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) ``` ### Governance features #### `is-dao-or-extension` This standard protocol function checks whether a caller (`tx-sender`) is the DAO executor or an authorized extension, delegating the extensions check to the `executor-dao` contract. #### `is-peg-in-paused` A read-only function that checks the operational status of the contract. #### `pause-peg-in` A public function, governed through the `is-dao-or-extension`, that can change the contract's operational status. **Parameters** ```lisp (paused bool) ``` #### `set-fee-to-address` This feature establishes the address to which the fees collected from peg-in operations are transferred. **Parameters** ```lisp (new-fee-to-address principal) ``` #### `set-peg-in-fee` This feature sets the fee for the peg-in operation as a percentage of the transaction amount. **Parameters** ```lisp (fee uint) ``` #### `set-peg-in-min-fee` This feature allows to set the minimum fee required for a peg-in transaction. **Parameters** ```lisp (fee uint) ``` #### `set-btc-peg-out-fee` ***(only present in btc-peg-in-v2-07-swap and btc-peg-in-v2-07a-agg)*** This feature sets the percentage fee applied to BTC peg-out operations. **Parameters** ```lisp (fee uint) ``` #### `set-btc-peg-out-min-fee` ***(only present in btc-peg-in-v2-07-swap and btc-peg-in-v2-07a-agg)*** This feature establishes the minimum fee required for BTC peg-out operations. **Parameters** ```lisp (fee uint) ``` ### Supporting features The following functions are tools to assist the off-chain activities. 1. Construct and destruct helpers (`destruct-principal`, `construct-principal`). 2. Order creation helpers (`create-order-cross-or-fail`, `create-order-cross-swap-or-fail`, `create-order-mint-liabtc-or-fail`, `create-order-launchpad-or-fail`, `create-order-agg-or-fail`). 3. Decoding helpers (`decode-order-cross-from-reveal-tx-or-fail`, `decode-order-cross-swap-from-reveal-tx-or-fail`, `decode-order-agg-or-fail`, `decode-order-agg-from-reveal-tx-or-fail`). ### Relevant internal functions * `refund`: this function returns the total amount of the peg-in transaction, including the fee, to the sender in case of a failure during the operation. ### Getters #### `get-peg-in-fee` #### `get-peg-in-min-fee` #### `get-fee-to-address` #### `get-peg-in-sent-or-default` **Parameters** ```lisp (tx (buff 32768)) (output uint) ``` #### `get-txid` **Parameters** ```lisp (tx (buff 32768)) ``` #### `get-btc-peg-out-fee` *(only present in btc-peg-in-v2-07-swap and btc-peg-in-v2-07a-agg)* #### `get-btc-peg-out-min-fee` *(only present in btc-peg-in-v2-07-swap and btc-peg-in-v2-07a-agg)* #### `get-liabtc-decimals` *(only present in btc-peg-in-endpoint-v2-05-lisa)* ## Contract calls (interactions) * `executor-dao`: calls are made to verify whether a certain contract-caller is designated as an extension. * `btc-bridge-registry-v2-01`: this contract is called to validate peg-in addresses, check and set transaction statuses, and order details during peg-in operations. * `bridge-common-v2-02`: this contract is called to extract and validate Bitcoin transaction details, decode routing and order information during peg-in operations. * `token-abtc`: this contract handles the management of aBTC (Bridged BTC) tokens, representing BTC on the Stacks network. It is called to mint and transfer aBTC during peg-in operations. * `cross-router-v2-03`: this contract is called to route tokens and execute cross-chain transfers during advanced peg-in operations, such as cross and cross-swap transactions. * `alex-launchpad-v2-03`: this contract is called to register and validate peg-in operations associated with launchpad projects on the Stacks network. * `clarity-bitcoin-v1-07`: this contract is called to retrieve the transaction ID of native SegWit Bitcoin transactions by excluding witness data. * `btc-peg-out-endpoint-v2-01`: this contract is called to manage refunds during peg-in failures to transfer BTC back to users. * `liabtc-mint-endpoint`: this contract is called to validate and mint liabtc during peg-in operations. * `token-wvliabtc`: this contract handles the management of wvliabtc tokens, the wrapped representation of liabtc on the Stacks network. It is called to mint and manage wvliabtc during peg-in operations. * `meta-peg-out-endpoint-v2-04`: this contract is called to bridge wvLiaBTC from the Stacks network to Bitcoin as a BRC-20 token, transferring it to a specified address. * `cross-peg-out-v2-01-agg`: this contract is called to finalize the transaction by preparing the swap to be executed in an EVM-compatible blockchain. ## Errors | Error Name | Value | | ------------------------------ | ------------- | | `err-unauthorised` | `(err u1000)` | | `err-paused` | `(err u1001)` | | `err-peg-in-address-not-found` | `(err u1002)` | | `err-invalid-amount` | `(err u1003)` | | `err-invalid-tx` | `(err u1004)` | | `err-already-sent` | `(err u1005)` | | `err-bitcoin-tx-not-mined` | `(err u1011)` | | `err-invalid-input` | `(err u1012)` | | `err-token-mismatch` | `(err u1015)` | | `err-slippage` | `(err u1016)` | | `err-not-in-whitelist` | `(err u1017)` | | `err-invalid-routing` | `(err u1018)` | | `err-commit-tx-mismatch` | `(err u1019)` | | `err-invalid-token` | `(err u1020)` | # BTC Peg-Out Endpoints * Location: `./packages/contracts/bridge-stacks/contracts/btc-peg-out-endpoint-v2-01.clar` * [Deployed contract](https://explorer.hiro.so/txid/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.btc-peg-out-endpoint-v2-01?chain=mainnet) This technical document provides a detailed overview of the contract responsible for managing the peg-out process, enabling the transfer of bridged BTC from the Stacks network back to the Bitcoin network. In this process, aBTC (Bridged BTC tokens on Stacks) is burned or transferred, depending on the context, and BTC is released to a specified Bitcoin address. The contract's primary functionality is implemented through a series of public functions. Let's review this core operation. ## Storage ### `fee-to-address` | Data | Type | | -------- | ----------- | | Variable | `principal` | The address where the fees collected from peg-out operations are transferred. By default, the address assigned to receive these fees is the `tx-sender` address of the contract deployer. ### `peg-out-paused` | Data | Type | | -------- | ------ | | Variable | `bool` | A flag that indicates whether the peg-out process is active. If set to true, all peg-out operations are paused, preventing any new transactions. The contract is deployed in a paused state by default. ### `peg-out-fee` | Data | Type | | -------- | ------ | | Variable | `uint` | The percentage fee charged for peg-out transactions. The fee is represented in a fixed-point format with 6 decimal places. This means that 100% is represented as `u100000000`and 1% is represented as `u1000000`. By default, this value is `u0`. ### `peg-out-min-fee` | Data | Type | | -------- | ------ | | Variable | `uint` | The minimum fee required for a peg-out transaction, regardless of the transaction amount. By default, this value is `u0`. ## Features #### `request-peg-out-0` *In `btc-peg-out-endpoint-v2-01` contract.* This function initiates the peg-out process, enabling users to transfer bridged BTC from the Stacks network to a specified Bitcoin address (peg-out-address). First, it validates the requested amount using `validate-peg-out-0` to ensure it meets the minimum requirements (the requested amount must be sufficient to cover both the peg-out fee and the gas fee, leaving a positive net amount available for transfer). The function registers the request by interacting with the `.btc-bridge-registry-v2-01` contract, storing details such as the requesting user, target Bitcoin address, calculated fees, and associated block heights (e.g., `block-height` and `burn-block-height`). A unique request ID is generated for tracking. Finally, the amount of aBTC is escrowed by transferring it from the user to the contract, securing the funds until the request is either completed or revoked. **Parameters** ```lisp (peg-out-address (buff 128)) (amount uint) ``` #### `claim-peg-out` *In `btc-peg-out-endpoint-v2-01` contract.* This function allows a user to claim a specific peg-out request. The function first retrieves the request details and performs several validations to check that the request is active and valid. It checks that the peg-out process is not paused, the request has not been finalized, revoked, or already claimed, and that all conditions for claiming are met. Upon successful validation, the function registers the request as claimed in the `.btc-bridge-registry-v2-01` contract, updating the state with the claimer's identity, the Bitcoin address (`fulfilled-by`) responsible for completing the transaction, and the block height defining the claim's expiration period. Note that the expiration period defines a specific timeframe during which the claimed request must be finalized. And finally, the updated request details are logged, and the claimer is granted the right to proceed with finalizing the peg-out. **Parameters** ```lisp (request-id uint) (fulfilled-by (buff 128)) ``` #### `finalize-peg-out` *In `btc-peg-out-endpoint-v2-01` contract.* This function completes the peg-out process. It performs checks to finalize the peg-out, including verifying that the transaction has been mined, and verifies that the included details in the transaction (concerning the amount, recipient address, and fulfiller address) align with the request specifications. The function interacts with the `.btc-bridge-registry-v2-01` contract to mark the request as finalized. Additionally, the function processes fees by transferring them to the designated governance address. It then handles the bridged tokens (aBTC) associated with the request in one of two ways: 1. Approved Peg-in Address: * The tokens are burned, reducing the total supply. 2. Third-Party Address: * The tokens are transferred from the contract to the claimer, maintaining the total supply. Once all operations are completed, the function logs the transaction details and confirms the successful finalization of the request. **Parameters** ```lisp (request-id uint) (tx (buff 32768)) (block { header: (buff 80), height: uint }) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (output-idx uint) (fulfilled-by-idx uint) ``` #### `revoke-peg-out` *In `btc-peg-out-endpoint-v2-01` contract.* This function allows the user who created a peg-out request to cancel it, only if certain conditions are met. The function checks that the required `request-revoke-grace-period` has passed since the request was created, and verifies that the request has not already been claimed, finalized, or already revoked. Once these validations are passed, the function updates the request's status to "revoked" in the `.btc-bridge-registry-v2-01` contract. It then processes the refund by transferring the associated fees and the bridged tokens (aBTC) back to the requester. **Parameters** ```lisp (request-id uint) ``` ### Governance features #### `is-dao-or-extension` This standard protocol function checks whether a caller (`tx-sender`) is the DAO executor or an authorized extension, delegating the extensions check to the `executor-dao` contract. #### `is-peg-out-paused` A read-only function that checks the operational status of the contract. #### `pause-peg-out` A public function, governed through the `is-dao-or-extension`, that can change the contract's operational status. **Parameters** ```lisp (paused bool) ``` ### Getters #### `get-peg-out-fee` #### `get-peg-out-min-fee` #### `get-request-revoke-grace-period` #### `get-request-claim-grace-period` #### `get-request-or-fail` **Parameters** ```lisp (request-id uint) ``` #### `get-peg-in-sent-or-default` **Parameters** ```lisp (tx (buff 32768)) (output uint) ``` #### `get-fee-to-address` #### `get-txid` **Parameters** ```lisp (tx (buff 32768)) ``` ## Contract calls (interactions) * `executor-dao`: Calls are made to verify whether a certain contract-caller is designated as an extension. * `btc-bridge-registry-v2-01`: This contract is called to register, update, and track peg-out requests. * `clarity-bitcoin-v1-07`: This contract is called to validate Bitcoin transactions by verifying that they have been mined and extracting relevant transaction details, such as inputs, outputs, and script data. * `token-abtc`: This contract represents the aBTC token on the Stacks network. It is directly responsible for managing the transfer, burning, and refunding of aBTC tokens during the peg-out process. ## Errors | Error Name | Value | | ------------------------------- | ------------- | | `err-unauthorised` | `(err u1000)` | | `err-paused` | `(err u1001)` | | `err-invalid-amount` | `(err u1003)` | | `err-invalid-tx` | `(err u1004)` | | `err-already-sent` | `(err u1005)` | | `err-address-mismatch` | `(err u1006)` | | `err-request-already-revoked` | `(err u1007)` | | `err-request-already-finalized` | `(err u1008)` | | `err-revoke-grace-period` | `(err u1009)` | | `err-request-already-claimed` | `(err u1010)` | | `err-bitcoin-tx-not-mined` | `(err u1011)` | | `err-tx-mined-before-request` | `(err u1013)` | | `err-slippage` | `(err u1016)` | # Meta Peg-In Endpoints * Location: `./packages/contracts/bridge-stacks/contracts/` * Deployed contracts: [meta-peg-in-endpoint-v2-04](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.meta-peg-in-endpoint-v2-04?chain=mainnet), [meta-peg-in-endpoint-v2-04-lisa](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.meta-peg-in-endpoint-v2-04-lisa?chain=mainnet), [meta-peg-in-v2-06-swap](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.meta-peg-in-v2-06-swap?chain=mainnet). This technical document provides a comprehensive overview on the module responsible for the peg-in (bridging) of Bitcoin's BRC-20 assets to the Stacks network. BRC-20 is a token standard on Bitcoin's metaprotocol layer, enabling fungible assets similar to Ethereum's ERC-20. The module's core functionality is implemented through a series of public functions distributed across multiple specialized contracts, each addressing specific aspects of the peg-in process. This functionality is implemented and distributed across the following contracts: * `meta-peg-in-endpoint-v2-04`: facilitates the bridging of BRC-20 tokens from Bitcoin to Stacks, leveraging cross-router for routing to the appropriate destination. * `meta-peg-in-endpoint-v2-04-lisa`: facilitates peg-in operations for BRC-20 tokens from Bitcoin that involve burning LiaBTC tokens within the ALEX system. * `meta-peg-in-v2-06-swap`: facilitates peg-in operations for BRC-20 tokens from Bitcoin to Stacks with integrated asset swapping capabilities. ## Storage *All contracts include the following variables unless otherwise specified.* ### `paused` | Data | Type | | -------- | ------ | | Variable | `bool` | This data variable serves as a flag to control the operational status of the contract. When set to `true`, all meta peg-in transactions are suspended. By default, the contract is deployed in *paused* mode. Refer to the [pause](#pause) governance feature to know more on how to change this status. ### `fee-to-address` | Data | Type | | -------- | ----------- | | Variable | `principal` | This is the address where fees, charged in Bridged BTC tokens (token-abtc), are sent. By default, this address is the `tx-sender` who deployed the contract. ### `peg-in-fee` | Data | Type | | -------- | ------ | | Variable | `uint` | This value represents the fee required for peg-in operations, expressed in fixed BTC (Bitcoin's base unit: satoshis). Fee amounts below this limit will be rejected with the error `err-invalid-amount`. By default, this value is set to `0`. ### `btc-peg-out-fee` *Only present in `meta-peg-in-v2-06-swap`.* | Data | Type | | -------- | ------ | | Variable | `uint` | This variable represents the percentage fee applied to BTC peg-out operations during cross-swap transactions. By default, it is initialized to `u0` and can be updated via governance functions. Refer to the [set-btc-peg-out-fee](#set-btc-peg-out-fee) governance feature to know more about updating this variable. ### `btc-peg-out-min-fee` *Only present in `meta-peg-in-v2-06-swap`.* | Data | Type | | -------- | ------ | | Variable | `uint` | This variable sets the minimum fee required for BTC peg-out operations during cross-swap transactions. By default, it is initialized to `u0` and can be updated via governance functions. Refer to the [set-btc-peg-out-min-fee](#set-btc-peg-out-min-fee) governance feature to know more about updating this variable. ### Relevant constants #### `burn-height-start` | Type | Value | | ------ | --------------------------------------------------------------------------------------------- | | `uint` | `burn-block-height` [(see more)](https://docs.stacks.co/reference/keywords#burn-block-height) | This constant denotes the block height at which the contract was deployed on the underlying burn blockchain. It serves to restrict operations to only include transactions minted from this block onward. ## Features #### `finalize-peg-in-cross-on-index` *Only present in `meta-peg-in-endpoint-v2-04`.* This function processes the order recipient, which is extracted and decoded from the provided reveal transaction. The reveal transaction contains additional details about the peg-in operation, such as the recipient's address and the `order-idx`. In this scenario, the recipient may be on a different blockchain. To facilitate the peg-in process, the contract calls the supporting contract `cross-router-v2-03`, to route the tokens based on the destination chain. As this peg-in feature is designed for Bitcoin metaprotocol tokens (e.g., BRC-20), the primary objective of this function is to facilitate 'crossing' to an EVM network. In such cases, the `cross-router-v2-03` contract will subsequently call `cross-peg-out-endpoint-v2-01` to execute the transfer of BRC-20 tokens from Bitcoin to an EVM chain. If any errors occur during the cross-transaction data validation, the function triggers a refund mechanism. **Parameters** ```lisp (tx { bitcoin-tx: (buff 32768), output: uint, tick: (string-utf8 256), amt: uint , from: (buff 128), to: (buff 128), from-bal: uint, to-bal: uint, decimals: uint }) (block { header: (buff 80), height: uint }) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (signature-packs (list 10 { signer: principal, tx-hash: (buff 32), signature: (buff 65) })) (reveal-tx { tx: (buff 32768), order-idx: uint }) (reveal-block { header: (buff 80), height: uint }) (reveal-proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (fee-idx (optional uint)) (token-trait ) (token-out-trait ) ``` #### `finalize-peg-in-cross-swap-on-index` *Only present in `meta-peg-in-v2-06-swap`.* Similar to the peg-in-cross, the peg-in-cross-swap involves a cross-blockchain operation with an additional asset swapping capability. This feature is useful when the desired target token requires intermediate swap operations. The function achieves this by receiving a list of token traits (interfaces that define the behavior of tokens in the operation) involved in the operation up to the target token. Refer to the [AMM Pool documentation](https://docs.alexgo.io/developers/protocol-contracts#amm-trading-pool) for more details. In addition to the sender (from) and recipient (to) addresses, the order details in the reveal transaction include information about the swap route. This swap route is validated against the `amm-pool-v2-01` contract through the `cross-router-v2-03` contract to check pool parameters. Additionally, this function includes a refund mechanism that gets triggered in case any errors occur during the cross-swap transaction validation. **Parameters** ```lisp (tx { bitcoin-tx: (buff 32768), output: uint, tick: (string-utf8 256), amt: uint, from: (buff 128), to: (buff 128), from-bal: uint, to-bal: uint, decimals: uint }) (block { header: (buff 80), height: uint }) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (signature-packs (list 10 { signer: principal, tx-hash: (buff 32), signature: (buff 65) })) (reveal-tx { tx: (buff 32768), order-idx: uint }) (reveal-block { header: (buff 80), height: uint }) (reveal-proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (fee-idx (optional uint)) (routing-traits (list 5 )) (token-out-trait ) ``` #### `finalize-peg-in-request-burn-liabtc-on-index` *Only present in `meta-peg-in-endpoint-v2-04-lisa`.* This function handles a peg-in operation that involves requesting the burn of LiaBTC tokens in the ALEX system. It begins by indexing the provided Bitcoin transaction using the `oracle-v2-01` contract to verify its validity and ensure it has not been processed before. Once the transaction is validated, the function calls `finalize-peg-in-request-burn-liabtc` to complete the burn request. The function interacts with the `meta-bridge-registry-v2-03-lisa` contract to retrieve and validate token pair details, which refer to the registered combination of a token and its target chain ID, and with the `liabtc-mint-endpoint` to register the burn request. Additionally, it utilizes the `clarity-bitcoin-v1-07` contract to extract transaction details such as the SegWit transaction ID. Any accrued rewards or updates, which are likely tied to the use or staking of LiaBTC tokens within the ALEX system, are processed through the provided `liabtc-message` and validated using signature packs. The function includes mechanisms to handle fees, using the `btc-bridge-registry-v2-01` contract to register these transactions and to ensure the peg-in-fee is properly accounted for. **Parameters** ```lisp (tx { bitcoin-tx: (buff 32768), output: uint, tick: (string-utf8 256), amt: uint, from: (buff 128), to: (buff 128), from-bal: uint, to-bal: uint, decimals: uint }) (block { header: (buff 80), height: uint }) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (signature-packs (list 10 { signer: principal, tx-hash: (buff 32), signature: (buff 65) })) (reveal-tx { tx: (buff 32768), order-idx: uint }) (reveal-block { header: (buff 80), height: uint }) (reveal-proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (fee-idx (optional uint)) (liabtc-message { token: principal, accrued-rewards: uint, update-block: uint }) (liabtc-signature-packs (list 100 { signer: principal, message-hash: (buff 32), signature: (buff 65) })) ``` #### `finalize-peg-in-update-burn-liabtc` *Only present in `meta-peg-in-endpoint-v2-04-lisa`.* This function finalizes or revokes a burn request for LiaBTC tokens initiated in the ALEX system. It validates the Bitcoin transaction through the `oracle-v2-01` contract, ensuring it was mined and indexed correctly. It interacts with the `meta-bridge-registry-v2-03-lisa` contract to verify the status of the burn request and update its details. If the burn request is finalized (status `0x01`), the function confirms the burn through the `liabtc-mint-endpoint` and completes the operation. For revocations (status `0x02`), the function handles re-minting of LiaBTC tokens and executes a peg-out process using the `meta-peg-out-endpoint-v2-04`. **Parameters** ```lisp (commit-tx { tx: (buff 32768), fee-idx: (optional uint) }) (block { header: (buff 80), height: uint }) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (reveal-tx { tx: (buff 32768), order-idx: uint }) (reveal-block { header: (buff 80), height: uint }) (reveal-proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (message { token: principal, accrued-rewards: uint, update-block: uint }) (signature-packs (list 100 { signer: principal, message-hash: (buff 32), signature: (buff 65) })) ``` ### Supporting features The following functions are tools to assist the off-chain activities. 1. Validation helpers (`validate-tx-cross`, `validate-tx-cross-swap`, `validate-tx-request-burn`, `validate-tx-update-burn`). 2. Order creation helpers (`create-order-cross-or-fail`, `create-order-cross-swap-or-fail`, `create-order-request-burn-or-fail`). 3. Decoding helpers (`decode-order-cross-or-fail`, `decode-order-cross-swap-or-fail`). 4. Token pair helpers (`get-pair-details-many`, `is-approved-pair`). ### Governance features #### `is-dao-or-extension` This standard protocol function checks whether a caller (`tx-sender`) is the DAO executor or an authorized extension, delegating the extensions check to the `executor-dao` contract. #### `is-paused` A read-only function that checks the operational status of the contract. #### `pause` A public function, governed through the `is-dao-or-extension`, that can change the contract's operational status. **Parameters** ```lisp (new-paused bool) ``` #### `transfer-all-to-many` This contract feature is designed to transfer its entire balance of a specified list of tokens to a new owner. Access to this feature is restricted by the `is-dao-or-extension` function. **Parameters** ```lisp (new-owner principal) (token-traits (list 10 )) ``` #### `set-fee-to-address` A public function, governed through the `is-dao-or-extension`, that sets the address to which the fee in Bridged BTC tokens will be transferred. **Parameters** ```lisp (new-fee-to-address principal) ``` #### `set-peg-in-fee` A public function, governed through the `is-dao-or-extension`, that establishes the fee to be deducted for the peg-in operation. **Parameters** ```lisp (fee uint) ``` #### `set-btc-peg-out-fee` *Only present in `meta-peg-in-v2-06-swap`.* A public function, governed through the `is-dao-or-extension`, that sets the percentage fee applied to BTC peg-out operations. **Parameters** ```lisp (fee uint) ``` #### `set-btc-peg-out-min-fee` *Only present in `meta-peg-in-v2-06-swap`.* A public function, governed through the `is-dao-or-extension`, that establishes the minimum fee required for BTC peg-out operations. **Parameters** ```lisp (fee uint) ``` ### Getters * `get-fee-to-address` * `get-peg-in-fee` * `get-pair-details` * `get-pair-details-or-fail` * `get-pair-details-many` * `get-tick-to-pair-or-fail` * `get-peg-in-sent-or-default` * `get-btc-peg-out-fee` *(only present in meta-peg-in-v2-06-swap)* * `get-btc-peg-out-min-fee` *(only present in meta-peg-in-v2-06-swap)* * `get-liabtc-decimals` *(only present in meta-peg-in-endpoint-v2-04-lisa)* ### Relevant internal functions * `index-tx`: this function validates and indexes a Bitcoin transaction in the `oracle-v2-01` contract. * `refund`: this function returns the total amount of the peg-in transaction, including the fee, to the sender in case of a failure during the operation. ## Contract calls (interactions) * `executor-dao`: calls are made to verify whether a certain contract-caller is designated as an extension. * `meta-bridge-registry-v2-03`: this interaction is used by the peg-in contract to check and set token pair information. It also facilitates liquidity operations to set balances and manage pool operations. * `btc-peg-out-endpoint-v2-01`: the `request-peg-out-0` function of this contract is used by the peg-in contract to remove liquidity and refund BTC amounts. * `btc-bridge-registry-v2-01`: the peg-in contract calls the `set-peg-in-sent` function of this contract to register a processed Bitcoin transaction. * `meta-peg-out-endpoint-v2-04`: the `finalize-peg-in-remove-liquidity` feature and the internal `refund` function call this contract to request a peg-out in their respective contexts. * `cross-router-v2-03`: the peg-in cross and peg-in cross swap operations use this contract to validate-route and route peg-ins involving other blockchains. * `oracle-v2-01`: this contract is called to verify that a transaction was mined and to index Bitcoin transactions. * `clarity-bitcoin-v1-07`: the peg-in contract uses this contract to obtain legacy transaction IDs from a SegWit native transaction. * `amm-pool-v2-01`: this contract manages all liquidity operations, including adding and reducing positions, within the peg-in features. Additionally, it acts as a helper to retrieve pool information and details. * `token-abtc`: this is the Bridged BTC token used throughout the peg-in contract to operate with native Stacks' SIP-010 token transactions involving the burn blockchain base-coin (BTC). * Tokens (`token-trait`): during peg-in operations, this trait is used to invoke the relevant tokens to perform the necessary transfers involved in the transaction. It is a customized version of Stacks' standard definition for Fungible Tokens (`sip-010`), with support for 8-digit fixed notation. * `bridge-common-v2-02`: this contract provides common helper functions to all Brotocol contracts, including order creation, transaction decoding, and cross-chain routing validations. * `liabtc-mint-endpoint`: this contract is called to validate and register burn requests of LiaBTC during peg-in operations. It ensures that the burn process adheres to protocol requirements and updates the registry with the burn request details. * `token-wvliabtc`: this contract manages the wrapped representation of LiaBTC tokens on the Stacks network. It is used during peg-in operations to burn wvliabtc tokens and to validate the corresponding token amounts for bridging purposes. ## Errors | Error Name | Value | | ------------------------------------------------------------------------- | ------------- | | `err-unauthorised` | `(err u1000)` | | `err-paused` | `(err u1001)` | | `err-peg-in-address-not-found` | `(err u1002)` | | `err-invalid-amount` | `(err u1003)` | | `err-token-mismatch` | `(err u1004)` | | `err-invalid-tx` | `(err u1005)` | | `err-already-sent` | `(err u1006)` | | `err-address-mismatch` | `(err u1007)` | | `err-request-already-revoked` | `(err u1008)` | | `err-request-already-finalized` | `(err u1009)` | | `err-revoke-grace-period` | `(err u1010)` | | `err-request-already-claimed` | `(err u1011)` | | `err-invalid-input` | `(err u1012)` | | `err-tx-mined-before-request` | `(err u1013)` | | `err-commit-tx-mismatch` | `(err u1014)` | | `err-invalid-burn-height` | `(err u1003)` | | `err-tx-mined-before-start` | `(err u1015)` | | `err-slippage-error` | `(err u1016)` | | `err-bitcoin-tx-not-mined` | `(err u1017)` | | `err-invalid-request` *(only present in meta-peg-in-endpoint-v2-04-lisa)* | `(err u1018)` | # Meta Peg-Out Endpoints * Location: `./packages/contracts/bridge-stacks/contracts/meta-peg-out-endpoint-v2-04.clar` * [Deployed contract](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.meta-peg-out-endpoint-v2-04?chain=mainnet) This technical document provides a detailed overview of the contract responsible for facilitating the peg-out process of tokens from the Stacks network to the burn chain. The target token standard is BRC-20, a protocol on Bitcoin's metaprotocol layer that supports fungible assets, inspired by Ethereum's ERC-20 standard. Unlike the meta-peg-in contract, the meta-peg-out feature is specifically designed to support the bridging-out process. This is achieved through a series of public functions, each intended to execute sequentially, while incorporating grace periods between their execution. In the following sections, we will explore these functions in detail. ## Storage ### `paused` | Data | Type | | -------- | ------ | | Variable | `bool` | This data variable serves as a flag to control the operational status of the contract. When set to `true`, all peg-out transactions are blocked. By default, the contract is deployed in *paused* mode. Refer to the [pause](#pause) governance feature to know more on how to change this status. ### `fee-to-address` | Data | Type | | -------- | ----------- | | Variable | `principal` | This variable represents the address to which fees are paid. In this contract, there are two categories of fees: peg-out fees and gas fees. The first ones are charged in the same token being bridged, while gas fees are handled using the Bridged BTC token. For more details on these transactions, refer to the [finalize peg-out feature](#finalize-peg-out-on-index). By default, the address assigned to receive these fees is the one used to deployed the contract. ### Relevant constants #### `burn-height-start` | Type | Value | | ------ | ---------------------------------------------------------------------------------- | | `uint` | [`burn-block-height`](https://docs.stacks.co/reference/keywords#burn-block-height) | This constant specifies the block height of the underlying burn chain at the time the contract was deployed. It is utilized to ensure that operations within the `finalize-peg-out` function are limited to transactions minted from this block onward. ## Features The peg-out is a multi-step process comprising several phases to ensure secure and orderly transactions. The process begins with a peg-out request to initiate the transfer of tokens out of the Stacks network. Configured grace periods then allow users to either revoke their request or claim it. Once a peg-out request is claimed, the final step is to finalize the peg-out, executing the transfer and updating the relevant records. Each of these steps is implemented through dedicated contract functions, which are explained in detail below. #### `request-peg-out` *Only present in `meta-peg-out-endpoint-v2-04`.* In this first step, the `tx-sender` requests a peg-out a specified amount of previously bridged tokens. Upon initiation, the net amount along with fee costs are escrowed by transferring the token and the gas fee token (`token-abtc`) to the contract, where they remain until the operation is either finalized or revoked. To proceed, several validations must be met: * The pair (token + chain-id) must be approved in the meta registry, meaning it is recognized as eligible for bridging operations. * The specified amount must exceed the peg-out operation fee for that particular token. * The token peg-out operation must be active in the registry (not paused). Once these validations are met, the operation is registered in the meta registry via the contract `meta-bridge-registry-v2-03`. The function then generates a unique identifier, known as the `request-id`, ensuring traceability and reference for future operations. **Parameters** ```lisp (amount uint) (peg-out-address (buff 128)) (token-trait ) (the-chain-id uint) ``` #### `claim-peg-out` *Only present in `meta-peg-out-endpoint-v2-04`.* A next potential step is to claim the request previously issued. This step is critical, as it marks the request as ready for finalization. This action is executed by calling the function with the id of the request, along with the `fulfilled-by` parameter, which designates the address responsible for executing the bitcoin operation. The claim must satisfy the following validations: * The request must exist. * The token pair must be approved and operational (not paused for peg-out). * The request must not be revoked, finalized, or previously claimed. Once these conditions are met, the final step is to register the claim in the meta registry. This registration includes the claimer, the fulfilled-by address and the calculated grace period, during which the claimed request will be eligible for finalization. **Parameters** ```lisp (request-id uint) (fulfilled-by (buff 128)) ``` #### `finalize-peg-out-on-index` *Only present in `meta-peg-out-endpoint-v2-04`.* Finalizing a peg-out is the final step in committing the process. This function takes in the burn chain (Bitcoin) transaction that corresponds to the Stacks layer operation and executes the peg-out request along with all related token transfers and their corresponding fees. The finalization can be performed by either a peg-in address or a third-party address. Key validations include: * The request must exist. * The token pair must be approved and operational (not paused for peg-out). * The transaction cannot be indexed to a time before the deployment of the contract. * The transaction's metaprotocol token (BRC-20) must match the requested details, including the `tick` (a unique identifier for the token) and the `amount` (the quantity of the token involved in the transaction). Additionally, the `from` address must correspond to the `fulfilled-by` address, and the `to` address must match the `peg-out-address`. * The request must not be revoked or already finalized. The procedure is as follows, based on who finalizes it: 1. Peg-In Address * The net amount of tokens requested for the peg-out operation is burned from the contract balance, affecting the overall total supply. * The peg-out fee and gas fees are paid to the [configured address](#fee-to-address). 2. Third-Party Address * The net amount of tokens requested for the peg-out operation and the gas fee are transferred from the contract to the claimer, so the overall involved token supply remains unaffected. * The peg-out fee is transferred from the contract to the [configured address](#fee-to-address). This operation involves indexing the specified transaction through the `oracle-v2-01` contract and marking the request as "finalized" in the `meta-bridge-registry-v2-03` contract. **Parameters** ```lisp (request-id uint) (tx { bitcoin-tx: (buff 32768), output: uint, tick: (string-utf8 256), amt: uint, from: (buff 128), to: (buff 128), from-bal: uint, to-bal: uint, decimals: uint }) (block { header: (buff 80), height: uint }) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) (signature-packs (list 10 { signer: principal, tx-hash: (buff 32), signature: (buff 65) })) (token-trait ) ``` #### `revoke-peg-out` *Only present in `meta-peg-out-endpoint-v2-04`.* In certain scenarios, a requested peg-out may need to be revoked, allowing users to retract it if necessary. Key validations include: * The request must be revoked within the grace period before it expires. * The request must not have been claimed, finalized, or previously revoked. If these conditions are met, the process continues by returning the tokens initially escrowed for the request, including both the peg-in tokens and the associated fees. These returns are made from the contract directly back to the requester. Finally, the `meta-bridge-registry-v2-03` contract is invoked to mark this request as `revoked`. **Parameters** ```lisp (request-id uint) (token-trait ) ``` ### Supporting features The following functions are tools to assist the off-chain activities. 1. Validation helpers (`validate-peg-out`). 2. Token pair helpers (`get-pair-details-many`). ### Governance features #### `is-dao-or-extension` This standard protocol function checks whether a caller (`tx-sender`) is the DAO executor or an authorized extension, delegating the extensions check to the `executor-dao` contract. #### `is-paused` A read-only function that checks the operational status of the contract. #### `pause` A public function, governed through the `is-dao-or-extension`, that can change the contract's operational status. **Parameters** ```lisp (new-paused bool) ``` #### `transfer-all-to-many` This contract feature is designed to transfer its entire balance of a specified list of tokens to a new owner. Access to this feature is restricted by the `is-dao-or-extension` function. **Parameters** ```lisp (new-owner principal) (token-traits (list 10 )) ``` #### `set-fee-to-address` This contract feature allows for specifying the address to which peg-out fees (denominated in the relevant tokens) and gas fees (denominated in Bridged BTC tokens, known as `token-abtc`) will be transferred. **Parameters** ```lisp (new-fee-to-address principal) ``` ### Getters * `get-fee-to-address` * `get-request` * `get-request-many` * `get-request-revoke-grace-period` * `get-request-claim-grace-period` * `get-request-or-fail` * `get-pair-details` * `get-pair-details-many` * `get-pair-details-or-fail` * `get-tick-to-pair-or-fail` * `get-peg-in-sent-or-default` ### Relevant internal functions * `index-tx`: this function validates and indexes a Bitcoin transaction in the `oracle-v2-01` contract. ## Contract calls (interactions) * `executor-dao`: calls are made to verify whether a certain contract-caller is designated as an extension. * `meta-bridge-registry-v2-03`: this interaction is primarily utilized by the peg-out contract to register request operations. Additionally, this contract is responsible for managing approved addresses. It provides functionality through its `is-peg-in-address-approved` and `is-fulfill-address-approved` functions, which verify whether specific addresses are authorized within the system. * `oracle-v2-01`: this contract is called to verify that a transaction was mined and to index Bitcoin transactions. * Tokens (`token-trait`): during the steps of peg-out operations, this trait is utilized to invoke the relevant tokens and execute the necessary transfers involved in the transaction. It is a customized adaptation of Stacks' standard definition for Fungible Tokens (`sip-010`), with additional support for 8-digit fixed-point notation. * `token-abtc`: this is the Bridged BTC token used throughout the peg-out contract to operate with native Stacks' SIP-010 token transactions involving the burn chain base-coin (BTC). ## Errors | Error Name | Value | | ------------------------------- | ------------- | | `err-unauthorised` | `(err u1000)` | | `err-paused` | `(err u1001)` | | `err-peg-in-address-not-found` | `(err u1002)` | | `err-invalid-amount` | `(err u1003)` | | `err-token-mismatch` | `(err u1004)` | | `err-invalid-tx` | `(err u1005)` | | `err-already-sent` | `(err u1006)` | | `err-address-mismatch` | `(err u1007)` | | `err-request-already-revoked` | `(err u1008)` | | `err-request-already-finalized` | `(err u1009)` | | `err-revoke-grace-period` | `(err u1010)` | | `err-request-already-claimed` | `(err u1011)` | | `err-invalid-input` | `(err u1012)` | | `err-tx-mined-before-request` | `(err u1013)` | | `err-commit-tx-mismatch` | `(err u1014)` | | `err-invalid-burn-height` | `(err u1003)` | | `err-tx-mined-before-start` | `(err u1015)` | # Cross Peg-In Endpoints * Location: `./packages/contracts/bridge-stacks/contracts/` * Deployed contracts: [cross-peg-in-endpoint-v2-04](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.cross-peg-in-endpoint-v2-04?chain=mainnet), [cross-peg-in-v2-04-launchpad](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.cross-peg-in-v2-04-launchpad?chain=mainnet). This technical document provides a detailed overview of the module responsible for managing the peg-in process, enabling the transfer of assets from external EVM-like blockchains into the Stacks network. The contract serves as the operational interface for relayers to submit orders, which are validated against a threshold of required validators as determined in the `cross-bridge-registry-v2-01`. The module's primary functionality is implemented through a suite of public functions that are distributed across the following contracts: * `cross-peg-in-endpoint-v2-04`: handles bridging tokens from EVM-like blockchains to Stacks, leveraging cross-router to manage the routing of tokens to the appropriate destination. * `cross-peg-in-v2-04-launchpad`: facilitates bridging tokens from EVM-like blockchains to Stacks, specifically for participation in launchpad activities. * `cross-peg-in-v2-04-swap`: enables token bridging from EVM-like blockchains to Stacks while performing token swaps through predefined routes. ## Storage *All contracts include the following variables unless otherwise specified.* ### `is-paused` | Data | Type | | -------- | ------ | | Variable | `bool` | A flag that indicates whether the peg-in process is paused. If set to `true`, all operations are paused, preventing relayers from submitting new peg-in orders. The contract is initialized in a paused state by default. ### `use-whitelist` | Data | Type | | -------- | ------ | | Variable | `bool` | A flag that determines whether the whitelist mechanism is enforced. When set to `true`, only whitelisted users are authorized to perform restricted actions. By default, this value is `false`. ### `whitelisted-users` | Data | Type | | ---- | ---------------- | | Map | `principal bool` | A map that keeps track of the whitelist status of specific users. Each entry associates a user's principal with a boolean value indicating whether they are authorized to interact with the contract under a whitelist-enabled configuration. If `true`, the user is allowed to perform actions that are otherwise restricted. ### Relevant constants * `structured-data-prefix`, `message-domain-main`, `message-domain-test`: these constants are utilized in the `validate-order` function to verify the signature consistency with the order hash. ## Features ### `transfer-to-cross` *In `cross-peg-in-endpoint-v2-04` contract.* This function enables peg-in operations to transfer tokens from an external EVM-like blockchain to Stacks. It validates the provided order by checking its hash and verifying signatures to meet a threshold of validators defined in `cross-bridge-registry-v2-01`. If the order is valid, it mints or transfers the bridged tokens to the sender of the transaction (`tx-sender`), and updates the token reserve for the source EVM chain. It then utilizes `cross-router-v2-03` to route the tokens based on the destination chain. In case the validation fails, the function initiates a refund process. **Parameters** ```lisp (order { from: (buff 128), to: (buff 128), token-in: principal, token-out: principal, amount-in-fixed: uint, src-chain-id: uint, dest-chain-id: (optional uint), salt: (buff 256) }) (token-in-trait ) (token-out-trait ) (signature-packs (list 100 { signer: principal, order-hash: (buff 32), signature: (buff 65) })) ``` ### `transfer-to-cross-swap` *In `cross-peg-in-v2-04-swap` contract.* This function facilitates advanced peg-in operations by incorporating token swapping during cross-chain transfers. It validates the order hash and signatures using `cross-bridge-registry-v2-01`, ensuring compliance with routing configurations, such as token paths and output amounts. Upon successful validation, the bridged tokens are swapped and routed to the recipient using `cross-router-v2-03`, following the same logic outlined in the `transfer-to-cross` feature. If validation fails, the function processes a refund. **Parameters** ```lisp (order { from: (buff 128), to: (buff 128), amount-in-fixed: uint, token-in: principal, routing-tokens: (list 5 principal), routing-factors: (list 4 uint), token-out: principal, min-amount-out-fixed: (optional uint), src-chain-id: uint, dest-chain-id: (optional uint), salt: (buff 256) }) (token-in-trait ) (routing-traits (list 5 )) (token-out-trait ) (signature-packs (list 100 { signer: principal, order-hash: (buff 32), signature: (buff 65) })) ``` ### `transfer-to-launchpad` *In `cross-peg-in-v2-04-launchpad` contract.* This function enables peg-in operations linked to [launchpad projects](https://docs.alexlab.co/features/launchpad). It validates the order and signatures through `cross-bridge-registry-v2-01` and confirms compatibility with the launchpad parameters. Once validated, the function mints bridged tokens, transfers them to the recipient and registers the operation in the `alex-launchpad-v2-03` contract. In case of validation failure, a refund is processed. **Parameters** ```lisp (order { address: (buff 128), chain-id: uint, launch-id: uint, dest: (buff 128), token: principal, amount-in-fixed: uint, salt: (buff 256) }) (token-trait ) (signature-packs (list 100 { signer: principal, order-hash: (buff 32), signature: (buff 65) })) ``` ### Supporting features The following functions are tools to assist the off-chain activities. 1. Validation helpers (`validate-cross-order`, `validate-cross-swap-order`, `validate-launchpad-order`). 2. Order creation helpers (`create-cross-order`, `create-cross-swap-order`, `create-launchpad-order`). 3. Decoding helpers (`decode-cross-order`, `decode-cross-swap-order`, `decode-launchpad-order`). 4. Relayer helper (`is-approved-relayer-or-default`). ### Governance features #### `is-dao-or-extension` This standard protocol function checks whether a caller (`tx-sender`) is the DAO executor or an authorized extension, delegating the extensions check to the `executor-dao` contract. #### `is-whitelisted` A read-only function that checks whether a specific user is included in the `whitelisted-users` map. It returns `true` if the user is whitelisted; otherwise, it returns `false`. #### `get-paused` A read-only function that checks the operational status of the contract. #### `set-paused` A public function, governed through the `is-dao-or-extension`, that can change the contract's operational status. **Parameters** ```lisp (paused bool) ``` #### `apply-whitelist` A public function, governed through the `is-dao-or-extension`, that toggles the use of the whitelist in the contract. When enabled, only users who are on the whitelist are authorized to execute restricted actions within the contract. **Parameters** ```lisp (new-use-whitelist bool) ``` #### `whitelist` A public function, governed through the `is-dao-or-extension`, that allows authorized extensions, to add or remove a single user from the whitelist. It updates the `whitelisted-users` map, where the user's principal is mapped to a `bool` value (`true` for accepted users and `false` for denied users). **Parameters** ```lisp (user principal) (whitelisted bool) ``` #### `whitelist-many` A public function, governed through the `is-dao-or-extension`, that allows to batch add or remove multiple users from the whitelist. This function iteratively calls `whitelist`, which handles the mapping of each user's principal to a bool value in the `whitelisted-users` map. **Parameters** ```lisp (users (list 2000 principal)) (whitelisted (list 2000 bool)) ``` ### Getters #### `get-use-whitelist` #### `get-validator-or-fail` **Parameters** ```lisp (validator principal) ``` #### `get-required-validators` #### `get-approved-chain-or-fail` **Parameters** ```lisp (src-chain-id uint) ``` #### `get-token-reserve-or-default` **Parameters** ```lisp (pair { token:principal, chain-id: uint }) ``` #### `get-min-fee-or-default` **Parameters** ```lisp (pair { token:principal, chain-id: uint }) ``` #### `get-approved-pair-or-fail` **Parameters** ```lisp (pair { token:principal, chain-id: uint }) ``` ## Contract calls (interactions) * `executor-dao`: calls are made to verify whether a certain contract-caller is designated as an extension. * `cross-bridge-registry-v2-01`: this contract is called to validate key components of the peg-in process, such as approved tokens, chain IDs, and relayers. It also handles updates to transaction statuses, token reserves, and validator signatures. * `cross-router-v2-03`: this contract is used to validate routing details and execute cross-chain token transfers and swaps. It ensures that the provided routing tokens and factors align with the transfer requirements, performs swaps through `amm-pool-v2-01` when multiple tokens are involved, validates minimum output amounts, and handles the final routing process for peg-in operations, including cross and cross-swap transactions. * `alex-launchpad-v2-03`: this contract is used to validate and register peg-in operations specifically related to launchpad projects on the Stacks network. * `token-trait`: in cross peg-in operations (featuring `transfer-to-cross`, `transfer-to-cross-swap`, and `transfer-to-launchpad`) this trait is employed to interact with relevant tokens for obtaining their principals, minting, and executing necessary transfers within the transaction. It is a customized version of Stacks' standard definition for Fungible Tokens (`sip-010`), with support for 8-digit fixed notation. * `cross-peg-out-endpoint-v2-01`: this contract is invoked to manage refunds for peg-in operations that failed external validations. ## Errors | Error Name | Value | | -------------------------- | ------------- | | `ERR-NOT-AUTHORIZED` | `(err u1000)` | | `ERR-TOKEN-NOT-AUTHORIZED` | `(err u1001)` | | `ERR-DUPLICATE-SIGNATURE` | `(err u1009)` | | `ERR-ORDER-HASH-MISMATCH` | `(err u1010)` | | `ERR-INVALID-SIGNATURE` | `(err u1011)` | | `ERR-UKNOWN-RELAYER` | `(err u1012)` | | `ERR-REQUIRED-VALIDATORS` | `(err u1013)` | | `ERR-ORDER-ALREADY-SENT` | `(err u1014)` | | `ERR-PAUSED` | `(err u1015)` | | `ERR-INVALID-VALIDATOR` | `(err u1016)` | | `ERR-INVALID-INPUT` | `(err u1020)` | | `ERR-NOT-IN-WHITELIST` | `(err u1021)` | | `ERR-INVALID-TOKEN` | `(err u1022)` | | `ERR-SLIPPAGE` | `(err u1023)` | # Cross Peg-Out Endpoints * Location: `./packages/contracts/bridge-stacks/contracts/` * Deployed contracts:[cross-peg-out-endpoint-v2-01](https://explorer.hiro.so/txid/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.cross-peg-out-endpoint-v2-01?chain=mainnet), [cross-peg-out-v2-01-agg](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.cross-peg-out-v2-01-agg?chain=mainnet) This technical document provides a detailed overview of the contracts responsible for managing the peg-out process, enabling the transfer of `SIP-010` bridged tokens from the Stacks network to EVM-compatible blockchain networks as EVM-based assets. The contracts manage token transfers by validating amounts and applying fees. During the process, tokens are either burned or transferred (depending on the token's configuration) to a designated address on the EVM chain. The core functionalities of the module are implemented through public and governance functions in the following contracts: * `cross-peg-out-endpoint-v2-01`: handles bridging of aBTC tokens from Stacks to EVM-compatible blockchains. * `cross-peg-out-v2-01-agg`: enables the bridging of tokens from Stacks to an EVM-compatible blockchain to perform a swap on a non-ALEX liquidity aggregator. ## Storage *All contracts include the following variables unless otherwise specified.* ### `is-paused` | Data | Type | | -------- | ------ | | Variable | `bool` | A flag that indicates whether the peg-out process is active. If set to `true`, all peg-out operations are paused, preventing any new transactions. The contract is deployed in a paused state by default. ### `use-whitelist` *Only present in `cross-peg-out-endpoint-v2-01`.* | Data | Type | | -------- | ------ | | Variable | `bool` | A flag that determines whether a whitelist is enforced for peg-out operations. If set to `true`, only addresses explicitly whitelisted can execute peg-out transactions. By default, this feature is disabled. ### `whitelisted-users` *Only present in `cross-peg-out-endpoint-v2-01`.* | Data | Type | | ---- | ------------------ | | Map | `principal → bool` | This map stores the whitelist status of users. Each entry associates a `principal` with a boolean value indicating whether they are authorized to perform peg-out transactions. When `use-whitelist` is set to `true`, users with a value of `true` in this map are whitelisted and permitted to participate in the process; otherwise, the whitelist is not enforced. ## Features ### Peg-out feature #### `transfer-to-unwrap` *Only present in `cross-peg-out-endpoint-v2-01`.* This function manages the peg-out process, enabling users to transfer `SIP-010` bridged tokens from the Stacks network to EVM-compatible blockchains. It begins by validating the transfer through the `validate-transfer-to-unwrap` function, performing checks such as token and chain approval, whitelist status, amount thresholds, and sufficient reserves for the operation. Once validated, the function calculates the required fee and determines the net amount to be transferred. Depending on the token's properties, the function either burns the net amount directly from the user's balance or transfers the entire amount (including the fee) to the `cross-bridge-registry-v2-01`. At the end of the process, the function logs key destination details, including the `settle-address`, which represents the recipient's address on the EVM-compatible blockchain. **Parameters** ```lisp (token-trait ) (amount-in-fixed uint) (dest-chain-id uint) (settle-address (buff 256)) ``` #### `transfer-to-swap` *Only present in `cross-peg-out-v2-01-agg`.* This function handles the peg-out process from Stacks to an EVM-compatible blockchain. It prepares the transaction to be sent to an external liquidity aggregator in the `BridgeEndpointWithSwap.sol` contract. Its core functionality consists of validating amounts, deducting fees, transferring tokens and emitting an event with the transaction details. The function begins by validating the transfer through the `validate-transfer-to-swap` function, performing checks such as token and chain approval, amount thresholds, and sufficient reserves for the operation. Once validated, the function calculates the required fee and determines the net amount to be transferred. Depending on the token's properties, the function either burns the tokens or transfers them to the `cross-bridge-registry-v2-01` contract. This action records the transaction and prepares it for further processing. At this point, an event is emitted, signaling relayers to detect and forward the transaction to `BridgeEndpointWithSwap`, which completes the operation through an external liquidity aggregator. ```lisp (amount-in-fixed uint) (token-in-trait ) (token-out principal) (min-amount-out (optional uint)) (dest-chain-id uint) (settle-details { address: (buff 256), chain-id: (optional uint) }) ``` ### Governance features #### `is-dao-or-extension` This standard protocol function checks whether a caller (`tx-sender`) is the DAO executor or an authorized extension, delegating the extensions check to the `executor-dao` contract. #### `is-whitelisted` *Only present in `cross-peg-out-endpoint-v2-01`.* A read-only function that checks whether a specific user is included in the `whitelisted-users` map. It returns `true` if the user is whitelisted; otherwise, it returns `false`. **Parameters** ```lisp (user principal) ``` #### `get-paused` A read-only function that checks the operational status of the contract. #### `set-paused` A public function, governed through the `is-dao-or-extension`, that can change the contract's operational status. **Parameters** ```lisp (paused bool) ``` #### `apply-whitelist` *Only present in `cross-peg-out-endpoint-v2-01`.* A public function, governed through the `is-dao-or-extension`, that enables or disables the whitelist mechanism for peg-out transactions. When enabled, only users listed in the `whitelisted-users` map can perform peg-out operations. **Parameters** ```lisp (new-use-whitelist bool) ``` #### `whitelist` *Only present in `cross-peg-out-endpoint-v2-01`.* A public function, governed through the `is-dao-or-extension`, that allows the DAO to manage user access to the peg-out feature. It updates the `whitelisted-users` map to either include or remove a specific user. If the `whitelisted` parameter is set to `true`, the user is added to the whitelist; if set to `false`, the user is removed. **Parameters** ```lisp (user principal) (whitelisted bool) ``` #### `whitelist-many` *Only present in `cross-peg-out-endpoint-v2-01`.* A public function, governed through the `is-dao-or-extension`, that allows the DAO to update the whitelist for multiple users in a single call. It works as a batch operation for the `whitelist` function, applying the specified whitelist status (`true` to add or `false` to remove) for each user in the provided list. The `whitelisted-users` map is updated. **Parameters** ```lisp (users (list 2000 principal)) (whitelisted (list 2000 bool)) ``` ### Getters #### `get-use-whitelist` *Only present in `cross-peg-out-endpoint-v2-01`.* #### `get-approved-chain-or-fail` **Parameters** ```lisp (dest-chain-id uint) ``` #### `get-token-reserve-or-default` **Parameters** ```lisp (pair { token: principal, chain-id: uint }) ``` #### `get-min-fee-or-default` **Parameters** ```lisp (pair { token: principal, chain-id: uint }) ``` #### `get-approved-pair-or-fail` **Parameters** ```lisp (pair { token: principal, chain-id: uint }) ``` ## Contract calls (interactions) * `executor-dao`: Calls are made to verify whether a certain contract-caller is designated as an extension. * `cross-bridge-registry-v2-01`: This contract is called to verify key components of the peg-out process. It validates approved tokens and chain pairings, manages the deduction and queries of token reserves, and records accrued fees. It also handles updates to transaction statuses. * `token-trait`: In the cross-peg-out process, this trait is employed to manage token operations such as burning tokens when required or transferring them to the `cross-bridge-registry-v2-01` contract. It is a customized version of Stacks' standard definition for Fungible Tokens (`sip-010`), with support for 8-digit fixed notation. ## Errors | Error Name | Value | | ------------------------------ | ------------- | | `ERR-NOT-AUTHORIZED` | `(err u1000)` | | `ERR-PAUSED` | `(err u1015)` | | `ERR-USER-NOT-WHITELISTED` | `(err u1016)` | | `ERR-AMOUNT-LESS-THAN-MIN-FEE` | `(err u1017)` | | `ERR-INVALID-AMOUNT` | `(err u1019)` | # Brotocol Staking Manager * Location: `xlink-dao/contracts/aux/xlink-staking.clar` * [Deployed contract](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.xlink-staking) The `xlink-staking` contract, also known as the **Brotocol Staking Manager**, is designed to manage liquid staking pools for multiple tokens and track staker positions within each pool. It holds users' staked funds, while the actual staking execution and reward reinvestment processes are managed off-chain by Brotocol's infrastructure. The Staking Manager contract is part of a hybrid, token-agnostic liquid staking management system, that operates alongside off-chain backend and frontend components managed by Brotocol. ## Liquid staking The lifecycle of liquid staking pools is based on three main operations: 1. **Staking**. Users deposit tokens into the `xlink-staking` contract, which are staked externally. 2. **Rewards accrual**. Rewards earned through the external staking protocol are periodically restaked, generating automatic compound interest for stakers. 3. **Unstaking**. Users can withdraw their staked tokens, which include accumulated restaked rewards, at any time. These are the main three features of the `xlink-staking` contract. Each of these has an impact on the contract storage and generates on-chain events, which are listened by the Brotocol off-chain components to facilitate corresponding external staking operations. ### Shares-based staking The system utilizes **shares** instead of token amounts to represent users' staking positions. Shares provide a fixed representation of the users' proportional ownership of the total amount staked, which intrinsically grows over time due to the reinvestment of the staking rewards. ## Reward accrual The account for the restaked rewards is permissionlessly performed by **updaters**, who submit messages signed by **validators**. This action is performed via the [`add-rewards`](#add-rewards) function and it's the core operation of the liquid staking mechanism. Validators are Brotocol protocol actors responsible for maintaining the system's integrity and synchronization. In this sense, their role includes generating a **proof** whenever rewards are successfully collected and restaked in the external protocol. Each proof consists of a signed message indicating the token, the updated total accrued rewards, and a timestamp. Once updaters collect a sufficient number of proofs, they submit these to the Staking Manager to perform a state update. It is important to note that this operation does not involve shares management. The key state update is the total staked amount in the [`total-staked`](#total-staked) map. ## Stake / Unstake ### Authorization These operations are exclusively available for **governance** roles, as they are guarded by the [`is-dao-or-extension`](#is-dao-or-extension) function. What does this imply? The [`stake`](#stake) and [`unstake`](#unstake) functions are designed to be called by a DAO extension acting as the `contract-caller`. Alternatively, in more exceptional cases, the `tx-sender` can be the DAO itself calling through a proposal contract. This setup implies that end users can only access these features indirectly through intermediary contracts (façade, endpoint, etc.) that must be enabled DAO extensions. The external call from the extension to the `xlink-staking` contract, a.k.a. Staking Manager, can be implemented in two ways, resulting in different authentications for the `tx-sender`, the staker. In summary, these operations are typically accessed by users through intermediary contracts registered as DAO extensions. However, they can also be directly called by a proposal contract executed by the DAO. #### End user call ```mermaid flowchart LR User --Sends transtaction--> i["DAO extension"] i["DAO extension"] -.-> B((Call type)) B --contract-call--> sm1[Staking Manager] B --as-contract--> sm2[Staking Manager] sm1 -.-o box1[["**tx-sender**: User **contract-caller**: DAO extension"]] sm2 -.-o box2[["**tx-sender** & **contract-caller**: DAO extension"]] ``` The `as-contract` call type is the most common approach for liquid staking implementations, where the intermediary contract stakes on behalf of users and provides them with a receipt in the form of a new (rebasing) token. #### Governance call ```mermaid flowchart LR Operator --Sends transtaction--> dao["Executor DAO"] dao --as-contract--> i["Proposal contract"] i --contract-call--> sm[Staking Manager] sm -.-o box[["**tx-sender**: Executor DAO **contract-caller**: Proposal contract"]] ``` ### Mechanics In the Staking Manager, the staker is represented by the `tx-sender`. As explained above, depending on the intermediary contract design, the staker may either be an end user or the endpoint/façade acting on behalf of the user. Therefore, every reference to "staker" (or `user`, as defined within the contract) applies to any of these two possibilities. Upon staking, the shares corresponding to the amount being staked are calculated and stored in the [`user-shares`](#user-shares) map. This is the staking position and represents the user's portion of the total amount staked. During this operation, the amount to stake is transferred from the `tx-sender` to the Staking Manager, and since the total amount staked and total shares increased, the contract updates its internal state to reflect the changes. Refer to the [`stake`](#stake) function for detailed information. Unstaking performs the inverse operations. It first calculates the shares that correspond to the amount willing to unstake. Then, the unstaked amount is transferred from the Staking Manager to the `tx-sender` and, finally, state upates are performed to decrease user shares, total shares and total amount staked. > **Info:** Note that both **staking** and **unstaking** operations involve shares management and update the staking status of the involved token across three dimensions: total shares, total amount staked and user's share-based staking position. Staking and unstaking shouldn't affect share's price. #### Token amount to shares conversion On every staking and unstaking action, an amount-to-shares conversion is perfomed using the following equation: $$ \textrm{Shares} = \frac{\textrm{Amount}}{\textrm{Total Staked}} ; \cdot ; \textrm{Total Shares}. $$ This is how [`get-shares-given-amount`](#supporting-features) function works. The ratio between the total staked amount and the total shares determines the "share price" in token units, i.e., how many tokens one share represents: $$ \textrm{Price} = \frac{\textrm{Total Staked}}{\textrm{Total Shares}} $$ Before completing a staking or unstaking operation, these two values are updated in a way that the share price remains constant. In contrast, reward accrual operations modify this price by maintaing total shares constant and incresing the total staked value.
How does the share price remain constant after staking/unstaking operations? The price formula shows that the share price is the ratio between the staked tokens amount and the shares amount. Staking adds tokens, so to maintain the price, shares are issued at the price before the staking state update. Analogously, unstaking removes tokens, and to preserve the price, shares are burned at the same price as before the unstaking state update.
## Roles * **Validators**: Trusted entities responsible for maintaining the system's integrity and synchronization. In the context of the Brotocol Staking Manager, they generate proofs of reward reinvestment on the external staking protocol. * **Updaters**: Actors resposible for submitting validator proofs to update the total staked value for any token in the system. * **Governance**: Includes DAO and its enabled extensions. These roles are authenticated via the [`is-dao-or-extension`](#is-dao-or-extension) function. Extensions are authenticated as `contract-caller`, while the DAO is authenticated as the `tx-sender` for proposal execution scenarios. ## Tokens Each token within the Staking Manager has the following attributes. * **Implementation contract**: The Stacks principal indicating the token's implementation contract, which needs to be approved in the [`approved-tokens`](#approved-tokens) map. * **Total staked**: The total staked amount, tracked in the [`total-staked`](#total-staked) map. * **Accrued rewards**: The total amount of rewards already restaked, tracked in the [`accrued-rewards`](#accrued-rewards) map. * **Total shares**: The total amount of shares issued for the token, tracked in the [`total-shares`](#total-shares) map. * **Staker registry**: The record of each staker's shares, where the sum of all staker shares equals the total shares. This ownership is tracked in the [`user-shares`](#user-shares) map. ## Features ### Main operations These operations are privileged and protected by the [`is-dao-or-extension`](#is-dao-or-extension) function, allowing only governance roles to execute them. However, the [`add-rewards`](#add-rewards) function is more permissive than staking and unstaking, also allowing approved updaters as callers (`tx-sender`). #### `add-rewards` Adds accrued staking rewards for a specific token. The function requires a message `{ token: principal, accrued-rewards: uint, update-block: uint }` signed by a sufficient number of approved validators ([`required-validators`](#required-validators)). The message must be proccessed within a block range determined by the `update-block` value and [`block-threshold`](#block-threshold) variable, or it is considered expired. Actions performed: * Calculates the difference (`delta`) between the previous and the updated amount of accrued rewards, given by the `accrued-rewards` value of the message. Mints the `delta` amount to the `xlink-staking` contract's balance to account for the new staked amount. * Updates the [`accrued-rewards`](#accrued-rewards) and [`total-staked`](#total-staked) maps. * Emits an `"add-rewards"` log with a detailed payload. **Parameters** | Name | Type | | ----------------- | --------------------------------------------------------------------------------- | | `message` | `{ token: principal, accrued-rewards: uint, update-block: uint }` | | `token-trait` | `` | | `signature-packs` | `list 100 { signer: principal, message-hash: (buff 32), signature: (buff 65) }))` | #### `stake` Allows users to stake a specified token amount. Actions performed: * Calls `add-rewards` to update the total staked value if needed. Note this is very important since the `total-staked` value of the token is utilized to calculate the shares. * Calculates `shares` corresponding to the newly stake amount. * Transfers the specified amount from the `tx-sender` (user) to the `xlink-staking` contract. * Updates the `user-shares`, `total-shares` and `total-staked` maps. * Emits a `"stake"` log with a detailed payload (user, token, updated values). **Parameters** | Name | Type | | ----------------- | --------------------------------------------------------------------------------- | | `token-trait` | `` | | `amount` | `uint` | | `message` | `{ token: principal, accrued-rewards: uint, update-block: uint }` | | `signature-packs` | `list 100 { signer: principal, message-hash: (buff 32), signature: (buff 65) }))` | #### `unstake` Allows users to unstake a specified token amount. Actions performed: * As in [`stake`](#stake), calls `add-rewards` to update the total staked value if needed. * Calculates `shares` corresponding to the amount to unstake. * Transfers the specified amount from the `tx-sender` (user) to the `xlink-staking` contract. * Updates the `user-shares`, `total-shares` and `total-staked` map. * Emits an `"unstake"` log with a detailed payload (user, token, updated values). **Parameters** | Name | Type | | ----------------- | --------------------------------------------------------------------------------- | | `token-trait` | `` | | `amount` | `uint` | | `message` | `{ token: principal, accrued-rewards: uint, update-block: uint }` | | `signature-packs` | `list 100 { signer: principal, message-hash: (buff 32), signature: (buff 65) }))` | ### Governance These features are protected by the [`is-dao-or-extension`](#is-dao-or-extension) function and resticted to the Brotocol DAO or its enabled extensions. #### `withdraw` Withdraws an amount of any approved token and deducts it from the total staked amount. This function serves as an emergecy mechanism designed to adjust protocol values if necessary, though such a situation is considered rare. Actions performed: * Transfers the specified amount from the `xlink-staking` contract to the `tx-sender`. * Updates the `total-staked` map. * Emits a `"withdraw"` log and a payload. **Parameters** | Name | Type | | ------------- | ------------ | | `token-trait` | `` | | `amount` | `uint` | #### `set-paused` Sets the [`is-paused`](#is-paused) variable. **Parameters** | Name | Type | | -------- | ------ | | `paused` | `bool` | #### `set-approved-token` Sets the approval status of a token within the Staking Manager. Modifies the [`approved-tokens`](#approved-tokens) map. **Parameters** | Name | Type | | ---------- | ----------- | | `token` | `principal` | | `approved` | `bool` | #### `set-approved-updater` Sets the approval status of an updater. Modifies the [`approved-updaters`](#approved-updaters) map. **Parameters** | Name | Type | | ---------- | ----------- | | `updater` | `principal` | | `approved` | `bool` | #### `set-block-threshold` Sets the [`block-threshold`](#block-threshold) variable. **Parameters** | Name | Type | | ----------- | ------ | | `threshold` | `uint` | #### `set-accrued-rewards` Permissionlessly sets the accrued rewards value of a certain `token` key in the [`accrued-rewards`](#accrued-rewards) map. Note this function potentially overwrites the value updatead via the [`add-rewards`](#add-rewards) function. **Parameters** | Name | Type | | --------- | -------------------------------------- | | `token` | `principal` | | `details` | `{ amount: uint, update-block: uint }` | #### `set-required-validators` Sets the [`set-required-validators`](#required-validators) variable. **Parameters** | Name | Type | | ---------- | ------ | | `required` | `uint` | #### `add-validator` Adds a new `validator` key in the [`validators-registry`](#validators-registry) map. Values cannot be modified if the key already exists, since the the update is performed with the [`map-insert`](https://docs.stacks.co/reference/functions#map-insert) Clarity function. **Parameters** | Name | Type | | ----------- | ----------------------------------------- | | `validator` | `principal` | | `details` | `{ token: principal, pubkey: (buff 33) }` | #### `remove-validator` Removes an entry in the [`validators-registry`](#validators-registry) map, using the [`map-delete`](https://docs.stacks.co/reference/functions#map-delete) Clarity function. **Parameters** | Name | Type | | ----------- | ----------- | | `validator` | `principal` | ### Supporting features #### `is-dao-or-extension` Standard protocol function to check whether the `contract-caller` is an enabled extension within the DAO or the `tx-sender` is the DAO itself (proposal execution scenario). The enabled extension check is delegated to the Brotocol's `executor-dao` contract. #### Staking validation * `validate-stake` * `validate-unstake` #### Shares conversion * `get-shares-given-amount` * `get-amount-given-shares` #### Message handling * `message-domain` * `create-oracle-message` * `decode-oracle-message` * `hash-oracle-message` ### Getters Getter functions to retrieve all the [storage](#storage) variables and values within each map. For maps related to validators, an error is thrown if the principal is not present as a key within the [`validators-regitry`](#validators-registry). In contrast, for token maps, a default value is returned if the principal is not found. #### Variables * `get-paused` * `get-block-threshold` * `get-required-validators` #### Maps * `get-validator-or-fail` * `get-approved-token-or-default` * `get-shares-or-default` * `get-total-shares-or-default` * `get-total-staked-or-default` * `get-accrued-rewards-or-default` * `get-approved-updater-or-default` ## Storage ### `is-paused` | Data | Type | | -------- | ------ | | Variable | `bool` | Indicates the operational status of the main contract operations: [`add-rewards`](#add-rewards), [`stake`](#stake) and [`unstake`](#unstake). ### `approved-tokens` | Data | Type | | ---- | ---------------- | | Map | `principal bool` | Maintains a mapping of token contracts (`principal`) to their approval status (`bool`) within the Staking Manager. ### `user-shares` | Data | Type | | ---- | -------------------------------------------- | | Map | `{ user: principal, token: principal } uint` | Tracks the number of shares held by each staker (`user`) for a specific `token`. ### `total-staked` | Data | Type | | ---- | ---------------- | | Map | `principal uint` | Tracks the total value staked for each token contract (`principal`). ### `total-shares` | Data | Type | | ---- | ---------------- | | Map | `principal uint` | Tracks the total shares issued for each staking token (`principal`). ### `validators-registry` | Data | Type | | ---- | --------------------------------------------------- | | Map | `principal { token: principal, pubkey: (buff 33) }` | Maintains a mapping of the registered validators. Each one is identified by a Stacks `principal` and has associated `token` and public key used for message signature verification. ### `required-validators` | Data | Type | | -------- | ------ | | Variable | `uint` | Indicates the minimum number of validators required to sign a message for it to be considered valid. ### `accrued-rewards` | Data | Type | | ---- | ------------------------------------------------ | | Map | `principal { amount: uint, update-block: uint }` | Tracks the total rewards that have been collected and restaked for each token, identified by its contract `principal`. The `update-block` field records the [`stacks-block-height`](https://docs.stacks.co/reference/keywords#stacks-block-height) of the last update. This map plays a key role in the [`add-rewards`](#add-rewards) function mechanism. ### `block-threshold` | Data | Type | | -------- | ------ | | Variable | `uint` | Specifies the number of Stacks blocks allowed as a delay for submitting an [`add-rewards`](#add-rewards) message. ### `approved-updaters` | Data | Type | | ---- | ---------------- | | Map | `principal bool` | Maps updaters (`principal`) to their approval status (`bool`). ### Relevant constants #### `ONE_8` | Type | Value | | ------ | ------------ | | `uint` | `u100000000` | Mathematical constant used to restrict the decimal precision to 8 digits. #### `MAX_REQUIRED_VALIDATORS` | Type | Value | | ------ | ----- | | `uint` | `u20` | Defines the upper bound for the [`required-validators`](#required-validators) variable. ## Contract calls * ``: Interaction with any approved token to perform mint actions ([`add-rewards`](#add-rewards)) and transfers (mostly within [`stake`](#stake) and [`unstake`](#unstake), but also within the [`withdraw`](#withdraw) governance function). The `ft-trait` within the contract is the custom SIP-010 implementation for handling fixed notation, available at `'SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.trait-sip-010`. * `'SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.executor-dao`: This contract is exclusively called by the [`is-dao-or-extension`](#is-dao-or-extension) function for authorizing governance operations. ## Errors | Error Name | Value | | ---------------------------------- | ------------- | | `err-not-authorised` | `(err u1000)` | | `err-paused` | `(err u1001)` | | `err-unknownvalidator` | `(err u1006)` | | `err-validator-already-registered` | `(err u1008)` | | `err-hash-mismatch` | `(err u1010)` | | `err-invalid-signature` | `(err u1011)` | | `err-message-to-old` | `(err u1012)` | | `err-invalid-block` | `(err u1013)` | | `err-required-validators` | `(err u1015)` | | `err-invalid-validator` | `(err u1016)` | | `err-invalid-input` | `(err u1017)` | | `err-token-mismatch` | `(err u1018)` | | `err-invalid-amount` | `(err u1019)` | | `err-update-failed` | `(err u1020)` | | `err-duplicated-signatures` | `(err u1021)` | # EVM ## Introduction This document outlines the main functionalities of the Brotocol Bridge as deployed on EVM-compatible blockchains. The core aspects of the bridging operation are implemented in the `BridgeEndpoint` contract, which acts as the main entry and exit point for cross-chain operations, ensuring that assets are securely locked, minted/burned, transferred, and released. The `BridgeEndpointWithSwap` contract extends this functionality by incorporating swaps, allowing bridging and swapping to occur in within a single transaction. The Brotocol ecosystem offers two main features in its EVM implementation: * The **bridging of ERC-20 assets**: these contracts interact with Brotocol's off-chain protocol actors to allow the transfer of assets back and forth between EVM-compatible blockchains and Stacks. * The **swapping of tokens in the bridging process** via external liquidity aggregators. ### EVM Chain Bridge ![This is a simplified representation on the EVM Chain Bridge's main goal.](/files/fwfNR3NqW1uSBXo7cHed) \*To see more information on the registry contract, see the [auxiliary contracts section](#auxiliary-contracts). #### Bridge Endpoint * Contract names: `BridgeEndpoint`, `BridgeEndpointWithSwap`. * [Complete technical documentation](/developers/brotocol-contracts/chains/evm/bridgeendpoint) This endpoint's main responsibility is serving as the entry and exit point for assets moving along Brotocol's cross-chain bridge. Sometimes, it also involves swapping to other tokens as part of the peg-in process. ### Auxiliary Contracts These contracts do not include the implementation of any core functionality but they serve as a support for other contracts to facilitate calculations and common storage management. * **Bridge Registry**: this contract keeps a record of approved tokens, validators, relayers and fees. It also keeps a record of the generated orders and their statuses. Its latest version can be found at `BridgeRegistry.sol`. # Bridge Endpoint * Location: `./packages/contracts/bridge-solidity/contracts` * Deployed contracts: See [Ethereum Contract Addresses](https://github.com/Brotocol-xyz/xlink/blob/main/site/documentation/contracts/ethereum-contract-addresses.md). This technical document provides a detailed overview of the Bridge Endpoint in EVM-compatible blockchains. The Bridge Endpoint facilitates communication between two blockchain networks by acting as the entry and exit point for assets moving along the Cross Chain Bridge. It passes messages between chains in the form of events, triggers contract calls, processes token transfers and validates and executes the unwrapping of tokens. `BridgeEndpointWithSwap` extends `BridgeEndpoint` and implements the necessary features to source liquidity from external aggregators. This Bridge Endpoint functionality is implemented and distributed across the following contracts: * `BridgeEndpoint`: the base contract that facilitates bridging operations. * `BridgeEndpointWithSwap`: extends `BridgeEndpoint` and integrates swaps during a bridge transfer. ## Storage ### `registry` | Data | Type | | -------- | ---------------- | | Variable | `BridgeRegistry` | Stores a reference to the `BridgeRegistry` contract, which manages approved tokens, relayers, and validators. ### `pegInAddress` | Data | Type | | -------- | --------- | | Variable | `address` | The address in which non-burnable tokens from peg-out orders are stored before they are bridged out of the EVM-compatible blockchain. The user calls [`sendMessageWithToken`](#sendmessagewithtoken), which deducts a fee and transfers the remaining non-burnable tokens to `pegInAddress`. This address also provides the funds for non-burnable peg-in orders. ### `timeLock` | Data | Type | | -------- | ----------- | | Variable | `ITimeLock` | Manages locked transactions that require a delay before execution. Tokens amounts that exceed the threshold are not immediately sent to the user. Instead, the `timeLock` contract holds them until the waiting period expires. At that point, the `timeLock` owner can fulfill the order, completing the cross-chain transfer. ### `timeLockThreshold` | Data | Type | | -------- | --------- | | Variable | `uint256` | The global minimum token amount that triggers a timelock. By default, the value is set to `0`. ### `timeLockThresholdByToken` | Data | Type | | -------- | ----------------------------- | | Variable | `mapping(address => uint256)` | Optional custom timelock thresholds for different tokens. The timelock will be triggered when a token amount exceeds the custom threshold, if applicable. If no custom threshold is set, the token amount will need to exceed the global threshold set in [`timeLockThreshold`](#timelockthreshold). ### `unwrapSent` | Data | Type | | -------- | ---------------------------------- | | Variable | `mapping(bytes32 => OrderPackage)` | Stores unwrap orders that need to be finalized. It stores a mapping of [`OrderPackage`](#orderpackage) structs, which contain a flag indicating whether the unwrap has been completed. `bytes32` is a unique hash of the struct parameters, as calculated by [`transferToUnwrap`](#transfertounwrap). ### `swapExecutor` ***(only present in BridgeEndpointWithSwap)*** | Data | Type | | -------- | -------------- | | Variable | `SwapExecutor` | Holds a reference to `SwapExecutor`, which is the contract that executes swaps. ### `swapSent` ***(only present in BridgeEndpointWithSwap)*** | Data | Type | | -------- | -------------------------------------- | | Variable | `mapping(bytes32 => SwapOrderPackage)` | A mapping of [`SwapOrderPackage`](#swaporderpackage) structs that contains details of swap orders.`bytes32` is a unique hash of the swap parameters, as calculated by [`transferToSwap`](#transfertoswap). ## Data Types #### `OrderPackage` Holds details of a pending unwrap operation. ```solidity struct OrderPackage { address recipient; address token; uint256 amount; bool sent; } ``` #### `SignaturePackage` Contains signatures from validators to prove an order is legitimate. It is used for verifying cross-chain transfers. ```solidity struct SignaturePackage { bytes32 orderHash; address signer; bytes signature; } ``` #### `SwapOrderPackage` ***(only present in BridgeEndpointWithSwap)*** A struct that stores details of a swap order. ```solidity struct SwapOrderPackage { address target; address tokenIn; address tokenOut; uint256 amountIn; uint256 amountOutMin; bytes bridgePayloadSuccess; bytes bridgePayloadFailure; bool sent; } ``` ## Modifiers * `onlyApprovedToken(token)`: ensures the token is approved in the registry. * `onlyApprovedRelayer()`: ensures the caller is an approved relayer. * `notWatchlist(recipient)`: prevents transfers to watchlisted addresses. * `nonReentrant`: protects against reentrancy attacks. * `onlyAllowlisted`: ensures only allowed addresses can execute certain functions. ## Features #### `sendMessageWithToken` This function is called to initiate the peg-out process from an EVM-compatible blockchain onto other chains, such as Stacks or Bitcoin. The user deposits tokens in the bridge contract, which are burned or locked, depending on the token. The contract checks that the token is approved, since [`sendMessageWithToken`](#sendmessagewithtoken) has the `onlyApprovedToken` modifier. The function calls [`_transfer`](#_transfer), which performs validations. Finally, the function emits a [`SendMessageWithTokenEvent`](#sendmessagewithtokenevent) containing the transaction details, which will be reviewed by validators. Once they verify that the tokens were deposited in the `BridgeEndpoint` contract, the validators will sign the order and relayers will submit it in the destination chain. **Parameters** ```solidity address token, uint256 amount, bytes calldata payload ``` #### `sendMessage` Emits an event with a message. **Parameters** ```solidity bytes calldata payload ``` #### `transferToUnwrap` This function is called by a relayer when a user initiates a token transfer from another blockchain. The originating order may come from an EVM chain (via [`sendMessageWithToken`](#sendmessagewithtoken)), or from a non-EVM chain like Stacks, Bitcoin or Solana. Relayers listen for the corresponding event on the source chain and call [`transferToUnwrap`](#transfertounwrap) on the destination chain, supplying the recipient, token, amount, a salt (usually the source chain transaction), and an array of validator signatures (proofs). The contract verifies these proofs and generates an EIP-712-compliant hash, which acts as a unique identifier for each order. **Parameters** ```solidity address token, address recipient, uint256 amount, bytes32 salt, SignaturePackage[] calldata proofs ``` #### `finalizeUnwrap` This function completes a pending unwrap order for non-burnable tokens. It is called by a hot wallet address once the timeLock period expires, which transfers the tokens to the recipients and finalizes peg-in orders. It loops through each `orderHash` and calls [`_finalizeUnwrap()`](#_finalizeunwrap), which verifies that the order has not already been completed and transfers the token and amount stored in [`unwrapSent`](#unwrapsent) to the recipient. The order is then marked as completed, and the [`FinalizeUnwrapEvent`](#finalizeunwrapevent) is emitted. **Parameters** ```solidity bytes32[] calldata orderHash ``` #### `transferToSwap` ***(in contract BridgeEndpointWithSwap)*****\`** This function executes a swap before bridging tokens. If the token is burnable, the contract mints the required amount before swapping, calls [`_executeSwap`](#_executeswap) to perform the swap and emits a [`TransferToSwapEvent`](#transfertoswapevent) recording the details. If it is not burnable, it saves swap details in the [`swapSent`](#swapsent) mapping and emits [`SwapOrderCreated`](#swapordercreated) so the swap can be finalized later. In either case, the function will validate token and relayer permissions and generate a unique EIP-712 hash to identify the swap. **Parameters** ```solidity address target, address tokenIn, address tokenOut, uint256 amountIn, uint256 amountOutMin, bytes calldata swapPayload, bytes calldata bridgePayloadSuccess, bytes calldata bridgePayloadFailure, bytes32 salt, SignaturePackage[] calldata proofs ``` #### `finalizeSwap` ***(in contract BridgeEndpointWithSwap)*****\`** This function is used when a token is not burnable, leading [`transferToSwap`](#transfertoswap) to store the swap order instead of executing it immediately. It ensures input arrays are valid, and it loops through each `orderHash` and calls [`_finalizeSwap()`](#_finalizeswap). **Parameters** ```solidity bytes32[] calldata orderHashes, bytes[] calldata swapPayloads ``` ### Governance Features #### `setTimeLock` Updates the contract managing timelocks. **Parameters** ```solidity address _timeLock ``` #### `setTimeLockThreshold` Sets the global timelock threshold. **Parameters** ```solidity uint256 _timeLockThreshold ``` #### `setTimeLockThresholdByToken` Sets a custom timelock threshold per token. **Parameters** ```solidity address token, uint256 _timeLockThreshold ``` #### `addAllowList` Adds an address to the allowlist, granting it permission to perform specific contract actions. #### `removeAllowedList` Removes an address from the allowlist, revoking its access. **Parameters** ```solidity address account ``` #### `pause` Pauses the contract, preventing token transfers until the contract is unpaused. #### `unpause` Resumes contract operations after a pause, allowing bridging and transfers again. ### Read-Only Functions #### `offAllowList` Returns `true` if the provided address is not on the allowlist. **Parameters** ```solidity address account ``` #### `onAllowList` Returns `true` if the provided address is on the allowlist, which means it has permission to use the contract’s functions. ### Relevant Internal Functions #### `_transfer` This internal function is responsible for processing token transfers when a user sends tokens into the bridge. It is called from [`sendMessageWithToken`](#sendmessagewithtoken) and performs validations, calculates and deducts fees, and sends the correct amount of tokens to the `pegInAddress`. This function ensures the transfer amount is within allowed limits and that it is large enough to cover the minimum fee. If the token is burnable, it burns the amount minus the fee. Otherwise, it transfers the same amount to the `pegInAddress`. In either case, the fee is sent to the `BridgeRegistry` contract. **Parameters** ```solidity address token, uint256 amount ``` #### `_validateOrder` Verifies if an order is legitimate by checking validator signatures. **Parameters** ```solidity bytes32 orderHash, SignaturePackage[] calldata proofs ``` #### `_finalizeUnwrap` Completes an unwrap transaction by transferring tokens to the recipient. **Parameters** ```solidity bytes32 orderHash ``` #### `_finalizeSwap` ***(in contract BridgeEndpointWithSwap)*****\`** This function is called by [`finalizeSwap`](#finalizeswap) to retrieve a stored swap order and to execute the swap. It checks if the order exists and has not been executed, transfers `amountIn` tokens from the sender to the `BridgeEndpointWithSwap` contract and calls [`_executeSwap`](#_executeswap) to perform the swap. Finally, it marks the order as sent and emits a [`SwapOrderFinalized`](#swaporderfinalized) event. **Parameters** ```solidity bytes32 orderHash, bytes memory swapPayload ``` #### `_executeSwap` ***(in contract BridgeEndpointWithSwap)*****\`** This function approves `swapExecutor` to spend `tokenIn` and calls its `executeSwap()` function to attempt the swap. If the swap succeeds, it either burns the swapped tokens or prepares them for transfer. To transfer the tokens, `tokenOut` is sent to [`pegInAddress`](#peginaddress) for bridging and a [`SendMessageWithTokenEvent`](#sendmessagewithtokenevent) is emitted. If the swap fails, the error is logged via `SwapExecutorError`, approvals are revoked and a [`SendMessageWithTokenEvent`](#sendmessagewithtokenevent) with `bridgePayloadFailure` is emitted. In either case, the function will burn `tokenIn` tokens if applicable. **Parameters** ```solidity address tokenIn, address tokenOut, address target, uint256 amountIn, uint256 amountOutMin, bytes memory swapPayload, bytes memory bridgePayloadSuccess, bytes memory bridgePayloadFailure ``` ## Events #### `SendMessageEvent` Emitted when a user sends a message without transferring tokens. **Parameters** ```solidity address indexed from, uint256 value, bytes payload ``` #### `SendMessageWithTokenEvent` Emitted when a user initiates a peg-out order. **Parameters** ```solidity address indexed from, address indexed token, uint256 amount, uint256 fee, bytes payload ``` #### `TransferToUnwrapEvent` Emitted when an order is created to unwrap tokens. This event is emitted when an order is validated and tokens have to be transfered to a recipient. **Parameters** ```solidity bytes32 orderHash, bytes32 salt, address indexed recipient, address indexed token, uint256 amount ``` #### `FinalizeUnwrapEvent` Emitted when an unwrap order is finalized and tokens are successfully transferred to the recipient. **Parameters** ```solidity bytes32 indexed orderHash ``` #### `SetTimelockEvent` Emitted when [`timeLock`](#timelock) is updated by the contract owner. **Parameters** ```solidity address timeLock ``` #### `SetTimeLockThresholdEvent` Emitted when the global time lock threshold is updated. **Parameters** ```solidity uint256 timeLockThreshold ``` #### `SetTimeLockThresholdByTokenEvent` Emitted when the time lock threshold for a specific token is updated. **Parameters** ```solidity address token, uint256 timeLockThreshold ``` #### `SwapExecutorError` ***(only present in BridgeEndpointWithSwap)*** Emitted when a swap operation fails during the bridge transfer. **Parameters** ```solidity address indexed target, bytes reason ``` #### `SwapOrderCreated` ***(only present in BridgeEndpointWithSwap)*** Emitted when a new swap order is created for non-burnable tokens. It logs the creation of swap orders, helping to track them before execution. **Parameters** ```solidity bytes32 indexed orderHash, address indexed target, address indexed tokenIn, address tokenOut, uint256 amountIn, uint256 amountOutMin, bytes bridgePayloadSuccess, bytes bridgePayloadFailure ``` #### `SwapOrderFinalized` ***(only present in BridgeEndpointWithSwap)*** Emitted when a swap order is executed and finalized, confirming a swap has been processed. **Parameters** ```solidity bytes32 indexed orderHash, address indexed executor, uint256 amountOut, bool success ``` #### `TransferToSwapEvent` ***(only present in BridgeEndpointWithSwap)*** Emitted when a token transfer and swap operation is executed. **Parameters** ```solidity bytes32 orderHash, address target, bytes swapPayload, address tokenIn, address tokenOut, uint256 amountIn, uint256 amountOut, bool success ``` ## Contract Calls (Interactions) * `BridgeRegistry`: this contract is called to process orders and to manage validator roles and fees. It acts as the central registry for approved tokens, relayers and validators. * `ITimeLock`: the `ITimeLock` interface is utilized to interact with the [`timeLock`](#timelock) contract by calling the `createAgreement` function when bridged amounts exceeds the threshold. * `IBurnable`: this interface is used for burnable tokens to enable mint and burn operations. * `ERC20`: all approved tokens within the bridge must implement the `ERC20Fixed` standard, which is an Brotocol's custom standard that extends ERC-20 to handle fixed precision. Token contract interactions occur in both peg-in and peg-out operations for non-burnable tokens, using the `transferFromFixed`, `transferFixed`, and `increaseAllowanceFixed` functions. * `SwapExecutor`: this contract is called by `BridgeEndpointWithSwap` to execute swaps with external liquidity aggregators during bridging. # Security Audits As with all crypto technology, risk is real whether using a centralized or decentralized bridge. Some of the more novel decentralized bridges are relatively untested and even those that have been tested are still subject to exploits. Brotocol is audited by [CoinFabrik](https://www.coinfabrik.com/) and [Defence](https://thesis.co/defense), covering both the contracts and the backends. * [2022-12 Bridge Endpoints](https://cdn.xlink.network/pdf/ALEX_Audit_bridge_coinfabrik_202212.pdf) * [2023-04 Bridge Backend and Endpoints](https://cdn.xlink.network/pdf/ALEX_Audit_Bridge_2023-04.pdf) * [2023-10 Bitcoin Oracle and Bridge](https://cdn.xlink.network/pdf/ALEX_Audit_202310_Bitcoin_Oracle_and_Bridge.pdf) * [2024-06 BridgeEndpoint, BridgeRegistry and BridgeEndpointWithAxelar](https://cdn.xlink.network/pdf/XLink_Bridge_Endpoint_Audit_2024-06.pdf) * [2024-06 MultisigWallet and BridgeToken](https://cdn.xlink.network/pdf/XLink_MultisigWallet_BridgeToken_2024-06.pdf) * [2024-11 Brotocol Staking Manager](https://cdn.xlink.network/pdf/XLINK_Staking_Audit_2024_11_final.pdf) * [2024-11 Brotocol Peg-out Endpoints](https://cdn.xlink.network/pdf/XLINK_Peg-out_Endpoints_Audit%2011-2024.pdf) * [2024-11 Brotocol Peg-in Endpoints](https://cdn.xlink.network/pdf/XLINK_Peg-in_Endpoints_Audit_11-2024.pdf) * [2025-03 Endpoint Update](https://cdn.brotocol.xyz/pdf/XLink_Endpoits_Update_Audit_2025-03.pdf) * [2025-04 EVM Endpoints](https://cdn.brotocol.xyz/pdf/XLink_EVM_Endpoint_Audit_2025-04.pdf) * [2025-05 Solana Endpoints](https://cdn.brotocol.xyz/pdf/XLINK_Solana_Endpoint_Audit_2025-05.pdf) * [2025-08 EVM BridgeEndpoint](https://cdn.brotocol.xyz/pdf/250825_Defense_by_Thesis_Brotocol_BridgeEndPoint_Smart_Contract.pdf) # Official Links 🌐 Website: 📝 Medium: 🎮 Discord: 💬 Telegram: 🐦 𝕏: 🎨 Download Brotocol Media Kit: # BroSDK # Supported Blockchains and Tokens We list below the different bridgable tokens with Brotocol. > **Important:** Users can only bridge tokens that represent the **same asset** across different blockchains. > > For example, BTC can be transferred to its equivalent, WBTC, when moving from Bitcoin to an EVM network, as both represent the same asset on different chains. | **AILayer** | aBTC, ALEX, aUSD, uBTC, vLiALEX, vLiSTX | | ------------ | ---------------------------------------------------------------------------------------------------------------------------- | | **Arbitrum** | aBTC, WBTC, ALEX, aUSD, uBTC, vLiALEX, vLiSTX | | **Aurora** | aBTC, ALEX, aUSD, vLiALEX, vLiSTX | | **B²** | aBTC, ALEX, aUSD, uBTC, vLiALEX, vLiSTX | | **Bitcoin** | BTC | | **Bitlayer** | aBTC, ALEX, aUSD, uBTC, vLiALEX, vLiSTX | | **BNB** | aBTC, ALEX, BTCB, aUSD, SKO, USDT, uBTC | | **BOB** | aBTC, ALEX, aUSD, uBTC, vLiALEX, vLiSTX | | **Core** | aBTC, ALEX, aUSD, uBTC, vLiALEX, vLiSTX | | **Ethereum** | ALEX, aUSD, WBTC | | **Lorenzo** | aBTC, ALEX, aUSD, vLiALEX, vLiSTX | | **Merlin** | aBTC, ALEX, aUSD, uBTC, vLiALEX, vLiSTX | | **Mode** | aBTC, ALEX, aUSD, uBTC, vLiALEX, vLiSTX | | **Runes** | DOG•GO•TO•THE•MOON, ETHEREUM•ON•BITCOIN, MAKE•BITCORN•GREAT•AGAIN, NOT•GONNA•MAKE•IT, SATOSHI•NAKAMOTO•INU, WELSH•CORGI•COIN | | **Stacks** | aBTC, ALEX, DOG•GO•TO•THE•MOON, ETHEREUM, NOT, PEPE, SATOSHI•NAKAMOTO•INU, SKO, aUSD, uBTC, vLiALEX, vLiSTX, WELSH | | **X Layer** | aBTC, ALEX, aUSD, uBTC, vLiALEX, vLiSTX | | Base | aBTC, cbBTC, aUSD, ALEX, uBTC, vLiALEX, vLiSTX |