# Welcome {% hint style="warning" %} **Feedback** This document is being continuously updated as feedback is captured from readers like you. In case you have any feedback, it can be given on our [Telegram channel](https://t.me/+sp8J07DEGTxmNjc0) or on [Discord](https://botanixlabs.xyz/en/r/discord). {% endhint %} Hello and welcome to the official documentation for Botanix, the first fully decentralized Bitcoin-based blockchain! Whether you're new to blockchain technology, an experienced developer, or someone looking to contribute to the network infrastructure, this documentation will guide you through everything you need to know about Botanix. ### Your Journey Starts Here If you're completely new to Botanix, our **User Tutorials** section is the perfect starting point. Here you'll learn how to set up your first wallet, bridge assets to the network, and start exploring the Bitcoin Economy that Botanix enables. These step-by-step guides will have you up and running in no time, regardless of your technical background. For those wanting to understand what makes Botanix special, the **Get to Know Botanix** section dives deep into the core concepts that power our network. You'll discover how the Spiderchain protocol works, understand our unique approach to Bitcoin scaling, and explore our roadmap for the future. This section bridges the gap between basic usage and technical implementation. Developers ready to start building will find everything they need in our **Build dApps** section. From setting up your development environment to deploying smart contracts on the Botanix EVM, this comprehensive guide covers all the tools, frameworks, and resources you'll need to create innovative applications on our network. If you're interested in supporting the network infrastructure, the **Run a Node** section provides detailed instructions for setting up and maintaining both federation and RPC nodes. Running a node is a crucial way to contribute to Botanix's decentralization and security. Finally, the **About Botanix Labs** section introduces you to the team behind the network. Learn about our mission, meet the people building the future of Bitcoin, and understand the vision driving Botanix forward. ### What Makes Botanix Different Botanix represents a breakthrough in blockchain technology by combining Bitcoin's legendary security with Ethereum's smart contract capabilities. Through the innovative Spiderchain protocol, we've created a network that doesn't compromise on either security or functionality. This isn't just another layer-2 solution – it's a fundamental reimagining of what's possible when you build on Bitcoin's foundation. ### Ready to Explore? Each section of this documentation builds naturally on the others, but you're free to jump to whatever interests you most. New users should start with the tutorials, curious minds should explore our concepts section, developers can dive straight into building, and infrastructure enthusiasts can head to the node operation guides. This documentation evolves continuously based on community feedback and network updates. If you have questions, suggestions, or just want to connect with other Botanix users and developers, don't hesitate to join our community discussions. *** *Welcome to the Botanix network* # Overview This section walks you through everything you need to get started with Botanix as a user: 1. [Chain information](/botanix/user-tutorials/chain-information) 2. [Set up a wallet](/botanix/user-tutorials/step-by-step/step-1-set-up-a-wallet) 3. [Bridge Bitcoin to Botanix](https://docs.botanixlabs.com/bridge/getting-started/prerequisites) 4. [Earn Bitcoin Yield](https://docs.botanixlabs.com/bitcoin-yield/getting-started/prerequisites) 5. [Discover the rest of the Ecosystem](https://botanixlabs.com/use) If you run into a problem, join our [Discord](https://botanixlabs.xyz/en/r/discord) where you can ask your questions. {% hint style="info" %} **Want to Build on Botanix?** Visit our [Builder's section](/botanix/build-applications/introduction). {% endhint %} # Chain Information
ParameterValue
Network NameBotanix
Chain ID3637
SymbolBTC
Explorerhttps://botanixscan.io/
RPC URLhttps://rpc.ankr.com/botanix_mainnet
https://rpc.botanixlabs.com
# Step-by-step # Step 1 - Set up a wallet ## Install an EVM wallet[​](https://docs.linea.build/use-mainnet/set-up-your-wallet#install-metamask) Botanix is fully EVM compatible. Because of that, **it works with all EVM wallets right out of the box**, such as [OKX](https://www.okx.com/en-us/download), [Rabby](https://rabby.io/), [Safe](https://app.safe.global/welcome) or [MetaMask](http://metamask.io/). {% hint style="info" %} **Things to Consider When Choosing a Web3 Wallet** Choosing the right Web3 wallet is key to safely managing your crypto, NFTs, and interacting with decentralized apps (dApps). Here are a few things to keep in mind: **Security** — Look for wallets with strong security features like private key control, seed phrases, and hardware support. Remember: *not your keys, not your coins*. **Compatibility** — Make sure the wallet supports the blockchains and tokens you use. **Ease of Use** — Some wallets are beginner-friendly, while others offer advanced features for experienced users. **Backup & Recovery** — Check how you can back up your wallet and recover access if you lose your device. Never share your seed phrase! **dApp Integration** — If you want to explore DeFi, NFTs, or DAOs, pick a wallet with good browser or app integration. **Open Source & Reputation** — Prefer wallets with open-source code and a solid reputation in the community. {% endhint %} ## Connect to Botanix There are two different ways you can connect to Botanix. **Automatically** If you want to automatically connect to Botanix, simply navigate to our [Bridge](https://bridge.botanixlabs.com/) and we will guide you through the process. **Manually** To add Botanix manually to your wallet, use the provided information in [Chain Information](/botanix/user-tutorials/chain-information). {% hint style="info" %} **Rabby information** As we currently are working on integrating Botanix into Rabby, you can add the network manually.\ For networks that are not yet integrated, you can still access them by adding a custom network through: **More > Add Custom Network**. {% endhint %} # BONUS - Launch your own token {% hint style="warning" %} **Important information** This tutorial is based on the description provided by QuickNode which wrote the tutorial for testnet. You can find the original tutorial [here](https://www.quicknode.com/guides/ethereum-development/smart-contracts/how-to-create-and-deploy-an-erc20-token). The video is made by [Simple Crypto](https://www.youtube.com/@SimpleCryptoTV). When deploying your token on mainnet, you have to make sure you make the necessary changes as indicated throughout the text but not in the movie. {% endhint %} {% embed url="" %} ## Set up MetaMask and get BTC on Botanix testnet To get started, you will need the [Metamask](https://metamask.io/) browser extension to create an EVM wallet and some Bitcoin, which you can get by following the steps laid out on [this link](https://docs.botanixlabs.com/bridge/getting-started/deposit). ## Implement contract Head over to the [Ethereum Remix](https://remix.ethereum.org/) IDE and make a new Solidity file, for example `-token.sol` . Paste the following code into your new Solidity script: {% code overflow="wrap" lineNumbers="true" %} ```solidity pragma solidity ^0.4.24; //Safe Math Interface contract SafeMath { function safeAdd(uint a, uint b) public pure returns (uint c) { c = a + b; require(c >= a); } function safeSub(uint a, uint b) public pure returns (uint c) { require(b <= a); c = a - b; } function safeMul(uint a, uint b) public pure returns (uint c) { c = a * b; require(a == 0 || c / a == b); } function safeDiv(uint a, uint b) public pure returns (uint c) { require(b > 0); c = a / b; } } //ERC Token Standard #20 Interface contract ERC20Interface { function totalSupply() public constant returns (uint); function balanceOf(address tokenOwner) public constant returns (uint balance); function allowance(address tokenOwner, address spender) public constant returns (uint remaining); function transfer(address to, uint tokens) public returns (bool success); function approve(address spender, uint tokens) public returns (bool success); function transferFrom(address from, address to, uint tokens) public returns (bool success); event Transfer(address indexed from, address indexed to, uint tokens); event Approval(address indexed tokenOwner, address indexed spender, uint tokens); } //Contract function to receive approval and execute function in one call contract ApproveAndCallFallBack { function receiveApproval(address from, uint256 tokens, address token, bytes data) public; } //Actual token contract contract QKCToken is ERC20Interface, SafeMath { string public symbol; string public name; uint8 public decimals; uint public _totalSupply; mapping(address => uint) balances; mapping(address => mapping(address => uint)) allowed; constructor() public { symbol = "QKC"; name = "QuikNode Coin"; decimals = 2; _totalSupply = 100000; balances[YOUR_METAMASK_WALLET_ADDRESS] = _totalSupply; emit Transfer(address(0), YOUR_METAMASK_WALLET_ADDRESS, _totalSupply); } function totalSupply() public constant returns (uint) { return _totalSupply - balances[address(0)]; } function balanceOf(address tokenOwner) public constant returns (uint balance) { return balances[tokenOwner]; } function transfer(address to, uint tokens) public returns (bool success) { balances[msg.sender] = safeSub(balances[msg.sender], tokens); balances[to] = safeAdd(balances[to], tokens); emit Transfer(msg.sender, to, tokens); return true; } function approve(address spender, uint tokens) public returns (bool success) { allowed[msg.sender][spender] = tokens; emit Approval(msg.sender, spender, tokens); return true; } function transferFrom(address from, address to, uint tokens) public returns (bool success) { balances[from] = safeSub(balances[from], tokens); allowed[from][msg.sender] = safeSub(allowed[from][msg.sender], tokens); balances[to] = safeAdd(balances[to], tokens); emit Transfer(from, to, tokens); return true; } function allowance(address tokenOwner, address spender) public constant returns (uint remaining) { return allowed[tokenOwner][spender]; } function approveAndCall(address spender, uint tokens, bytes data) public returns (bool success) { allowed[msg.sender][spender] = tokens; emit Approval(msg.sender, spender, tokens); ApproveAndCallFallBack(spender).receiveApproval(msg.sender, tokens, this, data); return true; } function () public payable { revert(); } } ``` {% endcode %} Replace the following values: * Line 52: Replace "**QKCToken"** with your own name (In the example it is BotanixTestToken) * Line 62: symbol = "**QKC**"; Choose your own symbol * Line 63: name = "**QuikNode Coin**"; Choose your own name * Line 64: decimals = **2**; set the decimal (value in which tokens can be divided, 0 to 8 decimal units can be used) and establish a total supply value as you wish * Line 65 \_totalSupply = **100000**; Choose a total supply * Line 66: balances\[**YOUR\_METAMASK\_WALLET\_ADDRESS**] = \_totalSupply; Please change YOUR\_METAMASK\_WALLET\_ADDRESS to your own wallet address (This one can be found in your MetaMask interface) * Line 67: emit Transfer(address(0), **YOUR\_METAMASK\_WALLET\_ADDRESS**, \_totalSupply); {% hint style="info" %} **Note**: The total supply value must have additional trailing zeros as specified by the decimals field. For example, the decimals value in this contract is 2 and we need a total supply of 1000 tokens, so we’ll have to set the total supply variable to 100000 (simply because it won’t allow a decimal point). {% endhint %} Compile the smart contract. Make sure you select the right compiler based on the chosen Solidity version.
Deploy it using *injected Web3* (make sure to select the Botanix networkon MetaMask before compiling the contract) and select the right contract to be deployed. Approve the transaction from MetaMask. {% hint style="info" %} **Note:** We need to deploy the main token contract, select the name of the contract appropriately under the contracts section before deploying the contract (BotanixTestToken here). {% endhint %}
{% hint style="info" %} **Gas fees** If the gas fees appear to high to deploy the contract, try lowering them manually. {% endhint %}
{% hint style="info" %} If you receive an error message before deployment “This contract may be abstract”, make sure to select the appropriate contract under the Contract tab. Confirm the transaction in Metamask. {% endhint %}
That’s it! your token contract is now deployed on Botanix! ## Get token in MetaMask To get the token in Metamask, go to the “Deployed Contracts” section in Remix and copy the deployed contract’s address using the copy button near the contract’s name.
Open Metamask, go to the Token tab and click on the Import Tokens button. Paste the contract’s address in the first field. Metamask will fetch the Token Symbol and decimals automatically.
# Risk warning {% hint style="danger" %} **Risk Warning** Botanix mainnet involves real Bitcoin and other cryptocurrency funds. Before using the network, you must understand and accept the following critical risks. **Core Network Risks** Even though the end-goal of Botanix Labs is to create and implement a fully decentralized Spiderchain, we need some in-between steps to get there. (see our [Roadmap](/botanix/get-to-know-botanix/roadmap-to-spiderchain) or the [whitepaper](https://drive.google.com/file/d/1WwbQCNaCCjQyw7ZufyfwhJj7TK9kjXH0/view)) At this stage of development, Botanix mainnet operates as a **federated sidechain**, meaning that blocks are produced by 16 trusted, permissioned federation members. These federation members also secure the multisig where your real funds are locked. This setup means users are sending their bitcoin to a centralized semi-custodial system with the following risks: 1. **You trust the Federation with custody of your real BTC**. BTC withdrawals are currently permissioned by the Botanix federation. When you deposit BTC into Botanix mainnet, you must trust that the signers will not collude and steal your funds. Your BTC is held in a 12-16 multi-sig wallet where 12 (⅔ + 1) of the signers would need to be compromised to steal your bitcoin. 2. **Orchestrators control block production**. Botanix blocks are proposed and finalized by the Botanix federation. Block production is permissioned, meaning anyone cannot join as a block producer regardless of resources. You trust that the federation will not censor your transactions or prevent withdrawals. **Financial and Security Warnings** * **Real money is at risk**: Unlike testnets, mainnet involves actual cryptocurrency with real monetary value. Any losses are permanent and irreversible. * **Smart contract risks**: Smart contracts may contain bugs or vulnerabilities that could result in total loss of funds. * **Bridge risks**: The cross-chain bridge technology carries inherent risks including potential exploits or technical failures. * **Regulatory uncertainty**: Regulatory changes could impact the network's operation or your ability to access funds. **Security Best Practices** * Never share your private keys or seed phrases with anyone * Verify all website URLs carefully - beware of phishing sites * Only follow official announcements through verified Botanix social media channels * Start with small amounts to test functionality before depositing larger sums **Legal and Investment Disclaimers** * You could lose all deposited funds: There is no guarantee of fund recovery if issues arise * This technology is in beta phase and carries risks * No investment advice is provided - conduct your own research * All roadmaps, specifications, and performance claims are estimates made in good faith but are not guarantees * Nothing in this project constitutes a solicitation for investment **By using Botanix mainnet, you acknowledge that you understand these risks and agree to use the network at your own risk with funds you are happy to experiment with.** {% endhint %} # Introduction {% hint style="warning" %} **Disclaimer** Some of the provided information in the following chapters is related to the final product of Botanix with the Spiderchain fully implemented as outlined in the whitepaper. For more information on the current implementation, visit [Founding Federation](/botanix/get-to-know-botanix/roadmap-to-spiderchain/founding-federation). {% endhint %} ## Botanix in short Botanix is a Layer 2 protocol built on Bitcoin that enables users to access decentralized applications directly on the Bitcoin network. This includes decentralized exchanges (DEXs), lending and borrowing protocols, NFT marketplaces, and other DeFi applications. While these capabilities have long been available on Ethereum and other EVM-compatible chains, Botanix Labs is bringing this functionality to Bitcoin through the Botanix protocol. ### Bridging to Botanix To use Botanix, users bridge their bitcoin from the Bitcoin base layer (L1) to Botanix (L2). When bitcoin is bridged to Botanix, it is securely stored in newly created multisig wallets that are managed by the network's Orchestrator nodes. These nodes safeguard the deposited bitcoin until users choose to bridge back to the Bitcoin mainnet. During this time, users receive an equivalent amount of bitcoin on Botanix that can be used with applications built on the platform. When users no longer wish to interact with these applications, they can bridge their assets back to receive their bitcoin on the Bitcoin mainnet. ### Security Through Economic Incentives The security of user funds is maintained through economic incentives built into the protocol. Orchestrator nodes must stake their own bitcoin to participate in the network. This stake serves as collateral to ensure honest behavior—if an Orchestrator acts maliciously or fails to meet network requirements, their staked funds are subject to slashing penalties. This mechanism, combined with additional security features detailed in our Advanced Concepts section, ensures the integrity of user deposits and network operations. ### Example Use Case Consider the following scenario: 1. **Initial Position**: Alice holds BTC and wants to earn yield through decentralized lending 2. **Bridge In**: Alice deposits her BTC to Botanix, receiving an equivalent amount of BTC on the Layer 2 network 3. **DeFi Interaction**: Alice lends her BTC through a lending protocol available on Botanix 4. **Yield Generation**: Over time, Alice earns interest on her deposited assets 5. **Bridge Out**: Alice withdraws her principal plus earned interest back to the Bitcoin mainnet 6. **Result**: Alice has successfully generated yield on her Bitcoin holdings through decentralized finance This example demonstrates how Botanix enables Bitcoin holders to participate in sophisticated financial applications while maintaining the security and decentralization principles of the Bitcoin network. # Beginner Welcome to the foundational knowledge section of Botanix documentation. Whether you're new to cryptocurrency or coming from Bitcoin's world of simple transactions, understanding these core concepts will help you navigate the expanded possibilities that Botanix brings to Bitcoin. ### What You'll Learn This section covers the essential building blocks you need to understand before diving into Botanix's advanced features. We've designed these guides to be beginner-friendly while providing the depth necessary to use Botanix confidently and safely. **Wallets and Custody**: Learn how to safely store and manage your cryptocurrency, from browser wallets to hardware security, and understand the responsibility that comes with being your own bank. **Consensus Mechanisms**: Learn how different blockchain networks reach agreement and why Botanix's hybrid approach combines the best of multiple systems. **Layer 1 vs Layer 2**: Grasp why Layer 2 solutions like Botanix exist and how they extend Bitcoin's capabilities without compromising its security. **Gas Fees**: Understand the cost of transactions and smart contract interactions, and learn how Botanix makes DeFi accessible with minimal fees. **Smart Contracts**: Discover how programmable money works and why it represents a fundamental shift from traditional Bitcoin transactions to sophisticated, automated financial applications. **DeFi (Decentralized Finance)**: Explore the world of decentralized exchanges, lending protocols, and yield farming that's now possible on Bitcoin through Botanix. # Wallets and Custody of Funds ### What is a Crypto Wallet? A crypto wallet is a tool that stores your private keys—the secret codes that prove you own your cryptocurrency. Think of it like a digital keychain that holds the keys to your crypto "safety deposit boxes" on the blockchain. The wallet doesn't actually store your coins (they live on the blockchain), but it stores the keys that let you access and move them. ### Types of Wallets {% tabs %} {% tab title="Hot Wallets" %} **Browser Wallets**: Extensions like MetaMask that run in your web browser. Perfect for interacting with DeFi applications and easy daily use. * *Pros*: Convenient, easy to use with dApps * *Cons*: More vulnerable to online attacks **Mobile Wallets**: Apps on your smartphone for on-the-go access. * *Pros*: Portable, user-friendly, often include QR code scanning * *Cons*: Phone security depends on device security **Desktop Wallets**: Software installed on your computer. * *Pros*: More features, better for managing multiple assets * *Cons*: Vulnerable to malware and computer attacks {% endtab %} {% tab title="Cold Wallets" %} **Hardware Wallets**: Physical devices like Ledger or Trezor that store your keys offline. * *Pros*: Highest security, immune to online attacks * *Cons*: Less convenient for frequent transactions, costs money **Paper Wallets**: Your private keys written or printed on paper. * *Pros*: Completely offline, free * *Cons*: Easy to lose or damage, not practical for regular use {% endtab %} {% endtabs %} ### Custody Models {% tabs %} {% tab title="Self-Custody" %} You hold your own private keys and are fully responsible for security. This gives you complete control but also complete responsibility. **Best For**: Users who want maximum control and are comfortable with security practices. {% endtab %} {% tab title="Custodial (3rd party)" %} Exchanges or services hold your private keys for you, similar to a traditional bank account. **Best For**: Beginners who want simplicity and aren't comfortable managing their own security. {% endtab %} {% tab title="Multi-Signature (Shared)" %} Requires multiple signatures to move funds, often used by organizations or for added security. **Best For**: Organizations, high-value holdings, or users wanting distributed security. {% endtab %} {% endtabs %} ### Essential Security Best Practices {% tabs %} {% tab title="General" %} * **Start small**: Begin with small amounts while learning * **Use reputable wallets**: Stick to well-known, audited wallet software * **Keep software updated**: Regular updates fix security vulnerabilities * **Verify addresses**: Always double-check recipient addresses before sending * **Use strong passwords**: Protect wallet files and accounts with strong, unique passwords {% endtab %} {% tab title="Seed Phrase" %} * **Write it down**: Store your 12-24 word seed phrase on paper, never digitally * **Multiple copies**: Keep copies in separate secure locations * **Never share**: Never enter your seed phrase on websites or share with anyone * **Test recovery**: Verify you can recover your wallet before storing large amounts {% endtab %} {% tab title="Hot Wallet" %} * **Separate devices**: Consider using a dedicated device for crypto activities * **Limited funds**: Only keep what you need for regular use in hot wallets * **Regular backups**: Backup wallet data regularly {% endtab %} {% tab title="Cold Storage" %} * **Physical security**: Store hardware wallets and paper wallets in secure locations * **Test periodically**: Occasionally verify your cold storage is still accessible * **Have a plan**: Ensure trusted family members can access funds if needed {% endtab %} {% endtabs %} ### Botanix Wallet Compatibility Botanix is EVM-compatible, so you can use familiar wallets such as: * **OKX:** Comprehensive wallet with built-in DEX and multi-chain support * **Rabby:** Advanced wallet designed for DeFi users with enhanced security features * **MetaMask**: Most popular choice for interacting with Botanix dApps * **Trust Wallet**: Mobile-friendly option with broad crypto support * **Coinbase Wallet**: User-friendly with built-in dApp browser * **Hardware Wallets**: Ledger and Trezor support EVM chains including Botanix ### Getting Started Safely 1. **Choose the right wallet type** for your needs and technical comfort level 2. **Start with small amounts** to learn and test everything works 3. **Secure your seed phrase** before adding significant funds 4. **Practice basic operations** like sending and receiving 5. **Gradually increase** your holdings as you become more comfortable ### Common Mistakes to Avoid * **Not backing up seed phrases** - This is the #1 way people lose their crypto * **Using exchange wallets for storage** - Exchanges can be hacked or freeze accounts * **Sharing private information** - Never share keys, seed phrases, or passwords * **Not verifying addresses** - Always double-check before sending transactions * **Ignoring software updates** - Outdated software has security vulnerabilities ### Learn More **Best Practices**: * [Kraken Security Guide](https://www.kraken.com/learn/videos/crypto-security-guide) * [Coinbase Learn: How to keep your crypto secure](https://www.coinbase.com/learn/crypto-basics/how-to-secure-crypto) **Specific Wallet Guides**: * [MetaMask Official Guide](https://metamask.io/faqs/) * [Ledger Academy](https://www.ledger.com/academy) Remember: With crypto, you are your own bank. This brings great freedom but also great responsibility. Take time to understand security practices before committing significant funds. # Consensus Mechanisms ### What is Consensus? Consensus mechanisms are the rules that blockchain networks use to agree on what transactions are valid and which version of the blockchain is correct. Since blockchains are decentralized networks with no central authority, all participants (nodes) must agree on the state of the ledger to prevent fraud and ensure consistency. Think of it like a group of friends splitting a dinner bill—everyone needs to agree on who ordered what and how much each person owes. In blockchain, consensus mechanisms ensure everyone agrees on who sent what to whom. ### Why Consensus Matters Without consensus mechanisms, blockchain networks would face serious problems: * **Double Spending**: Someone could spend the same coins multiple times * **Conflicting Records**: Different nodes might have different versions of transaction history * **Network Splits**: The blockchain could fragment into incompatible versions * **Fraud**: Malicious actors could manipulate transaction records Consensus mechanisms solve these problems by establishing clear rules for validating transactions and adding new blocks to the chain. ### Types of Consensus Mechanisms
Proof of Work (PoW) #### How It Works Proof of Work requires network participants (miners) to solve computationally difficult puzzles to add new blocks to the blockchain. The first miner to solve the puzzle gets to add the block and receives a reward. Watch this video by WhiteBoard Crypto to learn more: [What is Proof of Work?](https://www.youtube.com/watch?v=XLcWy1uV8YM\&ab_channel=WhiteboardCrypto) #### The Process 1. **Transaction Collection**: Miners gather pending transactions into a block 2. **Puzzle Solving**: Miners compete to solve a cryptographic puzzle 3. **Block Addition**: The first to solve it broadcasts their solution 4. **Verification**: Other nodes verify the solution and accept the block 5. **Reward**: The winning miner receives newly created coins plus transaction fees #### Examples * **Bitcoin**: The original and most famous PoW blockchain * **Ethereum** (until 2022): Used PoW before transitioning to Proof of Stake * **Litecoin**: Bitcoin's "silver" using a different hashing algorithm #### Advantages * **Battle-tested security**: Proven secure over 15+ years * **True decentralization**: Anyone can participate with computing power * **Immutable history**: Extremely difficult to alter past transactions * **No central authority**: Purely distributed consensus #### Disadvantages * **Energy intensive**: Requires significant electricity consumption * **Slow transactions**: Bitcoin processes \~7 transactions per second * **High costs**: Mining requires expensive specialized hardware * **Environmental concerns**: Large carbon footprint
Proof of Stake (PoS) #### How It Works Instead of competing with computational power, Proof of Stake selects validators based on their stake (ownership) in the network. Validators are chosen to create new blocks based on their stake size and other factors. Watch this video by WhiteBoard Crypto to learn more: [What is Proof of Stake? ](https://www.youtube.com/watch?v=x83EVUZ_EWo\&ab_channel=WhiteboardCrypto) #### The Process 1. **Staking**: Users lock up their tokens as stake 2. **Validator Selection**: The network randomly selects validators weighted by stake 3. **Block Creation**: Selected validators create new blocks 4. **Attestation**: Other validators verify and vote on the block 5. **Rewards**: Validators earn rewards for honest participation 6. **Penalties**: Validators lose stake for malicious behavior (slashing) #### Examples * **Ethereum 2.0**: Transitioned from PoW to PoS in 2022 * **Cardano**: Purpose-built PoS blockchain * **Solana**: High-performance PoS network #### Advantages * **Energy efficiency**: Uses 99%+ less energy than PoW * **Faster transactions**: Can process thousands of transactions per second * **Lower barriers**: No need for expensive mining hardware * **Scalability**: More efficient consensus enables higher throughput #### Disadvantages * **Wealth concentration**: Richer participants have more influence * **Newer technology**: Less battle-tested than PoW * **Slashing risk**: Validators can lose their stake for mistakes * **Nothing at stake**: Theoretical problem where validators have no cost to validate multiple chains
Delegated Proof of Stake (DPoS) #### How It Works Token holders vote to elect a small number of delegates who validate transactions and create blocks on behalf of the network. Watch this video by Binance Academy to learn more: [What is Delegated Proof of Stake?](https://www.youtube.com/watch?v=OVKAOwzAwHI\&ab_channel=BinanceAcademy) #### Examples * **EOS**: Early DPoS implementation * **Tron**: High-throughput DPoS network #### Advantages * **Very fast**: Can process thousands of transactions per second * **Democratic**: Token holders vote for representatives * **Efficient**: Fewer validators mean faster consensus #### Disadvantages * **Centralization**: Only a small number of validators * **Political**: Voting and governance can become contentious * **Cartel risk**: Validators might collude
Proof of Authority (PoA) #### How It Works Validators are pre-approved identities (authorities) who are given the right to validate transactions and create blocks. Instead of staking tokens or solving puzzles, validators are chosen based on their reputation and identity verification. #### The Process 1. **Authority Selection**: Network operators choose trusted validators based on identity verification 2. **Round-Robin Validation**: Validators take turns creating blocks in a predetermined order 3. **Block Creation**: The designated validator creates and signs the block 4. **Network Acceptance**: Other validators verify and accept the block 5. **Reputation Management**: Misbehaving validators can be removed from the authority list #### Examples * **VeChain**: Supply chain focused blockchain using PoA * **Ethereum Testnets**: Goerli and other test networks use PoA * **Private Networks**: Many enterprise and consortium blockchains #### Advantages * **High performance**: Very fast transaction processing and block times * **Predictable**: Known validators create consistent block production * **Low energy**: No computational competition or large stake requirements * **Immediate finality**: Transactions are final once included in a block * **Regulatory friendly**: Known validator identities aid compliance #### Disadvantages * **Centralization**: Limited number of pre-approved validators * **Trust dependency**: Relies on the reputation and honesty of authorities * **Censorship risk**: Authorities could potentially censor transactions * **Governance challenges**: Difficulty in adding/removing validators fairly * **Less decentralized**: Contradicts blockchain's decentralization principl
Practical Byzantine Fault Tolerance (pBFT) #### How It Works Designed to work even when up to 1/3 of network participants are malicious or offline. Validators communicate directly to reach consensus. #### Examples * **Hyperledger Fabric**: Enterprise blockchain platform * **Cosmos**: Uses Tendermint pBFT consensus #### Advantages * **Finality**: Transactions are immediately final * **Fault tolerance**: Works with up to 33% malicious nodes * **Efficiency**: No energy-intensive mining #### Disadvantages * **Scalability limits**: Communication overhead increases with network size * **Complexity**: More complex to implement and understand
### Botanix's Approach (TODO) {% hint style="info" %} For the current information on Botanix's consensus, visit [Broken mention](broken://pages/wkhWLHv0d04y2ZxPr4LC) {% endhint %} ### Key Takeaways * **Consensus enables trust**: Without it, decentralized networks couldn't function * **Different trade-offs**: Security vs. speed vs. decentralization vs. energy use * **No perfect solution**: Each mechanism has advantages and disadvantages * **Innovation continues**: New approaches constantly emerge to address limitations * **Hybrid solutions**: Combining mechanisms can optimize for specific use cases Understanding consensus mechanisms helps you evaluate blockchain networks and understand why different projects make different design choices. # Layer 1 vs Layer 2 ### What is Layer 1? Layer 1 (L1) refers to the base blockchain network itself—the foundational layer where all transactions are ultimately recorded and validated. Bitcoin, Ethereum, and Solana are examples of Layer 1 blockchains. These networks handle everything: transaction processing, consensus, security, and data storage. Think of Layer 1 as the main highway system of a country—it's the primary infrastructure that everything else builds upon. The Bitcoin as Layer 1 is extremely secure and decentralized but lacks scalability. This is often known as the "Blockchain Trilemma". {% hint style="info" %} **Info - Blockchain Trilemma** * The blockchain trilemma refers to the challenge of achieving three critical aspects of blockchain technology: security, scalability, and decentralization. * The trilemma suggests that optimizing one aspect often compromises the others, making it difficult to achieve all three simultaneously. * Various solutions, such as sharding, side-chains, and state channels, are being explored to address this trilemma ![](https://1545802676-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGi5rTBkDfRkp6vDha0bT%2Fuploads%2F52OeoMMqPgScc6dORzDM%2Fimage.png?alt=media\&token=17b01ca2-3383-4e83-80e1-e9850fa71953) {% endhint %} ### What is Layer 2? Layer 2 (L2) refers to secondary networks built on top of Layer 1 blockchains to improve their capabilities. These solutions process transactions off the main chain but still derive their security from the underlying Layer 1 network. Continuing the highway analogy, Layer 2 is like express lanes, local roads, and bypasses that reduce traffic on the main highway while still connecting to it. ### Why Do We Need Layer 2? Layer 1 blockchains face a fundamental challenge called the "blockchain trilemma"—they struggle to be secure, decentralized, and scalable all at the same time. Most Layer 1 networks prioritize security and decentralization, which can limit their transaction throughput and increase costs. **Bitcoin's Limitations:** * \~7 transactions per second * 10-minute block times * Limited smart contract capability * High fees during network congestion **Ethereum's Limitations:** * \~15 transactions per second * High gas fees during busy periods * Network congestion affects all users Layer 2 solutions address these limitations while maintaining the security benefits of the underlying Layer 1. ### How Layer 2 Works Layer 2 networks process transactions faster and cheaper by handling most activity off-chain, then periodically settling the final results on Layer 1. This approach provides: * **Faster Transactions**: Process hundreds or thousands of transactions per second * **Lower Costs**: Reduce fees from dollars to cents * **Enhanced Functionality**: Add capabilities like smart contracts to Bitcoin * **Maintained Security**: Inherit the security guarantees of the base layer ### Types of Layer 2 Solutions * **Sidechains**: Independent blockchains that run parallel to Layer 1 with their own consensus mechanisms * **State Channels**: Allow parties to transact off-chain and only settle final results on Layer 1 * **Rollups**: Bundle many transactions together and submit them as a single transaction to Layer 1 * **Plasma Chains**: Create child chains that periodically commit to the main chain ### Botanix as a Layer 2 Botanix operates as a Layer 2 solution on Bitcoin, bringing several key innovations: * **EVM Compatibility**: Enables smart contracts and DeFi applications on Bitcoin * **Spiderchain Security**: Uses distributed multisig wallets to secure bridged Bitcoin * **Fast Transactions**: 5-second block times compared to Bitcoin's 10 minutes * **Low Fees**: Transactions cost cents instead of dollars * **Bitcoin Settlement**: Inherits Bitcoin's proof-of-work security for final settlement ### Trade-offs to Consider * **Additional Complexity**: Users need to understand bridging between layers * **New Trust Assumptions**: Layer 2 security models may differ from Layer 1 * **Liquidity Fragmentation**: Assets may be split across different layers * **Emerging Technology**: Many Layer 2 solutions are still experimental ### The Future is Multi-Layer The blockchain ecosystem is evolving toward a multi-layer architecture where: * **Layer 1** provides security and final settlement * **Layer 2** handles everyday transactions and applications * **Users** move seamlessly between layers as needed This approach allows Bitcoin to remain the secure, decentralized foundation while enabling the rich application ecosystem that users expect from modern blockchain networks. Botanix represents this vision realized—bringing the full power of decentralized finance to Bitcoin while preserving everything that makes Bitcoin special. # Gas Fees ### What are Gas Fees? Gas fees are the costs you pay to execute transactions and smart contracts on the Botanix network. Think of gas as the fuel that powers your transactions—just like your car needs gasoline to run, blockchain transactions need "gas" to be processed by the network. Every action on Botanix requires computational work from the network's nodes. Gas fees compensate these nodes for the energy and resources they use to process your transactions, ensuring the network remains secure and operational. ### Why Do Gas Fees Exist? * **Network Security**: Fees prevent spam attacks by making it costly to flood the network with meaningless transactions. * **Resource Allocation**: Since computational power is limited, fees help prioritize transactions—those willing to pay more get processed faster. * **Node Compensation**: Fees reward the nodes that maintain the network and process transactions, keeping the system running smoothly. ### How Gas Works on Botanix When you make a transaction on Botanix, you're essentially asking the network to perform computational work. Different actions require different amounts of computational resources: * **Simple Transfer**: Sending Bitcoin from one address to another requires minimal computation and thus lower gas fees. * **Smart Contract Interactions**: Trading on a DEX, lending money, or minting an NFT requires more complex calculations and higher gas fees. * **Contract Deployment**: Publishing a new smart contract to the network requires the most computation and typically has the highest gas costs. ### Gas Fee Components Gas fees consist of three main parts: 1. **Gas Limit**: The maximum amount of computational work you're willing to pay for. Setting this too low means your transaction might fail; setting it too high wastes money but doesn't hurt the transaction. 2. **Base Fee**: The minimum fee required for your transaction to be included in a block. This fee is automatically determined by network demand and gets burned (removed from circulation). 3. **Priority Fee (Tip)**: An optional extra fee you can pay to miners/validators to prioritize your transaction. Higher priority fees mean faster processing during busy periods. **Total Fee = Gas Limit × (Base Fee + Priority Fee)** ### Botanix vs Other Networks One of Botanix's major advantages is significantly lower gas fees compared to Ethereum mainnet: * **Ethereum**: Gas fees can range from $5-50+ during busy periods * **Botanix**: Gas fees typically cost less than a dollar cent, making microtransactions and frequent DeFi interactions economically viable This dramatic cost reduction makes Botanix accessible for everyday users and enables new use cases that would be too expensive on Ethereum. ### Managing Gas Fees Here are practical tips for managing your gas costs: * **Check Network Activity**: During busy periods, gas fees increase. If possible, transact during quieter times for lower costs. * **Set Appropriate Priority Fees**: Most wallets suggest fee levels automatically, but you can often choose between "slow," "standard," and "fast" options based on how quickly you need your transaction processed. * **Batch Transactions**: Some applications allow you to combine multiple actions into a single transaction, saving on gas fees. * **Use Gas Estimation Tools**: Many interfaces show estimated gas costs before you confirm a transaction. ### What Happens if Gas is Too Low? If you set your gas limit too low, your transaction will fail but you'll still pay the gas fee for the computational work performed before failure. Always use the recommended gas limits or slightly higher to ensure successful transactions. # Smart Contracts ### What are Smart Contracts? Smart contracts are self-executing programs that automatically enforce agreements between parties without requiring intermediaries. Think of them as digital vending machines—you insert your money (cryptocurrency), select what you want, and the machine automatically delivers your product without needing a human operator. Unlike traditional contracts that require lawyers, courts, or other third parties to enforce, smart contracts execute automatically when predetermined conditions are met. The contract's rules are written in code and deployed on the blockchain, where they become immutable and transparent. ### How Smart Contracts Work Smart contracts operate on simple "if-then" logic: **If** a specific condition is met → **Then** execute a predetermined action For example: * **If** Alice sends 10 BTC to the contract → **Then** automatically transfer ownership of a digital asset to Alice * **If** the current date reaches December 31st → **Then** release locked funds to the designated recipient * **If** the price of BTC exceeds $100,000 → **Then** automatically execute a trading order The blockchain network validates these conditions and executes the contract code, ensuring trustless and transparent operations. ### Why Bitcoin Couldn't Do This Before Bitcoin was designed with a very specific purpose: peer-to-peer digital cash. While revolutionary, Bitcoin's scripting language is intentionally limited for security and simplicity: * **Limited Programming Capability**: Bitcoin Script can only perform basic operations like verifying signatures and simple conditional logic. It cannot perform complex calculations or store sophisticated program states. * **No Turing Completeness**: Bitcoin cannot run arbitrary programs or loops, preventing the creation of complex applications that require advanced logic. * **Minimal State Storage**: Bitcoin doesn't maintain a global state that smart contracts can reference and modify, limiting the complexity of possible applications. * **Transaction-Focused Design**: Bitcoin processes individual transactions but cannot maintain persistent applications or complex relationships between multiple parties. These limitations meant Bitcoin could only facilitate simple transfers—you couldn't build decentralized exchanges, lending protocols, or other sophisticated financial applications directly on the Bitcoin network. ### What Smart Contracts Enable Smart contracts unlock a vast array of possibilities that transform Bitcoin from simple digital cash into a platform for sophisticated applications such as: {% tabs %} {% tab title="DeFi" %} **Lending and Borrowing**: Protocols that automatically match lenders with borrowers, calculate interest, and handle liquidations without banks or traditional financial institutions. **Decentralized Exchanges (DEXs)**: Platforms where users can trade tokens directly with each other using automated market makers, without centralized exchanges. **Yield Farming**: Programs that automatically distribute rewards to users who provide liquidity or stake their tokens. {% endtab %} {% tab title="NFTs" %} **Non-Fungible Tokens**: Unique digital assets that prove ownership of art, collectibles, or other digital items. **Programmable Ownership**: Assets that can change ownership automatically based on conditions, like time-based transfers or performance milestones. {% endtab %} {% tab title="Automated Services" %} **Insurance Protocols**: Smart contracts that automatically pay out claims when specific conditions are met, like flight delays or weather events. **Escrow Services**: Contracts that hold funds until both parties fulfill their obligations, eliminating the need for trusted third parties. **Subscription Services**: Automatic recurring payments that can be canceled or modified programmatically. {% endtab %} {% tab title="Financial Instruments" %} **Derivatives**: Contracts that derive value from underlying assets, enabling sophisticated trading strategies. **Structured Products**: Complex financial instruments with multiple conditions and payouts. **Governance Systems**: Decentralized voting mechanisms for protocol upgrades and community decisions. {% endtab %} {% endtabs %} ### Real-World Examples * **Uniswap-Style Trading**: Instead of using a centralized exchange, users can trade tokens through smart contracts that automatically calculate exchange rates and execute trades. * **Aave-Style Lending**: Users can deposit Bitcoin to earn interest or borrow against their Bitcoin collateral, all managed automatically by smart contracts. * **Compound-Style Interest**: Interest rates adjust automatically based on supply and demand, with no human intervention required. ### Benefits of Smart Contracts 1. **Trustless Execution**: No need to trust counterparties—the code executes exactly as programmed. 2. **Transparency**: All contract code and transactions are visible on the blockchain. 3. **Efficiency**: Automated execution eliminates intermediaries and reduces costs. 4. **Accessibility**: Anyone can interact with smart contracts 24/7 without geographic restrictions. 5. **Immutability**: Once deployed, contracts cannot be altered, providing certainty about future behavior. ### Smart Contracts on Botanix Botanix brings smart contract capability to Bitcoin by implementing the Ethereum Virtual Machine (EVM) as a Layer 2 solution. This means: 1. **Bitcoin Security**: Smart contracts benefit from Bitcoin's unmatched security and decentralization. 2. **Familiar Tools**: Developers can use existing Ethereum tools and languages like Solidity. 3. **Proven Applications**: Battle-tested DeFi protocols can be deployed on Bitcoin. 4. **Low Costs**: Botanix's efficient design keeps smart contract execution costs minimal. # Multisig Wallet ## Multisig Wallets ### What is a Multisig Wallet? A multisig (multi-signature) wallet is a cryptocurrency wallet that requires multiple signatures to authorize transactions, rather than just one private key like traditional wallets. Think of it like a bank vault that needs several different keys to open—no single person can access the funds alone. Instead of one person controlling a wallet with a single private key, a multisig wallet distributes control among multiple parties. The wallet is set up with specific rules about how many signatures are needed such as for example **2-of-3 Multisig**: Any 2 out of 3 designated signers can approve transactions. ### Real-World Example Imagine Alice, Bob, and Charlie create a 2-of-3 multisig wallet for their business: * Alice wants to pay a supplier $1,000 * She creates the transaction but can't send it alone * Either Bob OR Charlie must also sign to approve the payment * Once two signatures are provided, the transaction executes ### Why Use Multisig Wallets? #### **Enhanced Security** * **No single point of failure**: If one key is lost or stolen, funds remain safe * **Hack protection**: Attackers would need to compromise multiple devices/people * **Reduced risk**: Even if you lose one key, you can still access your funds #### **Shared Control** * **Team management**: Perfect for businesses, DAOs, or joint investments * **Family security**: Spouses or family members can share wallet access * **Organizational funds**: Multiple executives must approve large transactions #### **Trust and Accountability** * **Transparent approvals**: All signers can see proposed transactions * **Prevents misuse**: No single person can spend funds without approval * **Audit trail**: Clear record of who approved what transactions ### Common Use Cases **Business Treasuries**: Companies use multisig to prevent any single employee from moving large amounts **Investment Groups**: Friends pooling money for crypto investments use multisig for shared control **Personal Security**: Individuals create multisig with family members as backup in case of emergency **Smart Contract Security**: Protocols use multisig to control important functions and upgrades ### Multisig vs Regular Wallets | Feature | Regular Wallet | Multisig Wallet | | ----------- | ---------------------- | ------------------------------- | | Control | Single person | Multiple people | | Security | One key protects funds | Multiple keys required | | Convenience | Quick transactions | Requires coordination | | Risk | Lose key = lose funds | Lose one key = funds still safe | ### Key Takeaways * **Multisig requires multiple signatures** to move funds, not just one * **Enhanced security** through distributed control and no single points of failure * **Perfect for shared funds** like business accounts or investment groups * **More complex** than regular wallets but much more secure * **Foundation technology** that powers Botanix's Spiderchain security Multisig wallets represent a significant improvement in cryptocurrency security, moving from "one key controls everything" to "multiple keys provide protection." While they require more coordination, the security benefits make them essential for anyone managing significant cryptocurrency amounts or shared funds. # DeFi for Beginners ### What is DeFi? DeFi (Decentralized Finance) is a financial system built on blockchain technology that operates without traditional intermediaries like banks, brokers, or exchanges. Instead of relying on centralized institutions, DeFi uses smart contracts to automate financial services, making them accessible to anyone with an internet connection and a crypto wallet. Think of DeFi as recreating traditional banking services—lending, borrowing, trading, and earning interest—but in a transparent, permissionless way where you maintain control of your funds at all times. ### Key Advantages of DeFi * **No Intermediaries**: Trade, lend, and borrow directly without banks or financial institutions taking cuts or controlling access. * **24/7 Availability**: Markets never close—you can access DeFi services anytime, anywhere in the world. * **Transparency**: All transactions and smart contract code are visible on the blockchain, ensuring complete transparency. * **Permissionless**: No credit checks, paperwork, or approvals needed—if you have crypto, you can participate. * **Global Access**: Anyone with a wallet can use DeFi services regardless of location or background. ### Core DeFi Products {% tabs %} {% tab title="DEX" %} #### **Decentralized Exchanges (DEXs)** DEXs allow you to trade cryptocurrencies directly with other users without a centralized exchange. **How it works**: Smart contracts hold funds in liquidity pools, and automated algorithms determine exchange rates based on supply and demand. **Popular examples**: Uniswap, SushiSwap, PancakeSwap **Use case**: Trade one token for another (e.g., swap BTC for ETH) without creating exchange accounts or going through KYC procedures. {% endtab %} {% tab title="Lend / Borrow" %} #### **Lending and Borrowing Protocols** These platforms let you lend your crypto to earn interest or borrow against your crypto holdings. **How it works**: Lenders deposit crypto into smart contracts to earn interest. Borrowers provide collateral (usually more than they borrow) to access loans. **Popular examples**: Aave, Compound, MakerDAO **Use cases**: * Earn passive income on your crypto holdings * Borrow stablecoins against your BTC without selling it * Access liquidity for opportunities while keeping your crypto exposure {% endtab %} {% tab title="Yield" %} #### **Yield Farming** Yield farming involves providing liquidity to DeFi protocols in exchange for rewards and fees. **How it works**: You deposit your tokens into liquidity pools and earn fees from trades plus additional token rewards from the protocol. **Popular examples**: Curve Finance, Yearn Finance, Balancer **Use case**: Maximize returns on your crypto by earning trading fees and governance tokens. {% endtab %} {% tab title="Stablecoins" %} #### **Stablecoins** Stablecoins are cryptocurrencies designed to maintain stable value, usually pegged to the US dollar. **How it works**: Different mechanisms maintain the peg—some are backed by real dollars, others by crypto collateral, or algorithmic mechanisms. **Popular examples**: USDC, USDT, DAI **Use cases**: * Store value without volatility * Earn high interest rates on "dollar" deposits * Trade and transact without converting back to fiat {% endtab %} {% tab title="Synthetic" %} #### **Synthetic Assets** Synthetic assets are tokens that track the price of real-world assets like stocks, commodities, or fiat currencies. **How it works**: Smart contracts use price feeds to create tokens that mirror the value of traditional assets. **Popular examples**: Synthetix, Mirror Protocol **Use case**: Gain exposure to traditional assets like Apple stock or gold without leaving the crypto ecosystem. {% endtab %} {% endtabs %} ### DeFi on Botanix Botanix brings DeFi to Bitcoin with several advantages: * **Lower Fees**: Execute DeFi strategies at a fraction of Ethereum's gas costs * **Bitcoin Security**: Benefit from Bitcoin's unmatched security and decentralization * **Familiar Tools**: Use the same wallets and interfaces you know from Ethereum * **Proven Protocols**: Battle-tested DeFi applications can be deployed on Bitcoin ### Best Practices * **Do Your Own Research (DYOR)**: Understand any protocol before using it * **Start Small**: Learn with amounts you're comfortable losing * **Diversify**: Don't put all funds in one protocol or strategy * **Monitor Positions**: Keep track of your investments and market conditions * **Stay Updated**: DeFi moves fast—follow protocol updates and security announcements * **Use Hardware Wallets**: For significant amounts, use hardware wallet security ### The Future of DeFi DeFi represents a fundamental shift toward open, programmable money. As the ecosystem matures, we're seeing more sophisticated products, better user experiences, and integration with traditional finance. With Botanix bringing DeFi to Bitcoin, the world's largest cryptocurrency can finally participate in this financial revolution. DeFi democratizes access to financial services, but it also requires users to take responsibility for their own security and decision-making. Start small, learn continuously, and gradually explore the expanding world of decentralized finance. # Intermediate Now that you understand the foundational blockchain concepts, it's time to explore what makes Botanix unique. This section covers the core innovations that enable Botanix to support smart contracts and DeFi applications while maintaining its security and decentralization. ### Core Botanix Innovations **The Spiderchain**: The distributed multisig architecture that secures Bitcoin deposits and enables the two-way peg between Bitcoin and Botanix. **Orchestrator Nodes**: The specialized validators that manage the Spiderchain, participate in consensus, and ensure network security through economic incentives. **Bridging and Two-Way Peg**: How Bitcoin moves safely between Layer 1 and Layer 2, including deposit and withdrawal mechanisms. **Transaction Fees on Botanix**: How fee structures work on the Layer 2, including gas fees, priority fees, and the economic model that keeps costs low. ### Why These Concepts Matter Understanding these Botanix-specific mechanisms helps you: * **Use bridging safely** and understand what happens to your Bitcoin * **Appreciate the security model** that protects your funds * **Navigate transaction costs** effectively on the Layer 2 * **Understand the trade-offs** between Bitcoin's base layer and Botanix's enhanced functionality These concepts build directly on the basic blockchain knowledge from the [previous section](/botanix/get-to-know-botanix/beginner) while introducing the specific innovations that make Botanix possible. Each topic connects to the others, creating a complete picture of how Bitcoin becomes programmable through Botanix. # The Spiderchain {% hint style="info" %} The Spiderchain, as it is described below, isn't fully implemented yet. For the current implementation of the network, read [Founding Federation](/botanix/get-to-know-botanix/roadmap-to-spiderchain/founding-federation). This chapter describes the final goal as it is set out in the whitepaper. {% endhint %} ### What is the Spiderchain? The Spiderchain is Botanix's core innovation—a new primitive for second-layer blockchains that enables Bitcoin to support smart contracts and DeFi applications. At its heart, the Spiderchain is a series of successive [multisig wallets](/botanix/get-to-know-botanix/beginner/multisig-wallet) operated by Botanix Orchestrators that securely hold Bitcoin deposits while users interact with applications on the Layer 2. Think of the Spiderchain as a sophisticated security system made up of interconnected vaults, where your Bitcoin is protected by multiple independent guardians working together, and these vaults continuously evolve to maintain maximum security. ### How the Spiderchain Works #### The Basic Structure The Spiderchain operates as a network of decentralized multisig wallets that safeguard Bitcoin deposits. Here's how it functions: **Successive Multisigs**: Instead of one large multisig wallet, the Spiderchain creates a series of connected multisig wallets, each managed by different sets of Orchestrator nodes. **Dynamic Participation**: Every Bitcoin block is associated with a new multisig created between a randomly selected set of participants from the Spiderchain network. **Distributed Security**: The security comes from the decentralization of these multisig wallets across many independent operators, making it extremely difficult for any single entity or small group to compromise the system. #### The Spider Analogy The name "Spiderchain" comes from envisioning multisig wallets where each "leg" of the spider represents a different participant. Just as a spider's web is strong because of its interconnected structure, the Spiderchain's security comes from its network of interconnected multisig relationships. Each multisig wallet is like a node in the web, connected to others through shared participants, creating a resilient network that becomes stronger as it grows. ### Bitcoin Asset Separation One of the Spiderchain's most important innovations is how it separates bitcoin "the asset" from Bitcoin "the blockchain": **Asset Custody**: Your actual Bitcoin remains securely locked in multisig wallets on the Bitcoin network, guarded by the Spiderchain. **Blockchain Functionality**: Meanwhile, you receive equivalent Bitcoin on Botanix that you can use with smart contracts and DeFi applications. **Model Transition**: This separation allows for a transition from Bitcoin's UTXO (Unspent Transaction Output) model to the account model used in the EVM, enabling sophisticated programmable applications. ### Benefits of the Spiderchain Architecture #### Enhanced Security * **Multiple guardians** protect your Bitcoin instead of single entities * **Forward security** protects historical deposits even if future security is compromised * **No honeypot effect** since funds are distributed across many multisigs #### True Decentralization * **No central authority** controls the multisig network * **Random participant selection** prevents coordination attacks * **Distributed governance** through the network of Orchestrators #### Scalability * **Parallel processing** across multiple multisigs improves throughput * **Dynamic creation** of new multisigs supports network growth * **Efficient resource utilization** through distributed architecture ### Comparison to Traditional Approaches #### vs. Centralized Bridges * **Spiderchain**: Distributed across many operators * **Centralized**: Single point of failure and control #### vs. Simple Multisigs * **Spiderchain**: Dynamic, evolving security with forward protection * **Simple Multisig**: Static participants, vulnerable to long-term compromise ### The Future of the Spiderchain As Botanix evolves from its current federated model to full permissionless operation, the Spiderchain will: * **Expand participation** to include more diverse Orchestrator operators * **Enhance decentralization** through open staking mechanisms * **Improve efficiency** through ongoing protocol optimizations * **Maintain security** while scaling to support massive adoption ### Key Takeaways * The Spiderchain is a **network of connected multisig wallets** that secures Bitcoin deposits * **Forward security** protects your funds even if future validators are compromised * **Decentralized architecture** eliminates single points of failure * **Dynamic evolution** creates new security arrangements while preserving existing protection * **Bitcoin asset separation** enables UTXO to account model transition for EVM compatibility The Spiderchain represents Botanix's core innovation—a new security primitive that makes Bitcoin programmable while preserving its fundamental security and decentralization properties. It's the foundation that enables everything else Botanix offers, from DeFi applications to smart contracts, all secured by Bitcoin's unmatched network security. # Orchestrator node ### What are Orchestrator Nodes? Orchestrator nodes are the specialized validators that power the Botanix network. Just like every blockchain needs nodes to validate transactions and maintain the network, Botanix relies on Orchestrator nodes to run the protocol, secure Bitcoin deposits, and enable the seamless operation of the Layer 2. Think of Orchestrator nodes as the network's guardians—they simultaneously protect your Bitcoin deposits on Layer 1 while processing your transactions on Layer 2. ### Key Responsibilities #### **Network Operation** Orchestrator nodes are responsible for running Botanix and ensuring the protocol operates smoothly. They are the only entities able to construct new blocks on the Botanix network, making them essential for the Layer 2's functionality. #### **Dual-Side Liquidity** Unlike typical blockchain validators, Orchestrator nodes provide liquidity on both sides of the bridge: * **Bitcoin Side**: They participate in multisig wallets that hold actual Bitcoin deposits * **Botanix Side**: They mint and burn the corresponding BTC tokens on the Layer 2 #### **Security Management** When users bridge Bitcoin to Botanix, the actual Bitcoin resides safely in multisig wallets controlled by different Orchestrator nodes. This distributed custody model ensures no single entity controls user funds. ### How Orchestrator Selection Works #### **Random Selection Process** With every Bitcoin block (approximately every 10 minutes), a new multisig wallet is created. The Orchestrators who will guard this multisig wallet are randomly selected from the vast, decentralized network around the world using a verifiable random function (VRF). This random selection process ensures: * **Unpredictability**: No one can know in advance which Orchestrators will control specific deposits * **Decentralization**: Different combinations of Orchestrators secure different Bitcoin deposits * **Security**: Attackers cannot target specific Orchestrator groups #### **Dynamic Multisig Creation** Each deposit lives on its own unique multisig address, with signers (Orchestrators) randomly chosen for that specific Bitcoin block. This creates a constantly evolving security landscape where: * **New deposits** get fresh multisig configurations * **Historical deposits** remain secured by their original Orchestrator groups * **Attack surfaces** are minimized through this dynamic approach ### Staking and Economic Security #### **Stake Requirements** Anyone who wants to run an Orchestrator node must put in a stake—locking up their own Bitcoin as collateral. This stake serves multiple purposes: * **Economic alignment**: Orchestrators have skin in the game * **Security guarantee**: Malicious behavior results in financial loss * **Network participation**: Only committed operators can become Orchestrators #### **Slashing Mechanism** In case of malicious operation or protocol violations, the Bitcoin stake will be slashed. This means Orchestrator nodes can lose part or all of their stake for bad behavior, including: * **Attempting to steal deposits** * **Failing to participate in consensus** * **Violating protocol rules** * **Coordinating attacks on the network** #### **Proof-of-Stake Security Model** The security of Botanix follows established Proof-of-Stake security models. As long as the number of adversarial collaborating actors is overwhelmed by honest Orchestrators, the security is mathematically guaranteed. This creates strong economic incentives for honest behavior. ### Current vs. Future Implementation #### **Current State** The Spiderchain currently uses a simplified approach with fixed multisig addresses for practical deployment. This allows the network to operate securely while the full dynamic system is refined. The Orchestrator nodes have been carefully selected after a strict due diligence. There are currently 16 Orchestrator nodes of which Botanix Labs runs one. #### **Future Evolution** The frequency of generation and rotation of multisigs in a dynamic federation is still in the modeling and research phase. Future implementations will feature: * **Higher frequency** multisig rotation * **More sophisticated** random selection algorithms * **Enhanced security** through continuous evolution ### Key Takeaways * **Orchestrator nodes are specialized validators** that secure Bitcoin deposits while processing Layer 2 transactions * **Random selection** using VRF ensures unpredictable and secure multisig configurations * **Staking and slashing** create strong economic incentives for honest behavior * **Dynamic evolution** will enhance security as the system matures Orchestrator nodes represent the backbone of Botanix's security model, combining the battle-tested economics of Proof-of-Stake with innovative cryptographic techniques to create a secure, decentralized bridge between Bitcoin and advanced blockchain applications. # Bridging and the Two-Way Peg ### What is Bridging? Bridging is the process of moving your Bitcoin between the Bitcoin mainnet (Layer 1) and Botanix (Layer 2). It's like transferring money between two bank accounts—your Bitcoin doesn't disappear, it just moves from one network to another so you can use it for different purposes. ### How L1 Funds are Secured When you bridge Bitcoin to Botanix, your actual Bitcoin doesn't leave the Bitcoin network. Instead, it gets locked in a multisig wallet that's part of the Spiderchain. * **Secure Storage**: Your Bitcoin is held in multisig wallets controlled by randomly selected Orchestrator nodes * **Distributed Control**: No single entity can access your Bitcoin—it requires multiple Orchestrators to agree * **Spiderchain Protection**: The dynamic multisig network ensures your funds remain secure even if some Orchestrators are compromised Think of it like putting your Bitcoin in a high-security vault that requires multiple keys to open, with the keyholders being distributed around the world. ### Peg-In Process (Bitcoin → Botanix) When you want to use your Bitcoin on Botanix: 1. **Initiate Deposit**: You send Bitcoin to your personal, generated Deposit Address based on the EVM-address where you want to receive the funds. This address can be found on [https://bridge.botanixlabs.com](https://bridge.botanixlabs.com/) 2. **Bitcoin Locked**: Your Bitcoin is securely locked in the multisig wallet 3. **Confirmation**: The network confirms your Bitcoin deposit on Layer 1 4. **Minting**: An equivalent amount of Bitcoin is minted on Botanix and sent to your EVM-wallet 5. **Ready to Use**: You can now use your Bitcoin with Botanix applications ### Peg-Out Process (Botanix → Bitcoin) When you want to withdraw your Bitcoin back to Layer 1: 1. **Initiate Withdrawal**: You request to withdraw Bitcoin from Botanix on [https://bridge.botanixlabs.com](https://bridge.botanixlabs.com/) 2. **Orchestrator Approval**: Orchestrator nodes verify and approve the withdrawal 3. **Burning**: Your Botanix Bitcoin is burned (destroyed) on Layer 2 4. **Bitcoin Released**: Your original Bitcoin is released from the multisig wallet 5. **Received**: Bitcoin arrives in your Layer 1 wallet ### Minting and Burning Mechanism #### **Minting (Creation)** * When Bitcoin is locked in the Spiderchain, new Bitcoin is created on Botanix * This new Bitcoin is functionally identical to your original Bitcoin * Only Orchestrator nodes can mint new Bitcoin on Botanix * Minting only happens when actual Bitcoin is locked on Layer 1 #### **Burning (Destruction)** * When you withdraw, your Botanix Bitcoin is permanently destroyed * This ensures the total supply across both layers remains constant * Only Orchestrator nodes can burn Bitcoin on Botanix * Burning must happen before Bitcoin is released from Layer 1 ### The 1:1 Peg Botanix maintains a strict 1:1 peg between Bitcoin on Layer 1 and Bitcoin on Layer 2: * **Perfect Equivalence**: 1 BTC locked on Layer 1 = 1 BTC minted on Botanix * **Supply Conservation**: Total Bitcoin across both layers never increases * **Guaranteed Backing**: Every Bitcoin on Botanix is backed by real Bitcoin locked in the Spiderchain * **No Fractional Reserve**: The system cannot create more Bitcoin than is deposited ### Security Guarantees The bridging system provides multiple layers of security: * **Cryptographic Security**: Multisig wallets use proven cryptographic methods * **Economic Security**: Orchestrators risk their stake for honest behavior * **Distributed Control**: No single point of failure in the custody system * **Transparent Process**: All deposits and withdrawals are publicly verifiable ### User Experience From your perspective, bridging is straightforward: * **Deposit**: Send Bitcoin to a provided address, receive equivalent Bitcoin on Botanix * **Use**: Interact with DeFi applications using your bridged Bitcoin * **Withdraw**: Request withdrawal, receive your original Bitcoin back on Layer 1 The complex security mechanisms operate transparently in the background, ensuring your funds remain safe while providing seamless access to Botanix applications. ### Bridge vs. Traditional Approaches Unlike centralized exchanges or custodial services: * **You maintain control**: No single entity controls your Bitcoin * **Transparent operations**: All processes are visible on-chain * **Mathematically guaranteed**: Security through cryptography, not trust * **Non-custodial**: Your Bitcoin remains yours throughout the process ### Key Takeaways * **Bridging moves Bitcoin** between Layer 1 and Layer 2 without leaving Bitcoin's security * **Spiderchain multisigs** securely hold your Layer 1 Bitcoin * **1:1 peg guarantees** your Bitcoin value is preserved across layers * **Minting and burning** ensure supply conservation and backing * **Orchestrator nodes** manage the process with strong economic incentives The bridging mechanism is what makes Botanix possible—it allows Bitcoin to become programmable while remaining securely rooted in the Bitcoin network itself. # Transaction fees {% hint style="info" %} **TL;DR** Transaction fees on the Botanix EVM are a little different from Bitcoin and resemble more the Ethereum network. There are 3 primary actions when interacting with the Botanix EVM that can result in transaction fees. * Layer 2 transactions (i.e. transactions on the Botanix EVM itself) * Layer 1 to Layer 2 transactions (i.e. transactions from the Bitcoin main chain to Botanix EVM = bridge-in) * Layer 2 to Layer 1 transactions (i.e. transactions from Botanix EVM to the main chain = bridge-out) {% endhint %} ### Fee Structure Overview Botanix uses a dual-layer fee structure that reflects its position as a Bitcoin Layer 2. Understanding these fees helps you use the network efficiently and budget for your transactions. **Layer 1 (Bitcoin) Fees**: Traditional Bitcoin network fees for transactions on the Bitcoin mainnet **Layer 2 (Botanix) Fees**: EVM-style gas fees for transactions and smart contract interactions on Botanix ### Layer 2 Fees on Botanix #### **Fee Denomination** Fees on Botanix are denominated in Bitcoin, not ETH or other tokens. This means: * You pay gas fees using your Bitcoin balance on Botanix * Staking rewards for Orchestrators are paid in Bitcoin * All economic activity remains Bitcoin-native #### **Gas Fee Calculation** Botanix uses the same gas fee formula as Ethereum: **Fee = Gas Price × Gas Used** Where: * **Gas Price**: How much you're willing to pay per unit of computational work (set by you) * **Gas Used**: The actual computational work required for your transaction (determined by the network) #### **Setting Gas Parameters** * **Use `eth_gasPrice`** to determine the appropriate gas price for current network conditions * **Use `eth_estimateGas`** to find the appropriate gas limit for your transaction * **Important**: If your gas price is too low, your transaction will be rejected * **Important**: If your gas limit is below the estimated requirement, your transaction will fail ### Bridging Fees Explained
#### **L1 → L2: Deposit (Peg-in) Costs** When you deposit Bitcoin to Botanix, you pay two separate fees: 1. **Standard Bitcoin Transaction Fee** * This is the regular Bitcoin network fee shown in your BTC wallet * Varies based on Bitcoin network congestion * Paid to Bitcoin miners 2. **Minting Contract Gas Fee** * Cost to execute the smart contract that mints your Bitcoin on Botanix * Displayed on the bridge interface * Paid in Bitcoin on Botanix #### **L2 → L1: Withdraw (Peg-out) Costs** When you withdraw Bitcoin back to Layer 1, the process involves two transactions: 1. **Initialization Transaction (L2)** * Burns your Bitcoin on Botanix * Gas fee calculated like any other L2 transaction * Paid in Bitcoin on Botanix 2. **Finalization Transaction (L1)** * Releases your Bitcoin from the Spiderchain multisig * Cost depends on Bitcoin mempool congestion * Automatically handled by Orchestrators * Withdrawals are batched to reduce costs ### Fee Management Best Practices * **Monitor Bitcoin fees**: Bridge during lower congestion periods when possibl * **Plan ahead**: Bridge larger amounts less frequently to optimize fee-to-value ratios * **Time your transactions**: Both Bitcoin and Botanix fees vary with network activity * **Monitor gas prices**: Use tools to track optimal fee levels ### Key Takeaways * **Dual-layer fees**: Pay Bitcoin L1 fees for bridging, L2 gas fees for operations * **Bitcoin-denominated**: All fees paid in Bitcoin, maintaining network alignment * **Significant savings**: L2 operations cost (less than) cents instead of dollars * **Transparent pricing**: Tools available to estimate costs before transacting * **Batching benefits**: Some operations can be optimized through batching Understanding Botanix's fee structure helps you use the network efficiently while budgeting appropriately for your DeFi activities. The combination of Bitcoin's security with Layer 2 efficiency creates a cost-effective environment for sophisticated financial applications. # Ethereum Virtual Machine (EVM) ### What is the EVM? The Ethereum Virtual Machine (EVM) is a piece of software that executes smart contracts and computes the state of the Botanix network after each new block is added to the chain. Think of it as the engine that powers all decentralized applications on the network. The EVM sits on top of Botanix's hardware and node network layer. Its main purpose is to compute the network's state and run various types of smart contract code, compiling them into bytecode (machine-readable code that the EVM can execute). ### Why EVM for Bitcoin? Botanix Labs chose EVM compatibility to unlock Bitcoin's potential while leveraging the most mature smart contract ecosystem in crypto. This strategic decision brings several key advantages: **Proven Ecosystem**: The Ethereum Foundation has led the way in composable smart contract development, creating an ecosystem with the largest number of applications and developers. Rather than starting from scratch, Botanix taps into this established foundation. **Developer Accessibility**: EVM compatibility means developers can port their dApps or tokens from Ethereum to Botanix with relative ease. Smart contracts deployed on EVM-compatible chains like Polygon, Avalanche, or Ethereum can be recognized by Botanix nodes without modification. **Battle-Tested Security**: Solidity smart contracts benefit from the Lindy effect—the idea that older, battle-tested technology is more trustworthy. With billions of dollars secured by Solidity contracts, they experience higher levels of trust and familiarity compared to newer programming languages. ### What This Means for Users EVM compatibility transforms Bitcoin from a simple store of value into a platform for sophisticated financial applications. Bitcoin users can now access the same types of applications available on Ethereum—from Uniswap-style DEXs to Aave-style lending protocols—but secured by Bitcoin's unmatched security and decentralization. This means you can: * Trade tokens on decentralized exchanges * Lend and borrow assets * Participate in yield farming * Trade NFTs * Use familiar wallets like MetaMask ### Technical Implementation On Botanix, the EVM processes transactions and maintains network state while Bitcoin's proof-of-work provides final settlement and security. This hybrid approach combines Ethereum's programmability with Bitcoin's security model. The EVM's composability (how different protocols can work together like building blocks) enables complex financial products and services that would be impossible on Bitcoin alone. ### Programming Language Choice While other blockchains have chosen different paths—Solana with Rust, Starkware with Cairo—Botanix Labs opted for Solidity compatibility. From a programming language perspective, Solidity has established a stronghold in the crypto world, making it the clear choice for attracting developers and ensuring compatibility with existing tools and applications. This decision means developers can use familiar tools like: * Solidity for smart contract development * Hardhat for development frameworks * Remix for online development * Web3.js and ethers.js for frontend integration ### Learn More For deeper technical understanding, explore these resources: * [Ethereum Virtual Machine (Ethereum.org)](https://ethereum.org/en/developers/docs/evm/) * [What is Ethereum Virtual Machine (EVM) in Blockchain?](https://medium.com/) # UTXO vs Account Based Model This page gives a short description of the differences between UTXO and Account Based Model. {% hint style="info" %} **What does Botanix use?** Thanks to the [Spiderchain](/botanix/get-to-know-botanix/intermediate/the-spiderchain), we can make the transition from Bitcoin's UTXO model to an account model used in the EVM. This means that the Botanix EVM uses an account based model. {% endhint %}
The UTXO and account-based models represent the two most popular bookkeeping methods in the blockchain space. The two models represent two fundamentally different ways on how blockchains process and record transactions. In a nutshell, the UTXO model works similarly to cash transactions, while the account-based model works similarly to how bank accounts work. *Do you prefer to watch a movie explaining the differences? Click* [*here*](https://docs.botanixlabs.xyz/botanix-labs/get-to-know-botanix/basic-knowledge/utxo-vs-account-based-model#movie)*!* ### How Does the UTXO Model Work? UTXOs work similarly to cash, where each UTXO is like a unique fiat paper bill that users can spend. Each user in UTXO-based blockchains can keep track of its balance by adding up the cryptocurrencies in their possession. For example, assume a guy named Bob goes to a fast-food restaurant looking to buy a burger that costs $10. However, Bob only has a $20 bill, meaning that when he pays for the burger, the restaurant must give him a $10 bill as a change. In UTXO-based blockchains, the $20 bill and the $10 change would be represented as two separate UTXOs. So, in Bob’s case, his cryptocurrency account balance is just a sum of his UTXOs, just like his physical wallet is just a sum of all the different bills that he puts into his wallet. In UTXO-based blockchains like Bitcoin, for example, there's no notion of identity. There are only UTXOs or unspent coins designated to different wallet addresses. The critical point is that the Bitcoin protocol doesn't track users' balances but rather individual coins represented as UTXOs which are attributed to different addresses. ### How Does the Account-Based Model Work? The account-based model is the more popular blockchain bookkeeping method between the two. Initially popularized by Ethereum, the account model is used by many, if not most, blockchains today to record both transactions and state changes. The bookkeeping in the account model works just like bank accounts, where money transfers are recorded as debits and credits on different users' accounts on the bank's ledger. For example, when Alice wants to send $10 to Bob, the bank credits or deducts $10 from Alice's account and debits or adds $10 to Bob's name in its ledger. The same happens in account-based blockchains; only the ledger that records the users' balances is distributed among many entities (full nodes). The key point is that account-based blockchains don't track coins but instead balance changes on users' accounts. In this model, the notion of identity is present, and one user is typically associated with a single blockchain account or address. ### Key Differences in UTXO vs. Account-based Blockchains In examining the benefits and drawbacks of UTXO and account-based models, several key differences arise, highlighting the unique characteristics of each accounting system. For instance, in the UTXO model, crypto wallets typically generate new addresses for every user transaction, making it more difficult for third parties to trace or link transactions to a specific individual. This characteristic provides a **higher privacy level than the account model**, where users typically interact with the blockchain through a single account with a transparent balance. Additionally, the UTXO model naturally supports **parallel transaction processing**, which refers to the simultaneous processing of many blockchain transactions, allowing for increased efficiency and throughput. This is in contrast to account-based blockchains that process transactions sequentially or one transaction after another linearly. Parallel transaction processing can be particularly beneficial in situations with a high volume of transactions, as it enables the network to accommodate more transactions per second and handle increasing demand. Additionally, it can contribute to faster transaction confirmation times, a more responsive and efficient network, and better resource utilization. That being said, achieving optimal parallel processing requires efficient consensus algorithms and effective resource management techniques, meaning that UTXO-based blockchains aren't necessarily more scalable than current account-based ones. On the other hand, account-based blockchains are generally considered **more programmable or better suited for smart contracts** than UTXO-based blockchains. This is because account-based blockchains are stateful, which allows for more complex interactions between user accounts and smart contracts and makes it easier for developers to create programmable logic and build sophisticated decentralized applications. In other words, the account-based model is generally more straightforward for developers to work with because the transactions resemble direct transfers between accounts or function calls to smart contracts, which more closely mimics traditional programming paradigms. ### Conclusion In conclusion, the differences between UTXO and account-based blockchains stem from their distinct approaches to managing transactions and states. The UTXO model offers enhanced privacy and parallelism due to its structure, which focuses on tracking unspent outputs and allowing for simultaneous processing of unrelated transactions. On the other hand, the account-based model simplifies transactions by maintaining a global state of accounts and balances, making it more intuitive for developers and better suited for smart contracts and complex applications. Ultimately, understanding the nuances between these models is crucial for developers, users, and stakeholders to make informed decisions when building or participating in blockchain ecosystems. ### Movie {% embed url="" %} # Staking {% hint style="info" %} Coming later. Check out our Roadmap. {% endhint %} ### What is Staking? Staking on Botanix is the process of locking up your Bitcoin to help secure the network and participate in consensus. Unlike traditional Bitcoin, which doesn't offer native staking, Botanix enables Bitcoin holders to earn rewards by contributing to network security through the Spiderchain's Proof-of-Stake consensus mechanism. Think of staking as putting your Bitcoin to work—instead of just holding it, your Bitcoin actively helps secure the network while earning you additional Bitcoin rewards. ### How Staking Works on Botanix #### **The Staking Process** 1. **Lock Bitcoin**: You commit your Bitcoin as stake to participate in network security 2. **Validation Rights**: Your stake gives you the right to participate in consensus and validate transactions 3. **Earn Rewards**: You receive Bitcoin rewards for honest participation in securing the network 4. **Risk/Reward**: Your stake can be slashed (partially or fully lost) for malicious behavior #### **Bitcoin-Native Staking** Unlike other networks that require you to buy separate tokens: * **Stake with Bitcoin**: Use your actual Bitcoin as collateral * **Earn Bitcoin**: Rewards are paid in Bitcoin, not other tokens * **Maintain Exposure**: Keep your Bitcoin exposure while earning yield ### Why Stake on Botanix? #### **Earn Bitcoin Yield** For the first time, Bitcoin holders can earn native yield on their holdings: * **Passive Income**: Generate Bitcoin rewards without selling your position * **Compound Growth**: Reinvest rewards to increase your stake over time * **Bitcoin Denominated**: No exposure to other tokens or currencies #### **Support Network Security** Your staked Bitcoin directly contributes to Botanix's security: * **Consensus Participation**: Help validate transactions and create blocks * **Economic Security**: Your stake adds to the total economic security of the network * **Decentralization**: More stakers means a more decentralized and resilient network ### Staking Phases #### **Current Phase: Federated, no Staking** * **Selected Operators**: Current Orchestrators are pre-selected for network stability * **No Staking**: Staking is not required yet for selected node operators #### **Future: Permissionless** * **Open Participation**: Anyone can stake Bitcoin and participate in consensus * **Full Decentralization**: Transition to truly permissionless network participation ### Key Takeaways * **Bitcoin-native staking** enables yield generation without leaving the Bitcoin ecosystem * **Network security** benefits from increased economic participation * **Aligned incentives** ensure stakers and network interests are aligned * **Future implementation** will transition from federated to permissionless participation * **Multiple participation options** will accommodate different risk profiles and technical capabilities Staking represents a fundamental evolution in Bitcoin's utility—transforming it from purely a store of value into a productive asset that generates yield while securing the next generation of Bitcoin-based financial applications. # Advanced # Finality Finality ensures that previous transactions remain unchangeable. In present-day blockchain systems, transactions are commonly seen as immutable. However, the majority of these systems only provide a type of probabilistic transaction finality, indicating that transactions aren't immediately treated as final, but eventually gain that status. Consequently, it is recommended that one waits for up to 6 confirmations when transacting on the Bitcoin blockchain. Finality is the main reason bridge-ins for Botanix will take 6 confirmations before being processed. ### **Why is Finality so important?** Finality estimates the wait time for a reliable assurance that a transaction inscribed in the blockchain is unalterable, meaning it won't be disregarded. This holds paramount importance for businesses, as even an hour's delay on a blockchain network can yield noteworthy consequences. ### Finality: hard to solve in PoS but inherent to PoW See the sections on [Finality in a Proof-of-Work](https://app.gitbook.com/o/p0u0qYOXkJnhTfCjtGWw/s/Gi5rTBkDfRkp6vDha0bT/~/changes/9/get-to-know-botanix/architecture/finality/finality-in-a-proof-of-work-pow) and [Finality in a Proof-of-Stake](https://app.gitbook.com/o/p0u0qYOXkJnhTfCjtGWw/s/Gi5rTBkDfRkp6vDha0bT/~/changes/9/get-to-know-botanix/architecture/finality/finality-in-a-proof-of-stake-pos) on how the two different consensus mechanisms reach finality. From a general perspective finality is inherently part of the design in PoW while PoS has to design a new protocol (eg. Casper in Ethereum) to achieve finality. This new finality protocol comes with tradeoffs and new attack surfaces. Arguably finality is one of the biggest security problems of a Layer 1 PoS protocol. [Stacks](https://www.stacks.co/) has realized the issues of finality in PoS and therefore was the first to use a PoW protocol (Bitcoin) to achieve this finality. Likewise, the Botanix EVM as a PoS inherits finality from Bitcoin's PoW and does not need to implement a new protocol to achieve finality. # Finality in a Proof-of-Work (PoW) In a proof-of-Work (PoW) system, finality is typically achieved through the use of confirmations, which refer to the number of blocks that have been added to the chain after a particular block. The more confirmations a block has, the more secure it is considered to be. From the [Bitcoin whitepaper](https://bitcoin.org/bitcoin.pdf): > "The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power." A chain can split into two different forks when two different miners mine a block at the same time. When that happens, it is quite difficult to determine which fork is the valid chain. Once one of the chains validates a block before the other chain completes it becomes the longest chain. The longest chain is the one with the longest most valid blocks attached. The longest chain becomes officially the accepted chain and the transactions mined on the shorter chain are rejected. However, it is possible the transactions rejected on the shorter chain have been included in other blocks on the longest chain. # Finality in a Proof-of-Stake (PoS) Different Proof-of-Stake (PoS) based blockchains have different designs for attaining finality. Attaining finality in PoS systems is a major discussion in today's PoS blockchain based systems. Ethereum uses the [Casper protocol ](https://academy.binance.com/en/articles/ethereum-casper-explained)to achieve finality. Casper manages finality by using "checkpoint" blocks. The first block in each epoch is a checkpoint. Validators vote for pairs of checkpoints that it considers to be valid. If a pair of checkpoints attracts votes representing at least two-thirds of the total staked ETH, the checkpoints are upgraded. The more recent of the two (target) becomes "justified". The earlier of the two is already justified because it was the "target" in the previous epoch. Now it is upgraded to "finalized". See more here: # Finality on Botanix The Botanix EVM inherits finality from Bitcoin's PoW. Finality, one of the biggest issues in traditional Layer 1 PoS blockchains is solved by building it on top of a PoW. Let's dig deeper. Bitcoin reaches finality by having a longest chain with the most computing power. This is the reason why people sometimes refer to Bitcoin as being "backed by energy". By being inherently connected to Bitcoin, the Botanix EVM can inherit this finality. Other protocols that use Bitcoin's PoW for finality are Stacks and Babylon. ### How does the Botanix EVM achieve Finality? A Proof-of-Stake protocol needs to make sure that at a certain point a transaction becomes unchangeable. Traditional PoS chains implement different type of finality algorithms to achieve finality. By the inherent connection with Bitcoin, Orchestrators will post the root hash of the current Botanix EVM [Merkle Tree ](https://www.gemini.com/cryptopedia/merkle-tree-blockchain-merkle-root)to Bitcoin. More precisely, every Bitcoin block, the current Orchestrator will inscript the Merkle Tree root hash on Bitcoin. See [here](https://en.bitcoin.it/wiki/OP_RETURN) more on [inscriptions](https://docs.ordinals.com/inscriptions.html). Inscriptions are a method where you can post arbitrary data to the Bitcoin blockchain. The Botanix EVM will use this to post the root hash. Once Bitcoin achieves finality, the root hash data is forever posted on Bitcoin. When this happens, the Botanix EVM by inheritance achieves finality. Transactions on the Botanix EVM from before this certain root hash are forever final. #### Malicious Orchestrators posting the wrong Merkle Tree root hash A malicious Orchestrator could post a single wrong Merkle Tree root hash to the Bitcoin blockchain. This will however be obvious to all other node runners: Let's call the wrong root hash posted to Bitcoin in an OP\_RETURN ***root hash A*** and the actual merkle root hash of the Botanix EVM block ***root hash B*** where ***root hash A*** =/= ***root hash B***. As part of the PoS consensus, the Orchestrator communicates the currently built block, containing ***root hash B,*** to all the other stakers. All other stakers however also run Bitcoin and therefore witness the posting of ***root hash A.*** This means the malicious action is now exposed for all Orchestrators to see. The posting of a wrong Merkle Tree root hash means the Botanix EVM does not achieve finality for this current Bitcoin block and is a slash-able action. The malicious Orchestrator will therefore get his stake slashed. #### Malicious Orchestrators posting multiple Merkle Tree root hashes A malicious Orchestrator could post a two different Merkle Tree root hashes to the Bitcoin blockchain: the correct one and a wrong one. This will however be obvious to all other node runners: Let's call the wrong root hash posted ***root hash A*** and the actual Merkle Tree root hash of the Botanix EVM block ***root hash B*** where ***root hash A*** =/= ***root hash B***. The malicious Orchestrator then posts both ***root hash A*** and ***root hash B*** to Bitcoin in two different OP\_RETURNs. As part of the PoS consensus, the Orchestrator communicates the currently built block, containing ***root hash B,*** to all the other stakers. All other stakers however also run Bitcoin and therefore also witness the wrong OP\_RETURN posting of ***root hash A.*** This means the malicious action is now exposed for all Orchestrators to see. The posting of a wrong merkle root is an unexpected and incorrect action for a Orchestrator and is a slashable action. The malicious Orchestrator will therefore get his stake slashed. # Distributed Key Generation (DKG) {% hint style="info" %} **Learn More** For detailed technical information about DKG and FROST implementation in Botanix, read the full technical analysis: [Botanix's Spiderchain: DKG & FROST](https://botanixlabs.com/blog/botanix-s-spiderchain-dkg-frost) {% endhint %} ### What is DKG? Distributed Key Generation (DKG) is a cryptographic process that allows multiple participants to jointly generate a public/private keypair without any single party knowing the complete private key. Think of it as a group of people collectively creating a master key to a vault, where each person only knows their piece of the key, but together they can still open the vault. In the context of Botanix, DKG enables a randomly selected subset of Orchestrator nodes to jointly generate new multisig keys for securing Bitcoin deposits, with no individual Orchestrator having full knowledge of the private key. ### Why Do We Need DKG? #### **The Spiderchain Challenge** Botanix's Spiderchain creates a unique challenge that traditional cryptographic approaches can't solve efficiently. With each Bitcoin block (approximately every 10 minutes), the system needs to create a new threshold multisig address controlled by a randomly selected subset of Orchestrator nodes. Each Bitcoin deposit lives in one of these multisig addresses with randomly chosen signers, creating a constantly evolving security landscape. Traditional Bitcoin multisig would require revealing multiple public keys and signatures on-chain for every transaction, making large groups of signers extremely expensive and revealing exactly how many participants are involved. This approach simply doesn't scale when you need 12 out of 16 signers (or more) for security, and it provides no privacy protection. #### **The Permissionless Problem** As Botanix evolves toward full decentralization, the system needs to accommodate changing validator sets without requiring trusted setup ceremonies. Traditional multisig federations are static—when membership changes, you need to create entirely new addresses and move all funds, which is both expensive and operationally complex. DKG solves this by enabling any group of validators to jointly generate new multisig keys without any single party controlling the process or knowing the complete private key. This makes truly permissionless operation possible, where anyone can stake Bitcoin and participate in securing the network without requiring approval from existing validators or centralized authorities. ### How DKG Works on Botanix #### **The DKG Process** When Botanix needs to create a new multisig (with each Bitcoin block), the selected Orchestrators run a multi-round DKG protocol: 1. **Share Generation**: Each Orchestrator creates a secret polynomial and computes multiple secret shares, one for each participant. They also create cryptographic commitments to verify share consistency. 2. **Exchange**: Orchestrators exchange their commitments and encrypted secret shares with the group, broadcasting commitments while sending shares privately to intended recipients. 3. **Verification**: Each Orchestrator uses published commitments to verify that every share they received is valid, identifying any faulty participants who sent bad shares. 4. **Public Key Computation**: Once all shares are verified, Orchestrators compute the group's joint public key (the multisig address) by combining their contributions, excluding any detected bad actors. The result is a shared threshold key where each Orchestrator holds a secret share, and any threshold number (e.g., 12 out of 16) can later sign transactions collectively. #### **The DKG State Machine** Botanix doesn't just use standard DKG—it implements a sophisticated **DKG State Machine** designed for real-world conditions: * **Fault Tolerance**: Operates reliably even under adverse network conditions, tolerating packet loss during communication rounds. * **Retry Logic**: If packets are lost or delayed, the system retries and uses timeouts to continue attempting the protocol until a message quorum is reached. * **Phase Transitions**: Breaks the DKG process into defined stages (waiting for commitments, then transitioning to shares, etc.) so Orchestrators can "catch up" if messages arrive late or out of order. * **Auto-Reset Mechanism**: If the DKG process cannot be completed within a certain timeframe, the coordinator automatically resets with freshly generated packages, requiring all participants to regenerate theirs. ### Advantages of Botanix's DKG State Machine #### **Network Resilience** The State Machine approach provides critical advantages for a permissionless system: * **High latency tolerance**: Works even when network communication is slow * **Packet loss recovery**: Continues operating despite lost or delayed messages * **Asynchronous operation**: Doesn't require perfect timing between participants * **Automatic recovery**: Can reset and retry when faced with failures #### **Dynamic Participation** Unlike other threshold signature mechanisms: * **Seamless onboarding**: New Orchestrators can join without disrupting existing operations * **Graceful exit**: If an Orchestrator goes offline, future multisigs simply won't include them * **Evolving composition**: The set of Orchestrators can change over time as new multisigs are formed * **No trusted setup**: Eliminates the need for pre-established keys or trusted dealers #### **Scalability Benefits** The DKG approach enables: * **Large validator sets**: Can handle many more participants than traditional multisig * **Efficient operations**: Creates single signatures regardless of participant count * **Reduced coordination**: Less communication overhead compared to alternatives * **Permissionless growth**: Supports transition to fully open validator participation ### Integration with FROST DKG works hand-in-hand with FROST (Flexible Round-Optimized Schnorr Threshold Signatures): * **DKG**: Generates the shared keys for each multisig group * **FROST**: Uses those keys to create aggregated signatures for transactions * **Together**: Enable efficient threshold signatures that appear as single signatures on-chain ### Key Takeaways * **DKG enables groups to generate shared keys** without any single party knowing the complete private key * **The DKG State Machine** provides fault tolerance for real-world network conditions * **Dynamic participation** allows changing validator sets without trusted setup * **Superior scalability** compared to traditional multisig approaches * **Foundation for permissionless operation** as Botanix evolves toward full decentralization DKG represents a critical innovation that makes Botanix's vision possible—combining Bitcoin's security with advanced cryptographic techniques to create a truly decentralized, scalable Layer 2 solution. *** # FROST {% hint style="info" %} L**earn More** For detailed technical information about DKG and FROST implementation in Botanix, read the full technical analysis: [Botanix's Spiderchain: DKG & FROST](https://botanixlabs.com/blog/botanix-s-spiderchain-dkg-frost) {% endhint %} ### What is FROST? FROST (Flexible Round-Optimized Schnorr Threshold Signatures) is a specialized cryptographic protocol that enables multiple participants to collectively produce a valid Schnorr signature without any single participant knowing the complete private key. Unlike traditional multisignature schemes that create multiple signatures, FROST allows a threshold group of signers to collaboratively create a single aggregated signature that appears identical to a signature produced by a single party. The protocol was originally developed by cryptographers [Chelsea Komlo and Ian Goldberg](https://eprint.iacr.org/2020/852.pdf?ref=glossary.blockstream.com) to address the network overhead and coordination challenges inherent in threshold signature schemes. FROST optimizes Schnorr threshold signatures by requiring minimal communication rounds and avoiding single points of failure while maintaining strong security properties. In simple terms, FROST enables 12 out of 16 Orchestrators to jointly sign a Bitcoin transaction, but the resulting signature looks exactly like it came from a single signer. This elegant approach saves block space, enhances privacy, and reduces transaction fees compared to traditional multisignature methods. ### Why Do We Need FROST? Once the Spiderchain's [DKG](/botanix/get-to-know-botanix/advanced/distributed-key-generation-dkg) process establishes shared keys among Orchestrator groups, the system needs an efficient way to use those keys for transaction signing. This is where FROST becomes essential for Botanix's architecture. Traditional Bitcoin multisig approaches suffer from significant limitations when dealing with large groups of signers. A 12-of-16 multisig would require revealing 16 public keys and 12 signatures on-chain, creating enormous transaction sizes and fees. The blockchain would also reveal exactly how many participants were involved and which ones signed, compromising privacy and fungibility. FROST solves these problems by compressing all threshold signing activity into a single signature that's indistinguishable from standard single-party signatures. When users withdraw Bitcoin from Botanix, they see a normal-looking Bitcoin transaction, even though it was actually authorized by a distributed group of Orchestrators. This approach eliminates the scalability bottlenecks and privacy issues that would make large-scale threshold operations impractical with traditional methods. ### How FROST Works on Botanix #### **Integration with Spiderchain** FROST operates as the second phase of Botanix's threshold cryptography system. After DKG establishes shared keys for a group of Orchestrators, FROST uses those keys to create signatures for Bitcoin transactions. The process is seamlessly integrated into Botanix's peg-in and peg-out operations. For peg-in transactions, FROST isn't needed initially. The DKG process generates the public key that creates the Bitcoin address where users deposit funds. However, when those funds need to be spent during peg-out operations, FROST becomes critical for creating the authorization signatures. #### **The FROST Signing Process** When Botanix needs to process a withdrawal, the relevant Orchestrators run a two-round FROST protocol. In the commitment round, each participating Orchestrator picks a random nonce and shares a commitment to that nonce with the others. This can be done efficiently through broadcast communication or pairwise exchanges. In the signature round, one Orchestrator computes a challenge using the transaction message and all signers' nonce commitments, then shares this challenge with the group. Each participating Orchestrator uses their secret key share and nonce to produce a partial signature. These partial signatures are collected and mathematically combined into the final Schnorr signature that authorizes the Bitcoin transaction. #### **Peg-Out Operations** The practical application of FROST in Botanix is most visible during peg-out transactions. When users withdraw Bitcoin from Botanix back to the Bitcoin mainnet, the system creates a Bitcoin transaction that spends from one of the Spiderchain multisig UTXOs. Since this UTXO is controlled by a threshold key shared among the block's Orchestrators, these validators must jointly authorize the spending. The FROST protocol enables these Orchestrators to produce a single valid signature under the multisig public key. This signature is included in the Bitcoin transaction, allowing it to be broadcast to the Bitcoin network and mined into a block. From Bitcoin's perspective, the transaction appears completely normal, with no indication that multiple parties were involved in its authorization. #### **Botanix's FROST Advantages** Botanix's implementation of FROST provides several key advantages over traditional approaches. The on-chain footprint is dramatically reduced because threshold signatures always appear as a single public key and signature, regardless of how many participants are involved. A 15-of-15 multisig operation produces the same on-chain footprint as a single-signer transaction. Privacy is significantly enhanced because the resulting signatures are indistinguishable from single-party transactions. External observers cannot determine whether Bitcoin was secured by 5 validators or 50, nor can they identify which specific validators participated in signing. This improves Bitcoin's fungibility and protects the operational details of the Spiderchain. The security model remains robust because FROST maintains the same threshold assumptions as traditional multisig while eliminating coordination overhead. If one key share is compromised, the attacker still needs the threshold number of shares to create valid signatures. The protocol also includes protection against sophisticated attacks like those identified by Drijvers et al., binding each participant's response to specific messages and participant sets. ### Key Takeaways * **FROST enables efficient threshold signatures** by aggregating multiple participants' signatures into a single Schnorr signature indistinguishable from single-party signatures * **Seamless Bitcoin integration** allows large groups of validators to authorize transactions without revealing their participation or increasing transaction costs * **Privacy and scalability benefits** solve the fundamental limitations of traditional multisignature approaches for large validator sets * **Critical for Botanix operations** as it enables the Spiderchain to authorize Bitcoin withdrawals while maintaining the appearance of normal Bitcoin transactions * **Proven cryptographic security** with protection against known attacks and formal security proofs under standard cryptographic assumptions FROST represents the final piece of Botanix's threshold cryptography puzzle, working with DKG to enable truly scalable and private threshold operations on Bitcoin. Together, these protocols make it possible for Botanix to operate a large, decentralized network of validators while maintaining the efficiency and privacy properties that Bitcoin users expect. *** More information on FROST can be found by reading its official [whitepaper](http://eprint.iacr.org/2020/852.pdf?ref=glossary.blockstream.com) and watching the visual explainer below, provided by Blockstream. {% embed url="" %} # Reth ### What is Reth? [Reth](https://github.com/paradigmxyz/reth/) (short for Rust Ethereum) is a high-performance Ethereum execution client implementation written in Rust. It's a full-node implementation of the Ethereum protocol that focuses on being user-friendly, highly modular, fast, and efficient. Originally built by [Paradigm](https://paradigm.xyz/) and released under Apache/MIT licenses, Reth serves as the execution layer that handles transaction processing, state management, and smart contract execution. As an execution client, Reth is compatible with all Ethereum consensus layer implementations that support the [Engine API](https://github.com/ethereum/execution-apis/tree/59e3a719021f48c1ef5653840e3ea5750e6af693/src/engine). It can sync the complete Ethereum blockchain from genesis and provide full interaction capabilities with the Ethereum network, including sending and receiving transactions, accessing smart contracts, and maintaining historical state data. ### Why Do We Use Reth? Botanix chose Reth as its execution client because it aligns perfectly with the project's performance and modularity requirements. Reth's architecture offers several key advantages that make it ideal for Layer 2 implementations like Botanix. **Performance is Critical**: Reth was designed from the ground up for optimal performance, using Rust's memory safety and zero-cost abstractions combined with the proven Erigon staged-sync architecture. This results in faster sync times, lower resource consumption, and better overall efficiency compared to traditional Ethereum clients. For a Layer 2 that needs to process high transaction volumes with low latency, this performance advantage is essential. **Modular Design**: Reth's highly modular architecture allows components to be unbundled and customized for specific use cases. This modularity is particularly valuable for Layer 2 implementations that need to modify certain aspects of the execution environment while maintaining compatibility with Ethereum tooling and standards. **EVM Compatibility**: Since Botanix provides full EVM compatibility, using an execution client that implements the Ethereum specification precisely ensures seamless compatibility with existing Ethereum tools, wallets, and applications. Reth's strict adherence to Ethereum specifications means developers can port their applications to Botanix with confidence. ### How Botanix Uses Reth Botanix leverages Reth as its core execution engine, adapting it to work within the unique Spiderchain architecture while maintaining full EVM compatibility. The integration involves several key components and modifications. Reth handles all smart contract execution and state management on the Botanix Layer 2. When users interact with DeFi applications, trade tokens, or execute any smart contract operations, Reth processes these transactions using the same EVM implementation that powers Ethereum mainnet. This ensures that applications behave identically on both networks. The execution client manages Botanix's account-based state model, which differs from Bitcoin's UTXO model. Reth maintains account balances, smart contract storage, and transaction history in an efficient database structure optimized for fast queries and updates. This state management is crucial for supporting the complex interactions required by DeFi protocols. Botanix uses Reth's JSON-RPC interface to provide standard Ethereum API compatibility. This means wallets like MetaMask, development tools like Hardhat, and other Ethereum ecosystem tools work seamlessly with Botanix without requiring any modifications. The API provides access to transaction history, contract state, gas estimation, and all other standard Ethereum functionality. The integration also takes advantage of Reth's advanced tracing and debugging capabilities. These features are essential for developers building on Botanix, as they provide detailed insights into transaction execution, gas usage, and contract interactions that help optimize applications and troubleshoot issues. ### Sources * Reth Book - # Security Answer questions like: * is my bitcoin safe? * Why is it safe? * Decentralized fderation * Multiple audit * trusted organizations * Skilled people # Forward security One of the novel breakthroughs of the [Spiderchain](/botanix/get-to-know-botanix/intermediate/the-spiderchain) is its "Forward Security". Traditionally used in cryptographic encryption protocols ensuring private keys are long term secure, we applied the same principles to blockchain security. In the next pages we'll first introduce forward security in its traditional meaning in cryptography and then how we apply it in the Spiderchain. # Forward security in cryptography **Forward security**, also known as future security, is a concept in cryptography that pertains to the resilience of cryptographic systems against the compromise of long-term secret keys. The idea behind forward security is to ensure that even if an attacker manages to acquire a cryptographic key at some point in the future, they should not be able to decrypt past communications or transactions that were secured using that key before it was compromised. Forward security is crucial because in many cryptographic protocols and systems, compromising a long-term key can have catastrophic consequences, potentially leading to the decryption of sensitive information, exposure of past transactions, or even the undermining of the entire security framework. To achieve forward security, cryptographic protocols often utilize techniques such as key rotation and the use of ephemeral keys. Here's a brief explanation of each: 1. **Key Rotation:** Instead of relying on a single long-term key for an extended period, key rotation involves periodically changing the cryptographic keys used in a system. This limits the impact of key compromise, as even if an attacker gains access to a current key, they won't be able to decrypt communications secured with previous keys. 2. **Ephemeral Keys:** Ephemeral keys are short-lived keys generated for each individual communication session or transaction. These keys are used only for a limited period and are discarded after their use. Even if an attacker manages to obtain an ephemeral key, it will have no impact on past or future sessions. Both these techniques contribute to forward security by reducing the potential damage caused by key compromise. In systems that prioritize forward security, the compromise of a secret key should not lead to the retroactive compromise of historical data or the keys used in previous sessions. This property is essential for maintaining the confidentiality and integrity of sensitive information in cryptographic systems, particularly in scenarios where security breaches are discovered after the fact. ## Forward security or forward secrecy? The terms "forward security" and "forward secrecy" often refer to the same concept in the context of cryptographic communications. Both terms describe a security property of encryption protocols where session keys used to encrypt and decrypt messages will not be compromised even if the private keys of the communicating parties are compromised in the future. This means that past communication sessions remain secure and private, even if future security breaches occur. While "forward secrecy" is the more commonly used term, some sources might use "forward security" interchangeably. # The Spiderchain's Forward Security Similar to how encryption protocols are vulnerable to long term key exposure, the bitcoin secured in a Layer 2 Proof-of-Stake protocol is vulnerable to an attacker gaining majority control of the stake. In the case of the Botanix EVM where we stake bitcoin on Bitcoin, the protocol needs to be able to defend itself against a malicious actor gaining 2/3rds majority of the staked Bitcoin. This is where the Spiderchain's forward security comes into play. When at a certain point, a malicious actor gains 2/3rds majority of the stake, he will not be able to steal any bitcoin because of the Spiderchain's design. Every bitcoin block, a new multisig is generated between 100 random Orchestrators. So after a while the bitcoin in the Spiderchain is split among numerous different multisig wallets that were previously generated. 1. **Multisig rotation:** new bitcoin entering the Spiderchain will be stored in new multisigs controlled by random Orchestrators. The security of that new bitcoin is then dependent on the decentralization and security of the staking pool at that specific moment. This ensures future malicious actors will never be able to have control over the older established multisigs. 2. **Liveness Epochs:** Because the bitcoin is stored in FROST multisigs between Orchestrators, after every epoch a new set of keys is generated between the Orchestrators. This allows for the protocol to verify the liveness of each Orchestrator. 3. **LIFO management:** In order to protect the bitcoin stored in older established wallets, a LIFO inventory management is chosen. These techniques contribute to the forward security by reducing the potential damage caused by a malicious attacker gaining majority control over the stake. In systems that prioritize forward security, the compromise of a a 2/3rd majority should not lead to the retroactive compromise of the bitcoin stored. This property is essential for maintaining the security and integrity of the value on the Spiderchain. # Inventory management When completing a bridge-out, there are different ways possible to choose which bitcoin UTXOs in the Spiderchain to take. These different options share similarities with inventory management. There is LIFO (Last In First Out) and FIFO (First In First Out) and various hybrid solutions.\ Each of the three have benefits and cons. In the case of FIFO the coins are refreshed the fastest, and any potential malicious adversary will have to wait a certain amount before the coins are turned around and the forward security of the spiderchain is lost. LIFO on the other hand will ensure the oldest coins are secured by the oldest orchestrators, therefore giving a malicious adversary no chance to gain control of these older coins. Botanix Labs has chosen LIFO bitcoin management because of the higher security guarantees. # Bitcoin security inheritance The security of Botanix depends on that of Bitcoin, particularly the security features provided by its Proof of Work (PoW) system. If Bitcoin’s security were to be compromised, it would also have a negative impact on the security of Botanix. More specifically, three risks in any Proof of Stake system are mitigated by leveraging Bitcoin: 1. Decentralization 2. Finality 3. Randomized Validator Selection ## 1. Decentralization The security of a proof of stake (PoS) system is closely tied to its initial coin distribution and it's (de)centralization trend over time. More specifically: 1. When a new Proof of Stake launches, it needs to distribute the initial coins in a fair and decentralized way 2. Over time the consensus should ensure that the coins become more and more decentralized. ### The initial distribution Various methods, including airdrops, can be designed to ensure the initial coins are distributed with maximal fairness. Nevertheless, among all the distinct cryptocurrencies, Bitcoin stands out for having achieved the most impartial initial distribution. This factor has played a crucial role in its decentralization. During Bitcoin's inception, very few anticipated its enduring survival and remarkable value growth. It was primarily regarded as a novel collectible and an enjoyable experiment, which ultimately resulted in a substantial loss of many initial bitcoins over time. ### The decentralization trend over time Proof of Stake (PoS) algorithms, which are closed systems, often exhibit a tendency towards centralization over time. This is primarily attributed to the way PoS functions. In a PoS network, validators are chosen to create new blocks and validate transactions based on the amount of cryptocurrency they hold and are willing to "stake" as collateral. As the system progresses, validators with larger stakes will accumulate more rewards, and eventually gain a bigger and bigger share of the total supply. Over time, this dynamic can lead to an accumulation of wealth and influence among a small subset of participants with significant stakes. As their stake grows, their influence over the network's decisions and operations increases, potentially concentrating power and control. In contrast, Proof of Work (PoW) consensus mechanisms, like Bitcoin, have a decentralizing effect due to being a leaking system (in comparison to a closed PoS). PoW requires miners to use a significant amount of computational power. This process demands substantial energy expenditure and specialized hardware, which ensures that "money" is expended into the real world (hence a "leaking system"). this makes it less vulnerable to concentration over time. While PoS algorithms can lead to centralization in closed systems due to the accumulation of stake, PoW's energy-intensive requirements contribute to a more decentralized distribution. ### Botanix inherits Bitcoin's decentralization Botanix inherits both the initial fair launch of Bitcoin and the general decentralization trend of Bitcoin. While the argument can be made that Botanix as a Proof of Stake has a centralizing trend, this will always be trumped by the overall decentralization trend of Bitcoin's Proof of Work. ## 2. Finality See more in the section [Finality](/botanix/get-to-know-botanix/advanced/finality) to see how Botanix leverages Bitcoin's Proof of Work to inherit Bitcoin's finality and thereby solves of the biggest problems in any Proof of Stake blockchain. ## 3. Randomized Validator Selection In a proof of stake (PoS) system, validators are typically selected to create new blocks in a randomized manner, with the probability of selection being proportional to the amount of stake that the validator holds. This randomization process is intended to ensure that the system is fair and decentralized, as it allows anyone with a stake in the network to have a chance of being selected as a validator. Randomization is however a difficult problem to solve and the randomization process could be manipulated or gamed in some way, either through collusion or by an individual or organization with a large stake trying to increase their chances of being selected as a validator. Proof of Work solves this by spending energy and solving the difficulty problem. The process of finding a hash is essentially a random one, as miners must try different combinations of inputs (i.e. ”nonces”) until they find a solution that meets the required criteria. The miner solving the current block in Bitcoin’s Proof of Work first is a verifiable random event. A miner finding the solution does have the opportunity to withhold its result and yielding the block reward. Since the benefit (the Bitcoin block reward) of withholding a block is negligible to the edge the miner gains in Orchestrator selection, the Bitcoin block hash production is verifiable random for the purpose of Orchestrator selection. Botanix leverages the randomization from Bitcoin’s Proof of Work to ensure a fair Orchestrator selection. # Security in the Fully Decentralized Spiderchain {% hint style="info" %} **Security in Founding Federation** Want to read more about the current state of how your funds are secured in the Founding Federation, read more here: [Security Model](/botanix/get-to-know-botanix/roadmap-to-spiderchain/founding-federation/security-model) {% endhint %} ### Overview When Botanix reaches full maturity, it will operate as a completely permissionless, decentralized network where Bitcoin security is enhanced through multiple layers of cryptographic and economic protection. The complete Spiderchain implementation will provide security guarantees that exceed those of traditional Layer 2 solutions while maintaining Bitcoin's core principles of decentralization and trustlessness. The fully implemented system combines Bitcoin's proven Proof-of-Work security with advanced threshold cryptography, economic incentives through staking and slashing, and a dynamic multisig architecture that continuously evolves to prevent attacks and maintain decentralization. ### Dynamic Multisig Architecture #### **Continuous Key Rotation** In the fully decentralized Spiderchain, security is maintained through continuous rotation of multisig wallets. With each Bitcoin block (approximately every 10 minutes), new multisig addresses are created using fresh threshold keys generated by randomly selected Orchestrator nodes. This means that every Bitcoin deposit is secured by a unique multisig configuration that an attacker cannot predict or target in advance. The dynamic nature of this system provides unprecedented security compared to static multisig approaches. Even if an attacker somehow compromises a current group of Orchestrators, they cannot access Bitcoin deposits secured by previous multisig configurations. Historical deposits remain protected by the keys that secured them originally, implementing a form of temporal security isolation. #### **Forward Security Protection** The Spiderchain's forward security design ensures that even in the unlikely event of a catastrophic compromise—such as an attacker gaining control of a 2/3 majority of current Orchestrators—all previously deposited Bitcoin remains secure in older multisig wallets. This creates a security model where the impact of any potential attack is limited to new deposits, while the vast majority of user funds remain protected. The LIFO (Last-In-First-Out) spending approach further enhances this protection by ensuring that the newest deposits are spent first during withdrawals. This means that even if an attacker manages to compromise current keys, they cannot access the oldest and most established Bitcoin deposits, which represent the bulk of user funds. ### Permissionless Orchestrator Network #### **Open Participation** When fully decentralized, anyone can become an Orchestrator by staking Bitcoin and meeting basic technical requirements. This open participation model ensures that the network cannot be captured by any single entity or group, as the validator set is determined by economic participation rather than political decisions. The permissionless nature means that the network can scale to support thousands of Orchestrators globally, creating a level of decentralization that exceeds most blockchain networks. With potentially thousands of independent operators, the network becomes extremely resilient to attacks, regulatory pressure, or other forms of interference. #### **Geographic and Operational Diversity** A large, permissionless Orchestrator set naturally leads to geographic and operational diversity. Orchestrators will be distributed across different countries, regulatory jurisdictions, infrastructure providers, and operational setups. This diversity makes coordinated attacks practically impossible and ensures the network can continue operating even if entire regions experience disruptions. The diversity extends beyond geography to include different hardware configurations, network setups, security practices, and operational procedures. This heterogeneity makes the network extremely robust against both targeted attacks and systemic failures. ### Economic Security Through Staking #### **Bitcoin-Denominated Stakes** All Orchestrators must stake their own Bitcoin to participate in the network, creating perfect alignment between their interests and network security. Unlike other networks where validators stake secondary tokens, Botanix validators risk the same asset they're protecting—Bitcoin itself. The staking requirement ensures that Orchestrators have significant "skin in the game." Malicious behavior results in the loss of valuable Bitcoin, creating strong economic incentives for honest participation. As Bitcoin's value increases, so does the cost of attacking the network. ### Slashing Mechanisms #### **Automated Punishment** The slashing system automatically punishes malicious or negligent behavior by destroying a portion or all of an Orchestrator's staked Bitcoin. This creates immediate and severe consequences for attacks, operational failures, or protocol violations. Slashing conditions include attempting to spend from multisigs dishonestly, being offline during critical operations, participating in double-spending attempts, or coordinating with other malicious actors. The automated nature of slashing ensures that punishment is swift and certain. #### **Graduated Penalties** Different violations trigger different slashing penalties, from minor stake reductions for operational failures to complete stake destruction for malicious attacks. This graduated approach ensures that honest mistakes don't result in disproportionate punishment while maintaining severe consequences for intentional attacks. The slashing mechanism is designed to be mathematically provable, meaning that dishonest behavior can be cryptographically demonstrated and automatically punished without requiring human judgment or governance decisions. ### Cryptographic Security Layers #### **Threshold Cryptography Protection** The DKG and FROST protocols ensure that no single Orchestrator ever knows complete private keys, even during the key generation process. This eliminates the possibility of internal theft or key compromise at the individual level. The threshold nature means that even if multiple Orchestrators are compromised, the system remains secure as long as the threshold number of honest participants is maintained. With thousands of Orchestrators and threshold requirements, achieving the necessary compromise becomes practically impossible. #### **Attack Resistance** The combination of forward security, continuous key rotation, and threshold cryptography creates multiple overlapping layers of protection. An attacker would need to: * Compromise a threshold number of current Orchestrators simultaneously * Maintain this compromise across multiple key rotation cycles * Overcome the economic disincentives of losing staked Bitcoin * Coordinate this attack across geographically distributed, independent operators This combination of requirements makes successful attacks economically and technically infeasible. ### Bitcoin Security Inheritance #### **Proof-of-Work Foundation** Even in its fully decentralized state, Botanix continues to inherit Bitcoin's Proof-of-Work security for final settlement and dispute resolution. The Spiderchain's consensus mechanism uses Bitcoin's block hash for randomness and relies on Bitcoin's finality for ultimate security guarantees. This inheritance means that Botanix benefits from the massive hash power securing the Bitcoin network—currently requiring hundreds of billions of dollars in energy and hardware to attack. No attacker can compromise Botanix without also attacking Bitcoin itself. #### **Complementary Security Models** Rather than replacing Bitcoin's security, Botanix's Proof-of-Stake mechanism complements it. Bitcoin's PoW provides immutable history and final settlement, while Botanix's PoS enables fast, efficient operations and programmable functionality. Together, they create a security model that combines the best aspects of both consensus mechanisms. ### Ultimate Security Promise In its fully realized form, Botanix will provide security guarantees that exceed those of traditional financial systems: * **No single point of failure** exists anywhere in the system * **Multiple overlapping protection layers** ensure that no single attack vector can succeed * **Economic incentives** align all participants with network security * **Cryptographic guarantees** eliminate the need for trust in any individual or organization * **Bitcoin's proven security** provides the ultimate foundation for all operations # Security Audits Botanix Labs has conducted comprehensive security audits of its core infrastructure to ensure the highest level of security for users and the protocol. This section provides detailed information about each audit conducted by leading blockchain security firms. ### Overview Botanix has undergone multiple professional security audits covering the critical components of the Botanix ecosystem. Each audit was conducted by specialized security firms with expertise in blockchain and smart contract security. #### Audited Components 1. **Core Logic** - Core protocol logic, consensus mechanisms, and system architecture 2. **stBTC Contract** - Bitcoin staking functionality and vault management 3. **Minting Contract** - Smart contract responsible for minting and burning Bitcoin on Botanix *** ## Core Logic Audit {% file src="/files/i38GO6PdrH2yTfycEPfC" %} ### Audit Overview **Auditor**: Sigma Prime\ **Date**: May 2025\ **Focus**: Comprehensive security review of core protocol infrastructure\ **Type**: Time-boxed security assessment #### Scope **Primary Repository**: **Commit**: 3a5bb70 (initial), 3868b40 (fixes assessment)\ **Languages**: Solidity and Rust\ **Components**: Core protocol logic, consensus mechanisms, network protocols #### Methodology **Solidity Components** * **Manual Review**: Business logic implementation analysis * **Automated Tools**: * Mythril: Symbolic execution analysis * Slither: Static analysis detection * Surya: Code visualization and metrics * Aderyn: Advanced vulnerability detection * **Focus Areas**: Reentrancy, front-running, integer overflow, visibility specifiers **Rust Components** * **Manual Review**: Business logic and language-specific vulnerability analysis * **Automated Tools**: * Clippy: Linting and best practices * Cargo Audit: Dependency vulnerability scanning * Cargo Outdated: Dependency freshness analysis * Cargo Geiger: Unsafe code detection * Cargo Tarpaulin: Code coverage analysis * **Focus Areas**: Memory safety, panic scenarios, error handling, concurrency issues ### Findings Summary **Total Findings**: 34 issues identified | Severity | Count | Status Distribution | | ------------- | ----- | -------------------- | | Critical | 10 | All Resolved | | High | 10 | All Resolved | | Medium | 3 | All Resolved | | Low | 5 | 4 Resolved, 1 Closed | | Informational | 6 | 1 Resolved, 5 Closed | *** ## stBTC Contract Audit {% file src="/files/lcp62mt8lyPRyEwblBgK" %} ### Audit Overview **Auditor**: Sigma Prime & Spearbit\ **Date**: May 2025 \ **Focus**: Bitcoin staking contract security analysis\ **Repository**: ControlCplusControlV/stBTC\ **Commit**: 3d22855 #### Scope The stBTC audit focused on the Bitcoin staking infrastructure, examining: * **ERC4626 Vault Implementation**: Standard compliance and security * **Staking Mechanisms**: Token deposit and withdrawal security * **Reward Distribution**: Fair and secure reward calculation * **Inflation Attack Prevention**: Protection against vault manipulation #### Methodology * **Standard Compliance**: Verification of ERC4626 implementation * **Economic Security**: Analysis of tokenomics and incentive structures * **Attack Vector Analysis**: Focus on known vault vulnerabilities * **Integration Testing**: Compatibility with Botanix ecosystem ### Risk Assessment #### Overall Security Posture * **Implementation Quality**: High-quality implementation based on industry standards * **Attack Resistance**: Strong resistance to common vault attacks * **Economic Security**: Sound tokenomics with low exploitation risk #### Identified Risks * **Theoretical Inflation Attacks**: Very low probability, high complexity scenarios * **Economic Conditions**: Dependency on specific market and timing conditions * **Multi-victim Scenarios**: Requires coordination of multiple factors #### Risk Mitigation * **Design Choices**: Intentional risk acceptance based on low probability * **Monitoring**: Potential for enhanced monitoring systems * **Community Oversight**: Transparent operation and community validation *** ## Minting Contract Audit ### Audit Overview **Auditor**: Hacken\ **Date**: November 6, 2024\ **Focus**: Smart Contract Code Review and Security Analysis\ **Methodology**: Comprehensive analysis following Hacken's established smart contract methodology #### Scope The audit focused on the Minting contract, a crucial component of Botanix's Layer 2 solution for Bitcoin that leverages the EVM as a foundational superstructure. **Repository**: **Commit**: bac1da04873b378d9a195e897fb92c75412a5f72\ **Platform**: Botanix EVM\ **Language**: Solidity #### Methodology The security assessment covered: * Manual code review focusing on business logic implementation * Internal contract interactions verification * Known Solidity anti-patterns and attack vectors identification * Automated testing using industry-standard tools: * Mythril * Slither * Surya * Aderyn #### Key Areas Examined * **Access Control**: Function-level permission verification * **Input Validation**: Parameter sanitization and bounds checking * **Reentrancy Protection**: Guards against recursive call attacks * **Integer Operations**: Overflow/underflow prevention * **Gas Optimization**: Efficient resource usage analysis *** ### Conclusion The comprehensive audit process has significantly strengthened Botanix's security posture across all major components. With all critical vulnerabilities resolved and robust security measures implemented, Botanix provides a secure foundation for Bitcoin Layer 2 operations. Each audit contributed essential security improvements: * **Minting Contract**: Secured core bridging functionality * **Macbeth Repository**: Hardened protocol infrastructure and consensus mechanisms * **stBTC Contract**: Validated staking security and economic models # Proof of Reserves Botanix implements a transparent and verifiable proof of reserves system that allows anyone to independently verify the total amount of Bitcoin locked in the protocol. ### How It Works 1. **Deposit Address Storage**: Each EVM wallet address on Botanix has a corresponding Bitcoin deposit address (gateway address). We store these deposit addresses by listening to mint events emitted when users make pegin claims, and then storing the associated deposit address in our database. 2. **Address Reuse**: Users can reuse the same deposit address for multiple pegins with the same wallet, but the address is only registered once during the initial pegin operation. 3. **Address Discovery**: Users can obtain the complete list of active deposit addresses (those with balance > 0) in two ways: * **API Method**: Query our API endpoint for immediate access to active addresses * **Trustless Method**: Independently derive the address list by listening to mint events from the pegin contract 4. **Balance Verification**: Using the address list, anyone can verify total locked Bitcoin by running Bitcoin Core's `scantxoutset` RPC command, which returns the sum of all UTXOs held by these addresses. ### Benefits * **Real-time Verification**: Check reserves at any time without waiting for periodic audits * **Trustless Auditing**: Completely independent verification possible using only on-chain data * **Transparency**: All deposit addresses and their balances are publicly verifiable on the Bitcoin blockchain * **No Special Tools Required**: Verification only requires a Bitcoin Core node and basic RPC knowledge ### Verification Steps 1. Extract all deposit addresses from pegin contract mint events (or use our API) 2. Run `bitcoin-cli scantxoutset start '["addr(ADDRESS1)", "addr(ADDRESS2)", ...]'` 3. Sum the returned UTXO values to get total locked Bitcoin 4. Compare against circulating supply on Botanix L2 This approach ensures that Botanix operates with full reserves while providing the cryptographic guarantees users expect from blockchain-based systems. {% hint style="info" %} **API Access** If you want access to the API, contact us on [Telegram](https://t.me/+rVo_EOrFXeljN2Vk). {% endhint %} # Roadmap to Spiderchain Rome wasn't built in a day and neither is the Spiderchain. Developing the Spiderchain requires a tremendous engineering effort which is why the development is divided in several key milestones of which you can find an overview in the picture below.

Spiderchain Roadmap (updated February 2025)

On the next pages, you will find more information about each one of the milestones and specifics about the implementation as we work on them. # Single Node (Testnet) {% hint style="info" %} **This version is deprecated** The version of our testnet with a single node, called V0, was live between November 2023 and July 2024. This version is no longer live and the provided documentation is merely intended for the specially interested reader. {% endhint %} The very first version of the Botanix EVM is our MVP (minimum viable product) of which the goal is to showcase the possibilities of having an EVM built on top of Bitcoin and being able to bridge funds from L1 to L2. The Botanix EVM at this stage consists of: * A **single Botanix block producer** that assumes the responsibility of mining and producing blocks * A **decentralized application** (dApp) that serves as the front-end interface with mainly two functions: * Bridge: User interface that enables pegging in and pegging out of the Bitcoin Signet network to the Botanix Testnet * Faucet: User interface that enables getting some free Botanix testnet funds * **Side Car Server** which streamlines and simplifies the complex pegging procedure. * **BTC Signer** which is a solitary signer accessible via gRPC and has the following responsibilities * Administer a database of spendable Unspent Transaction Outputs (UTXOs) while dynamically updating this inventory upon the introduction of new peg ins and outs * Expose an endpoint facilitating the retrieval of its internal taproot key's public key * Shoulder the responsibility of executing all pegouts by orchestrating the construction of a bitcoin transaction, drawing from the available pool of UTXOs.
# Founding Federation Botanix operates as a Bitcoin Layer 2 network through a carefully designed federation model that prioritizes security, efficiency, and user experience. This section explains how Botanix works in its current implementation, covering the key components and processes that enable fast, secure Bitcoin transactions while maintaining full EVM compatibility. ### Development Journey In November 2024, Botanix Labs launched **Botanix Testnet V1** as our next public testnet version, replacing the previous testnet infrastructure. This release marked a crucial milestone in our development journey, providing a robust testing environment for continued mainnet development while allowing us to battle-test the federation network, consensus mechanisms, and block production systems under real-world conditions. Testnet V1 served dual purposes: enabling our development team to refine the protocol toward mainnet readiness, while providing infrastructure partners and decentralized application developers with a stable platform to test their products on our chain. This collaborative testing environment proved invaluable for identifying optimization opportunities and ensuring ecosystem readiness. After approximately 7 months of intensive battle-testing and development on Testnet V1, the proven architecture and operational procedures formed the foundation for **Botanix Mainnet**. With mainnet launch, Botanix truly comes to life as users can peg in their actual Bitcoin and begin exploring the rich world of decentralized applications built on top of Bitcoin. ### How Botanix Works Today The Botanix network is secured and operated by a federation of 16 trusted entities from the Bitcoin ecosystem. These federation members collectively manage Bitcoin custody through advanced cryptographic techniques, produce blocks using Byzantine Fault Tolerant consensus, and facilitate seamless bridging between Bitcoin and Botanix. Unlike traditional proof-of-work or proof-of-stake networks, Botanix uses a Proof of Authority model where security derives from the reputation and economic stake of known, trusted operators. This approach enables immediate transaction finality, predictable performance, and institutional-grade security for Bitcoin custody. ### What You'll Learn The following chapters provide a comprehensive understanding of Botanix's current architecture, refined through months of testnet operations and now powering mainnet: [**Federation Overview**](/botanix/get-to-know-botanix/roadmap-to-spiderchain/founding-federation/federation-overview) explains the 16-member federation model, why it was chosen, and how these trusted entities secure the network through collective responsibility and economic alignment. [**Consensus Mechanism**](/botanix/get-to-know-botanix/roadmap-to-spiderchain/founding-federation/consensus-mechanism-cometbft) covers how Botanix uses CometBFT to achieve fast finality and high throughput, explaining the advantages over other consensus mechanisms like Ethereum's Casper. [**Bridging**](/botanix/get-to-know-botanix/roadmap-to-spiderchain/founding-federation/bridging-peg-in-peg-out) details the complete process for moving Bitcoin to Botanix (peg-in) and back (peg-out), including timing, security measures, and user experience considerations. [**DKG and FROST Overview**](/botanix/get-to-know-botanix/roadmap-to-spiderchain/founding-federation/dkg-and-frost) provides an accessible introduction to the advanced cryptographic techniques that enable distributed custody without single points of failure. [**Block Production and Validation**](/botanix/get-to-know-botanix/roadmap-to-spiderchain/founding-federation/block-production-and-validation) explains how federation members collaborate to create blocks, validate transactions, and maintain network consensus in real-time. [**Security Model**](/botanix/get-to-know-botanix/roadmap-to-spiderchain/founding-federation/security-model) outlines the multi-layered security approach that protects user funds, from economic incentives and cryptographic protections to operational safeguards and emergency procedures. ### Design Philosophy Botanix's current implementation reflects a pragmatic approach to Bitcoin scaling that prioritizes user experience, security and the right amount of decentralization to bootstrap the network. By leveraging trusted entities with proven track records in the Bitcoin ecosystem, Botanix can provide immediate benefits to users while maintaining the flexibility to evolve toward greater decentralization as the network matures. The months of testnet operation validated this approach, demonstrating that the federation model can deliver fast, low-cost transactions with immediate finality, full EVM compatibility for smart contracts and DeFi applications, and institutional-grade security for Bitcoin holdings—all while maintaining the fundamental properties that make Bitcoin valuable. This battle-tested foundation now enables real Bitcoin holders to access Layer 2 capabilities with confidence, knowing the system has been thoroughly validated through extensive testing and operational experience. # Federation Overview The Botanix Federation forms the backbone of Botanix, providing secure Bitcoin bridging and block production through a carefully selected group of trusted operators. This chapter explains the federation model, its composition, and its critical role in maintaining network security and functionality. ### What is the Botanix Federation? The Botanix Federation is a group of 16 trusted entities responsible for: * **Bitcoin Custody**: Securing Bitcoin deposits through multi-signature control * **Block Production**: Creating and validating blocks on the Botanix network * **Bridge Operations**: Facilitating secure transfers between Bitcoin and Botanix * **Network Governance**: Maintaining network parameters and protocol upgrades The federation operates as the initial security model for Botanix, ensuring reliable and secure operations while the network establishes itself and grows. ### Why a Federation Model? #### Security Through Trusted Operators A federation model provides immediate security by leveraging the reputation and operational expertise of established Bitcoin ecosystem participants. Rather than relying on anonymous validators or energy-intensive mining, Botanix uses known entities with proven track records in blockchain infrastructure operations. This approach ensures operational reliability with consistent block production and bridge operations, while providing regulatory clarity through identifiable entities that can be held accountable for their actions. The federation model also enables rapid network launch with proven security properties from day one. #### Bridge Security Requirements Bitcoin's unique characteristics require special consideration for Layer 2 bridges. Bitcoin transactions require multiple confirmations for security, cannot be easily reversed once confirmed, and operate on a UTXO model that requires complex management. Additionally, protecting Bitcoin private keys requires institutional-grade security practices. A federation of trusted operators provides the necessary security guarantees while maintaining the operational efficiency required for a responsive Layer 2 network. ### Federation Composition #### 16 Trusted Members The Botanix Federation consists of 16 carefully selected members, chosen through a rigorous evaluation process. Selection criteria include proven technical expertise in blockchain infrastructure, established reputation within the Bitcoin ecosystem, geographic distribution for network resilience, and significant economic alignment with network success. Federation members include maj[^1]or Bitcoin mining pools with infrastructure expertise, established cryptocurrency exchanges with custody experience, blockchain infrastructure specialists, cryptocurrency-focused investment firms, and blockchain technology companies with operational capabilities. The 16-member structure provides an optimal balance between security and operational efficiency. This size is large enough to prevent centralization while remaining small enough for effective coordination and decision-making.
### Proof of Authority (PoA) Model Botanix implements a Proof of Authority consensus model where network security derives from the known identities and reputations of validators rather than computational work or token staking. In this model, network participants delegate authority to the federation members, who use their reputation and stake to secure the network. (Staking will be implemented at a later stage) The PoA model offers significant advantages for a Bitcoin Layer 2 network. It provides fast finality with immediate transaction confirmation, operates with high energy efficiency through streamlined consensus mechanisms, delivers scalable performance with predictable throughput, and maintains clear accountability through known validator identities. Under this authority structure, each federation member has equal rights to produce blocks in rotation, participates in the multi-signature control of Bitcoin custody requiring 12-of-16 signatures, maintains equal voice in protocol governance, and shares responsibility for overall network health and security. ### Roles and Responsibilities #### Bitcoin Custody Federation members collectively control the Bitcoin held in custody through a 12-of-16 multi-signature scheme. Each member maintains a secure private key share and participates in the creation of Bitcoin transactions when users request withdrawals. This distributed custody model ensures that no single entity can unilaterally access the Bitcoin reserves while providing sufficient redundancy to handle member unavailability. Members must maintain enterprise-grade security standards for key storage, participate in regular key ceremonies and audits, and follow strict operational procedures for transaction signing. The 12-of-16 threshold means that even if up to 4 members are compromised or unavailable, the network can continue to operate securely. #### Block Production Federation members take turns producing blocks according to the consensus mechanism, validating transactions and maintaining network state. Each member runs full node infrastructure with high availability requirements and participates in the consensus process to ensure all members agree on the canonical chain state. Block production responsibilities include creating new blocks with valid transactions, maintaining synchronization with other federation members, monitoring network performance and health, and ensuring optimal transaction throughput for users. #### Bridge Operations The federation collectively manages the bridging process between Bitcoin and Botanix. When users deposit Bitcoin, federation members verify the Bitcoin transactions and authorize the minting of equivalent tokens on Botanix. For withdrawals, members coordinate to create and sign Bitcoin transactions that release funds to users. This process requires careful verification of cryptographic proofs, accurate accounting between Bitcoin and Botanix balances, and coordination among members to ensure timely processing of user requests while maintaining security standards. [^1]: # Consensus Mechanism - CometBFT {% hint style="info" %} **Technical deepdive** Do you want to learn more about CometBFT? Visit their [official documentation](https://docs.cometbft.com/v1.0/)! {% endhint %} Botanix uses CometBFT as its consensus mechanism to achieve fast finality, high throughput, and strong consistency guarantees. This chapter explains what CometBFT is, why it was chosen over alternatives like Ethereum's Casper, and how it integrates with the Botanix Federation to provide superior user experience and security properties. ### What is CometBFT? [CometBFT](https://docs.cometbft.com/) is a Byzantine Fault Tolerant consensus engine that provides the networking and consensus layers for blockchain applications. Originally developed as [Tendermint Core](https://arxiv.org/abs/1807.04938), CometBFT separates the consensus mechanism from the application logic, allowing developers to build secure, consistent, and high-performance blockchain networks. The protocol operates through a round-based voting process where validators propose blocks and vote on their validity. This approach ensures that all honest participants agree on the same sequence of transactions, even in the presence of malicious or faulty nodes. CometBFT provides immediate finality, meaning that once a block is committed, it cannot be reverted or reorganized. This property is crucial for Bitcoin Layer 2 applications where users expect fast, irreversible transactions. ### Why CometBFT Over Ethereum's Casper? #### Immediate Finality vs Probabilistic Finality Ethereum's Casper FFG provides probabilistic finality, where the certainty of a transaction increases over time as more blocks are added on top. Users must wait for multiple confirmations to be confident their transactions won't be reversed due to chain reorganizations. CometBFT provides immediate finality through its consensus process. Once a block receives more than two-thirds of validator votes, it becomes final and cannot be reverted. This means users can trust their transactions immediately without waiting for additional confirmations. #### No Chain Reorganizations Ethereum's consensus mechanism allows for chain reorganizations where previously confirmed blocks can be replaced by alternative chains. While rare, these reorganizations can cause significant disruption for users and applications, especially those dealing with high-value transactions. CometBFT's architecture makes chain reorganizations impossible. The consensus process ensures that all validators agree on each block before proceeding to the next one, creating a linear chain that cannot be reorganized once blocks are finalized. #### Performance and Predictability Ethereum's current consensus mechanism can experience variable block times and unpredictable finality delays during periods of network stress or validator issues. This variability makes it difficult for applications to provide consistent user experiences. CometBFT provides predictable performance with consistent block times and reliable finality. The federation-based validator set ensures stable network operation without the performance variability seen in larger, more diverse validator sets. ### Byzantine Fault Tolerance Properties #### Security Guarantees CometBFT provides strong security guarantees as long as fewer than one-third of validators are Byzantine (malicious or faulty). With Botanix's 16-member federation, the network can tolerate up to 5 Byzantine members while maintaining security and liveness. The protocol guarantees safety, meaning that no two honest validators will ever commit conflicting blocks at the same height. It also guarantees liveness, ensuring that the network will continue to make progress and commit new blocks as long as more than two-thirds of validators are honest and available. #### Consensus Process The CometBFT consensus process operates in rounds, with each round consisting of several phases. A designated proposer creates a new block containing transactions from the mempool. All validators then vote on the proposed block in a prevote phase, followed by a precommit phase where validators commit to the block if it received sufficient prevotes. If more than two-thirds of validators precommit to the same block, it becomes finalized and is added to the blockchain. If consensus is not reached in a round, the protocol moves to the next round with a different proposer, ensuring the network maintains liveness even if some validators are unresponsive. #### Network Resilience The consensus mechanism is designed to handle various network conditions and validator behaviors. It can tolerate network partitions, temporary validator outages, and even attempts by malicious validators to disrupt the consensus process. The protocol includes timeouts and round progression mechanisms that ensure the network continues operating even when some validators are slow to respond or attempting to delay consensus. This resilience is crucial for maintaining consistent service quality for Botanix users. ### Integration with Botanix Federation #### Validator Set Management In Botanix, the 16 federation members serve as CometBFT validators, each running consensus nodes that participate in the block production and validation process. The federation's Proof of Authority model aligns perfectly with CometBFT's requirements for a known, trusted validator set. Each federation member operates validator infrastructure with high availability requirements, ensuring the network maintains strong uptime and performance. The fixed validator set eliminates the complexity and potential instability associated with dynamic validator sets in other consensus mechanisms. #### Block Production Process Federation members take turns proposing new blocks according to CometBFT's round-robin proposer selection algorithm. The designated proposer for each round collects transactions from the network mempool, creates a new block, and broadcasts it to other validators for consensus. All validators verify the proposed block, checking transaction validity, state transitions, and adherence to protocol rules. They then participate in the voting process to either accept or reject the block. This collaborative validation ensures that only valid blocks are added to the chain. #### Threshold Requirements CometBFT requires more than two-thirds of validators to agree for consensus, which translates to at least 11 out of 16 federation members for Botanix. This threshold provides strong security while maintaining operational efficiency, as the network can continue operating even if up to 5 members are temporarily unavailable. The two-thirds threshold aligns well with the federation's multi-signature requirements for Bitcoin custody, creating consistency across different aspects of the protocol's security model. ### Performance Characteristics #### Block Time and Throughput CometBFT enables Botanix to achieve consistent block times of approximately 5-6 seconds, providing users with fast transaction confirmation. This predictable timing allows applications to provide better user experiences compared to networks with variable block times. The consensus mechanism can handle thousands of transactions per second, limited primarily by the application logic rather than the consensus layer. This throughput capacity ensures Botanix can scale to meet growing demand while maintaining performance. #### Finality Speed Unlike proof-of-work systems where finality is probabilistic and requires multiple confirmations, CometBFT provides finality within a single block time. Users can be confident their transactions are irreversible as soon as they appear in a committed block. This immediate finality is particularly valuable for Bitcoin Layer 2 applications, where users expect the fast settlement that comes with off-chain scaling solutions while maintaining the security of the underlying Bitcoin network. #### Network Efficiency The consensus mechanism operates efficiently with minimal computational overhead compared to proof-of-work systems. Validators focus their resources on transaction validation and state management rather than energy-intensive mining operations. This efficiency translates to lower operational costs for federation members and reduced environmental impact for the network as a whole, while still maintaining strong security properties through the cryptographic and economic incentives of the federation model. ### Advantages for Bitcoin Layer 2 #### Bridging Benefits The immediate finality provided by CometBFT significantly improves the user experience for Bitcoin bridging operations. Users can see their peg-in transactions confirmed quickly on the Botanix side after the necessary amount of confirmations on the Bitcoin chain have been reached. For peg-out operations, the deterministic finality ensures that once a withdrawal is processed and confirmed on Botanix, users can be confident the corresponding Bitcoin transaction will be created and broadcast without risk of reversion. #### Smart Contract Execution The consistent block times and immediate finality make Botanix ideal for complex smart contract applications that require predictable execution timing. Developers can build applications with confidence in transaction ordering and finality guarantees. The absence of chain reorganizations eliminates a significant source of complexity for smart contract developers, who no longer need to account for the possibility that their transactions might be reversed due to chain restructuring. #### User Experience Users benefit from fast, predictable transaction confirmation times and the confidence that their transactions are immediately final. This creates a user experience that combines the best aspects of centralized systems (speed and finality) with the security and decentralization benefits of blockchain technology. The consistent performance also enables better integration with traditional financial systems and applications that require predictable settlement times and strong finality guarantees. ### Security Considerations #### Trust Model CometBFT's security relies on the assumption that fewer than one-third of validators are Byzantine. In Botanix's case, this means trusting that at least 11 of the 16 federation members will act honestly and maintain proper operational security. This trust model aligns with the broader federation approach, where security is derived from the reputation and economic incentives of known, trusted entities rather than anonymous participants or computational work. #### Attack Resistance The consensus mechanism provides strong resistance to various attack vectors, including double-spending attempts, denial-of-service attacks, and attempts to create conflicting transaction histories. The combination of cryptographic proofs and economic incentives makes successful attacks extremely difficult and expensive. The fixed validator set also eliminates certain attack vectors present in dynamic consensus systems, such as validator replacement attacks or stake grinding, while the federation's reputation-based security model provides additional deterrents against malicious behavior. *** *CometBFT provides Botanix with a robust, efficient, and user-friendly consensus mechanism that delivers the performance and security properties required for a successful Bitcoin Layer 2 network. The integration with the federation model creates a coherent security architecture that prioritizes user experience while maintaining strong decentralization and security guarantees.* # Bridging - Peg-in / Peg-out {% hint style="info" %} **Bridge User Manual** Looking for information on how to use the Bridge? Visit the [Bridge documentation](https://docs.botanixlabs.com/bridge/getting-started/prerequisites)! {% endhint %} Botanix enables seamless movement of Bitcoin between the Bitcoin mainchain and the Botanix Layer 2 through a secure bridging mechanism. This chapter explains how users can deposit Bitcoin to receive tokens on Botanix (peg-in) and withdraw their tokens back to Bitcoin (peg-out), along with the security measures and federation processes that make this possible. ### Overview of Botanix Bridging The Botanix bridge maintains a 1:1 peg between Bitcoin on the mainchain and tokens on the Layer 2 network. When users deposit Bitcoin, an equivalent amount of tokens is minted on Botanix. When they withdraw, the tokens are burned on Botanix and the corresponding Bitcoin is released from the federation's multi-signature wallet. This bidirectional bridge is secured by the 16-member federation through a 12-of-16 multi-signature scheme, ensuring that no single entity can unilaterally access user funds while providing sufficient redundancy for reliable operations. The bridge maintains strict accounting to ensure the total supply of Botanix tokens never exceeds the Bitcoin held in custody. ### Peg-in Process: Bitcoin to Botanix #### User Initiates Deposit The peg-in process begins when a user wants to move Bitcoin to Botanix. The user connects their EVM wallet to the Botanix bridge interface, which generates a unique Bitcoin deposit address derived from their EVM wallet address. The user then sends Bitcoin to this personalized deposit address, eliminating the need for additional metadata or complex transaction formatting. This deposit address derivation system creates a direct mapping between the user's EVM wallet and their Bitcoin deposit address, ensuring that deposits are automatically attributed to the correct Botanix address. #### Bitcoin Network Confirmation Once the user broadcasts their Bitcoin transaction to their derived deposit address, it enters the Bitcoin mempool and awaits confirmation by Bitcoin miners. The federation monitors the Bitcoin network for incoming transactions to all derived deposit addresses, automatically detecting deposits and associating them with the correct user accounts based on the address derivation system. The federation waits for 18 Bitcoin confirmations to ensure the deposit transaction is sufficiently secure against potential reorganizations. This waiting period provides strong confidence in transaction finality and represents approximately 3 hours under normal Bitcoin network conditions. #### Federation Verification After the required Bitcoin confirmations, federation members begin the verification process. Each member independently verifies that the Bitcoin transaction is valid, sent to a properly derived deposit address, and meets all technical requirements. The verification process includes checking the transaction's inclusion in the Bitcoin blockchain through cryptographic proofs, validating the transaction structure and signatures, and ensuring the deposit address derivation is mathematically correct. This comprehensive verification protects against various attack vectors and ensures only legitimate deposits are processed. #### Proof Generation and Validation Federation members verify cryptographic proofs demonstrating that a valid Bitcoin deposit has occurred to a properly derived address. These proofs include merkle tree proofs showing the transaction's inclusion in a Bitcoin block, along with the address derivation proof that links the deposit to the intended Botanix recipient. The proof generation process involves creating a complete audit trail from the Bitcoin transaction to the intended Botanix mint operation. This includes block header information, merkle proofs, transaction details, and cryptographic verification of the address derivation to ensure accurate processing of the user's deposit. The proof is generated by the entity that is submitting the mint transaction, in our case Sidecar. #### Token Minting on Botanix The minting process begins when the user "claims" the funds on Botanix. During the claim process, Sidecar (and in the future, anyone using an SDK) creates the cryptographic proof and includes it in the peg-in transaction, then broadcasts this transaction to the federation. The federation members validate both the proof and the mint transaction simultaneously, and upon successful validation, authorize the creation of new tokens equivalent to the deposited Bitcoin amount on the Botanix minting contract. The minting contract performs additional validation checks to prevent double-spending, ensures the proofs are properly formatted and verified, and maintains accurate accounting of the total token supply. Upon successful validation, new tokens are minted to the user's specified Botanix address, completing the peg-in process. #### Transaction Cost Handling The minting process includes mechanisms for handling transaction costs associated with processing the deposit. The system calculates the gas costs required for the minting operation and deducts these costs from the deposited amount, ensuring that users receive the net amount after accounting for processing fees. A portion of the transaction costs is allocated to a refund address (typically controlled by the entity facilitating the deposit) to incentivize bridge operation and maintenance. This cost structure ensures sustainable operation while minimizing fees for users. ### Peg-out Process: Botanix to Bitcoin #### Withdrawal Request The peg-out process begins when a user wants to withdraw tokens from Botanix back to Bitcoin. The user calls the burn function on the minting contract, specifying the amount to withdraw and providing their Bitcoin destination address along with any additional metadata required for the withdrawal. The burn operation immediately removes the specified tokens from circulation on Botanix, reducing the total token supply to maintain the 1:1 peg with Bitcoin held in custody. The burn transaction also creates a withdrawal request that enters the federation's processing queue. #### Federation Processing Queue Federation members monitor the Botanix network for burn events and maintain a shared queue of pending withdrawal requests. Each member independently validates the burn transactions, confirms the legitimacy of the withdrawal requests, and prepares for the collective signing process required to release Bitcoin. The processing queue operates on an epoch-based system. Epoch blocks are created every 10 Botanix blocks (roughly once a minute). #### Bitcoin Transaction Creation When processing withdrawals, federation members collaborate to create Bitcoin transactions that release funds to users' specified addresses. This process involves selecting appropriate UTXOs from the federation's Bitcoin holdings, calculating transaction fees, and creating outputs that match the withdrawal requests. The transaction creation process must account for Bitcoin's UTXO model, ensuring efficient use of available UTXOs while minimizing transaction fees. Federation members also coordinate to include multiple withdrawal requests in single transactions when possible, reducing overall costs and improving efficiency. #### FROST Signature Generation The federation uses [FROST](/botanix/get-to-know-botanix/advanced/frost) (Flexible Round-Optimized Schnorr Threshold signatures) to collectively sign Bitcoin transactions without requiring all members to be online simultaneously. This threshold signature scheme allows any 12 of the 16 federation members to create valid signatures for Bitcoin transactions. The FROST signing process involves multiple rounds of communication between federation members, where they share partial signatures and combine them into complete transaction signatures. This approach provides security through distribution while maintaining operational flexibility for handling member availability. #### Bitcoin Network Broadcasting Once the Bitcoin transaction is fully signed by at least 12 federation members, it is broadcast to the Bitcoin network for confirmation. The transaction releases the appropriate amount of Bitcoin to users' specified addresses, completing the withdrawal process. Federation members monitor the Bitcoin network to confirm successful broadcast and track the transaction's confirmation status. Users can track their withdrawal transactions using standard Bitcoin block explorers and wallet software. #### Finality and Confirmation The peg-out process is considered complete once the Bitcoin transaction receives sufficient confirmations on the Bitcoin network. Users receive their Bitcoin at the specified addresses and can use it freely on the Bitcoin network or other platforms. The federation maintains records of all completed withdrawals for auditing and reconciliation purposes, ensuring accurate accounting and enabling detection of any discrepancies in the bridging process. ### Security Measures and Safeguards #### Multi-signature Security The 12-of-16 multi-signature requirement ensures that no small group of federation members can unilaterally access user funds. Even if several members are compromised or become unavailable, the bridge continues operating securely with the remaining honest members. This threshold provides an optimal balance between security and operational efficiency, requiring sufficient consensus for legitimate operations while maintaining resilience against various failure modes and attack vectors. #### Proof Validation The bridge implements comprehensive cryptographic proof validation to prevent invalid deposits from being processed. All proofs must demonstrate valid Bitcoin transactions with proper confirmation depth and correct metadata formatting. The validation process includes multiple independent checks by different federation members, ensuring that consensus is required not only for signing transactions but also for validating the legitimacy of bridge operations. #### Supply Integrity The bridge maintains strict accounting to ensure the total supply of tokens on Botanix never exceeds the Bitcoin held in custody. This 1:1 backing provides users with confidence that their tokens are fully collateralized by actual Bitcoin. Regular audits and reconciliation processes verify the integrity of the supply relationship, with transparent reporting of Bitcoin holdings and token supply to enable community verification of the bridge's solvency. #### Replay Protection The system implements robust replay protection to prevent the same Bitcoin deposit from being processed multiple times. This includes tracking processed transactions, maintaining comprehensive records of completed operations, and implementing technical measures to detect and prevent duplicate processing. The replay protection extends across different aspects of the bridge operation, ensuring that both peg-in and peg-out operations are processed exactly once and cannot be manipulated or duplicated by malicious actors. ### Operational Considerations #### Processing Times Peg-in operations require 18 Bitcoin confirmations (approximately 3 hours) plus additional processing time for federation verification and proof generation. The total time from Bitcoin transaction broadcast to availability on Botanix is generally 3-4 hours under normal conditions. Peg-out operations are processed in batches on every epoch block, which occurs every 10 Botanix blocks (roughly once every minute). Users can expect their withdrawal requests to be processed in the next epoch block after their burn transaction is confirmed. This means that a typical withdrawal takes about 1 minute plus the time it takes to be included in an L1 block. #### Minimum Amounts and Fees The bridge enforces minimum withdrawal amounts to ensure economic viability and prevent dust attacks. These minimums are set to cover transaction costs while remaining accessible to typical users. Transaction fees for bridge operations are dynamically calculated based on current Bitcoin network conditions and operational costs. The fee structure is designed to ensure sustainable bridge operation while minimizing costs for users. #### Monitoring and Support Federation members continuously monitor bridge operations to ensure reliable service and quick resolution of any operational issues. This includes monitoring Bitcoin and Botanix networks, tracking transaction processing times, and maintaining system health metrics. Users can monitor their bridge transactions through standard block explorers and dedicated bridge monitoring tools that provide real-time status updates for peg-in and peg-out operations. *** *The Botanix bridge provides secure, reliable transfer of Bitcoin between the mainchain and Layer 2, enabling users to access fast, low-cost transactions while maintaining the security and value backing of their Bitcoin holdings.* # DKG and FROST Botanix uses advanced cryptographic techniques to secure Bitcoin custody without any single entity controlling user funds. This chapter provides an accessible introduction to Distributed Key Generation (DKG) and FROST signatures, explaining how these technologies enable the federation to collectively manage Bitcoin while maintaining security and operational efficiency. {% hint style="info" %} Technical Deep Dive For readers interested in the specifics of these technologies, comprehensive technical documentation is available in the Advanced Concepts section: * [DKG Technical Details ](/botanix/get-to-know-botanix/advanced/distributed-key-generation-dkg) * [FROST Specification ](/botanix/get-to-know-botanix/advanced/frost) {% endhint %} ### What is Distributed Key Generation (DKG)? Distributed Key Generation is a cryptographic process that allows multiple parties to collectively create a shared secret without any individual party ever knowing the complete secret. In Botanix's case, the 16 federation members use DKG to create the private keys needed to control Bitcoin without any single member having access to the full key. Think of it like creating a master key that's split into 16 pieces, where any 12 pieces can be combined to unlock Bitcoin funds, but fewer than 12 pieces are completely useless. The crucial aspect is that no single member ever possesses the complete master key during the creation process. This approach eliminates the trust issues that would arise if one entity generated the keys and distributed shares to others. Instead, the mathematical process ensures that the key generation is inherently distributed from the very beginning. ### What is FROST? FROST (Flexible Round-Optimized Schnorr Threshold signatures) is the signature scheme that allows the federation to spend Bitcoin using their distributed key shares. When the federation needs to sign a Bitcoin transaction, they use FROST to combine their individual key shares into a valid signature without ever reconstructing the complete private key. The "threshold" aspect means that only 12 of the 16 federation members need to participate in creating each signature. This provides operational flexibility since not all members need to be online simultaneously, while maintaining security since no small group can create unauthorized signatures. FROST is optimized for efficiency, requiring fewer communication rounds between federation members compared to older threshold signature schemes. This makes it practical for real-world operations where network latency and coordination overhead matter. ### How They Work Together in Botanix #### Initial Setup When the Botanix federation was established, all 16 members participated in a DKG ceremony to create the Bitcoin custody keys. During this process, each member contributed randomness and performed cryptographic computations that resulted in everyone holding a unique key share. The DKG ceremony ensures that the resulting Bitcoin addresses are controlled by the collective federation with a 12-of-16 threshold, meaning any 12 members can authorize Bitcoin transactions, but 11 or fewer cannot. #### Daily Operations For routine operations like processing user withdrawals, the federation uses FROST signatures. When users request peg-outs, at least 12 federation members must participate in the signing process to create valid Bitcoin transactions. The FROST process involves multiple rounds of communication where members share partial signatures that are mathematically combined into complete transaction signatures. This happens without any member revealing their private key share or reconstructing the complete private key. #### Security Benefits This combination provides several important security properties. No single federation member can steal user funds since they don't have access to complete private keys. The system remains operational even if several members are offline or compromised, as long as at least 12 honest members remain available. The cryptographic protocols ensure that even if attackers compromise some federation members, they cannot access Bitcoin funds without compromising at least 12 members simultaneously, which would require an unprecedented coordinated attack. ### Practical Advantages #### Operational Resilience The threshold structure means that federation members can perform maintenance, handle emergencies, or deal with technical issues without disrupting Bitcoin custody operations. As long as 12 members remain available, the system continues functioning normally. This resilience is crucial for a system that must operate 24/7 to serve users across global time zones and handle time-sensitive withdrawal requests. #### No Single Points of Failure Traditional multi-signature setups often involve trusted setup ceremonies or key dealers who have special privileges during key generation. DKG eliminates these trusted parties, ensuring that no entity has special access or control over the system. Even the federation members themselves cannot individually compromise the system, as each member only holds a mathematically useless fragment of the complete key. # Block Production and Validation Botanix's block production and validation process combines the federation's authority model with CometBFT consensus to create a fast, secure, and predictable blockchain. This chapter explains how federation members collaborate to produce blocks, validate transactions, and maintain network consensus. ### Block Production Overview Block production in Botanix follows a structured process where federation members take turns creating new blocks containing user transactions. Unlike proof-of-work systems where miners compete to solve puzzles, or proof-of-stake systems where validators are randomly selected, Botanix uses a deterministic rotation among the 16 federation members. Each block contains regular EVM transactions from users, bridge operations (peg-ins and peg-outs), and special epoch blocks that synchronize with Bitcoin blocks for withdrawal processing. The system maintains consistent block times while ensuring all transactions are properly validated before inclusion. ### Federation Block Proposers #### Proposer Selection CometBFT uses a round-robin algorithm to select which federation member will propose the next block. This deterministic selection ensures fair participation while preventing any single member from dominating block production. The proposer selection rotates through all 16 federation members, giving each member equal opportunity to produce blocks. If the designated proposer is offline or fails to create a valid block within the timeout period, CometBFT automatically moves to the next member in the rotation. This failover mechanism ensures continuous block production even when individual federation members experience technical issues. #### Block Creation Process When selected as the proposer, a federation member collects pending transactions from the network mempool, validates each transaction according to EVM rules, and packages them into a new block. The proposer must ensure that all transactions are valid, properly formatted, and don't conflict with the current network state. The proposer also includes any pending bridge operations that have met their confirmation requirements, special epoch markers when synchronized with Bitcoin blocks, and updates to network state based on the included transactions. All of this information is packaged into a properly formatted block proposal. ### Transaction Validation #### EVM Compatibility Botanix maintains full EVM compatibility, meaning all transaction validation follows standard Ethereum rules. This includes verifying digital signatures, checking account balances and nonces, validating smart contract calls, and ensuring gas limits are respected. Users can interact with Botanix using standard Ethereum tools and expect identical behavior. The validation process ensures that all state transitions are correct and that the resulting network state is consistent across all federation members. This compatibility allows existing Ethereum applications and tools to work seamlessly on Botanix. #### Bridge Transaction Validation Bridge transactions require additional validation beyond standard EVM checks. For peg-in transactions, the system must verify cryptographic proofs of Bitcoin deposits, confirm that deposit addresses are properly derived, and ensure that no double-spending occurs. The validation also checks that the deposited Bitcoin amount matches the tokens being minted. Peg-out transactions involve verifying that tokens are properly burned and that withdrawal requests are correctly formatted with valid Bitcoin destination addresses. The system maintains strict accounting to ensure the total token supply never exceeds the Bitcoin held in custody. ### Consensus Process #### CometBFT Integration Once a federation member creates a block proposal, it's broadcast to all other federation members for consensus. The CometBFT consensus process requires at least 11 of the 16 federation members to agree on the block before it becomes final. The consensus process involves multiple rounds of voting where federation members signal their acceptance or rejection of the proposed block. If the block receives sufficient votes, it becomes finalized and is added to the blockchain. If not, the process moves to the next proposer in rotation. #### Validation by All Members Every federation member independently validates each proposed block, checking all transactions, verifying state transitions, and ensuring compliance with protocol rules. This distributed validation ensures that no invalid transactions are included and that all members maintain consistent network state. The validation process includes checking that bridge operations have proper authorization, all EVM transactions follow standard rules, block formatting is correct, and the proposed state changes are valid. Only when these checks pass do members vote to accept the block. #### Finality and Confirmation Once a block receives more than two-thirds of federation votes (at least 11 of 16), it becomes immediately final and cannot be reversed. This provides users with instant confirmation that their transactions are permanently settled, unlike systems that require multiple confirmations for security. The immediate finality eliminates the possibility of chain reorganizations, providing users and applications with certainty about transaction status as soon as blocks are confirmed. ### Epoch Blocks and Bitcoin Synchronization #### Epoch Block Creation Every 10 Botanix blocks, roughly every minute, the network creates special epoch blocks that synchronize Layer 2 operations with Bitcoin. These epoch blocks trigger batch processing of pending peg-out requests and update the network's Bitcoin state information. Epoch blocks contain the same types of transactions as regular blocks but include additional metadata about Bitcoin network state and trigger special processing routines for bridge operations. The timing aligns with Bitcoin blocks to ensure efficient coordination between networks. #### Peg-out Processing When an epoch block is created, the federation processes all pending peg-out requests that have been confirmed since the previous epoch. This batch processing approach optimizes Bitcoin transaction fees and ensures predictable withdrawal processing times for users. The epoch-based processing means users can expect their withdrawal requests to be handled within approximately 10 minutes of submission, providing predictable service levels while maintaining operational efficiency. ### Performance and Monitoring #### Block Time Consistency The federation maintains consistent block times of approximately 5-6 seconds under normal conditions. This predictability enables applications to provide better user experiences and allows for more accurate transaction time estimates. Performance monitoring tracks block production times, consensus completion speed, and transaction processing throughput to ensure the network meets performance targets and to identify potential optimization opportunities. #### Network Health Monitoring Federation members continuously monitor network health metrics including block production success rates, consensus participation levels, transaction processing times, and system resource usage. This monitoring enables proactive identification and resolution of potential issues. Health monitoring also tracks individual federation member performance to ensure all participants meet operational standards and contribute effectively to network security and performance. *** *Block production and validation in Botanix combines the efficiency of authority-based consensus with the security of distributed validation, creating a fast and reliable blockchain that serves as an effective Bitcoin Layer 2 solution.* # Security Model {% hint style="info" %} **On the Road to Full Decentralization** The Founding Federation represents a critical phase in the network's journey toward full decentralization, providing professional-grade security and operational excellence while building toward the ultimate vision of permissionless Bitcoin programmability. {% endhint %} Botanix's current security model is built on multiple layers of protection that work together to secure user funds and maintain network integrity. This chapter outlines the core security assumptions, trust requirements, and protective mechanisms that make Botanix a secure Bitcoin Layer 2 solution. ### Core Security Architecture #### Multi-layered Protection Botanix security operates through several interconnected layers. The foundation is the federation's reputation-based security, where [16 trusted entities](/botanix/get-to-know-botanix/roadmap-to-spiderchain/founding-federation/federation-overview) stake their reputation and economic interests on honest behavior. Above this sits the cryptographic layer using [threshold signatures](/botanix/get-to-know-botanix/advanced/frost) and [distributed key generation](/botanix/get-to-know-botanix/advanced/distributed-key-generation-dkg), ensuring no single entity can compromise user funds. The protocol layer implements consensus through [CometBFT](/botanix/get-to-know-botanix/roadmap-to-spiderchain/founding-federation/consensus-mechanism-cometbft) with Byzantine fault tolerance, while the application layer includes smart contract security measures and comprehensive input validation. Finally, the Bitcoin layer provides ultimate settlement security through the world's most secure blockchain. #### Trust Assumptions The Botanix security model requires that fewer than one-third of federation members act maliciously. With 16 federation members, the network can tolerate up to 5 Byzantine actors while maintaining security and liveness. This assumption is reinforced by the economic and reputational incentives of federation members who have significant stake in the network's success. Users must also trust that the federation will not collude to steal funds, though the 12-of-16 threshold makes such collusion extremely difficult and economically irrational for established ecosystem participants. ### Federation Security #### Economic Incentives Federation members have strong economic incentives to act honestly. Each member has invested significantly in infrastructure, reputation, and long-term commitments to the Bitcoin ecosystem. Malicious behavior would result in immediate detection, loss of business relationships, and destruction of their reputation in the broader cryptocurrency community. The federation model creates aligned incentives where members benefit from network growth and user adoption, making the long-term value of honest participation far greater than any short-term gains from malicious behavior. #### Operational Security Each federation member maintains enterprise-grade security practices including secure key storage, multi-factor authentication, segregated network access, and comprehensive monitoring systems. Members undergo regular security audits and must demonstrate adherence to established security standards. The distributed nature of the federation means that even if individual members experience security incidents, the overall network security remains intact as long as fewer than 5 members are compromised simultaneously. ### Cryptographic Security #### Threshold Signatures {% hint style="info" %} Learn more about [FROST](/botanix/get-to-know-botanix/advanced/frost) {% endhint %} The 12-of-16 threshold signature scheme ensures that no small group of federation members can unilaterally access user funds. Using FROST (Flexible Round-Optimized Schnorr Threshold signatures), the federation can collectively sign Bitcoin transactions without exposing individual private keys or requiring all members to be online simultaneously. This threshold provides optimal security while maintaining operational flexibility, allowing the network to continue functioning even when several members are temporarily unavailable due to maintenance, network issues, or other operational considerations. #### Distributed Key Generation {% hint style="info" %} Learn more about [DKG](/botanix/get-to-know-botanix/advanced/distributed-key-generation-dkg) {% endhint %} The federation's Bitcoin custody keys are generated through a distributed key generation ceremony where no single entity ever possesses the complete private key. This process ensures that the multi-signature wallet controlling user funds is inherently distributed from inception. Key refresh ceremonies can be performed periodically to maintain security over time, allowing the federation to rotate keys without disrupting user operations or requiring movement of Bitcoin funds. ### Attack Resistance #### Byzantine Fault Tolerance The CometBFT consensus mechanism provides Byzantine fault tolerance, ensuring the network continues operating correctly even when up to 5 federation members behave arbitrarily or maliciously. This includes resistance to various attack scenarios such as double-spending attempts, chain history manipulation, and denial-of-service attacks. The consensus mechanism guarantees that all honest federation members will agree on the same transaction history, preventing conflicting states or transaction reversals that could compromise user funds. #### Bridge Security The bridging mechanism implements multiple layers of validation to prevent unauthorized minting or burning of tokens. Each peg-in requires cryptographic proof of valid Bitcoin deposits with sufficient confirmations, while peg-outs require proper token burning and federation consensus for Bitcoin release. Comprehensive replay protection prevents the same Bitcoin deposit from being processed multiple times, while strict accounting ensures the total token supply never exceeds the Bitcoin held in custody. #### Network Security The network implements robust protections against various attack vectors including transaction flooding, state manipulation, and consensus disruption. Rate limiting, gas mechanisms, and validation procedures ensure that malicious actors cannot overwhelm the network or compromise its operation. The fixed validator set eliminates certain attack vectors present in permissionless networks, such as stake grinding or validator replacement attacks, while the federation's known identities enable accountability and dispute resolution. ### Risk Mitigation #### Operational Risks The federation model mitigates operational risks through geographic distribution, diverse operational practices, and redundant infrastructure. Members operate in different jurisdictions with varying regulatory environments, reducing the impact of localized regulatory changes or infrastructure disruptions. Regular communication and coordination protocols ensure that temporary unavailability of individual members does not impact network operations, while emergency procedures enable rapid response to significant operational challenges. #### Technical Risks Smart contract risks are mitigated through comprehensive security audits, formal verification where applicable, and conservative design practices that prioritize security over feature complexity. The protocol includes circuit breakers and emergency procedures that can halt operations if critical vulnerabilities are discovered. Regular security assessments and bug bounty programs help identify and address potential vulnerabilities before they can be exploited, while the federation's technical expertise ensures rapid response to emerging threats. #### Economic Risks The 1:1 peg between Bitcoin and Botanix tokens eliminates many economic risks present in other bridging solutions. Users' funds are fully backed by actual Bitcoin rather than synthetic assets or algorithmic mechanisms that could fail under market stress. The federation's economic alignment ensures that members have strong incentives to maintain the peg and protect user funds, as any loss of confidence would directly impact their own economic interests and business operations. ### Emergency Procedures #### Incident Response The federation maintains comprehensive incident response procedures for various scenarios including security breaches, operational failures, and external attacks. These procedures include rapid communication protocols, emergency decision-making processes, and technical response capabilities. In extreme scenarios, the federation can halt bridge operations to prevent further damage while investigating and resolving security incidents. This temporary halt protects user funds while maintaining the ability to resume normal operations once threats are addressed. #### Recovery Mechanisms The distributed nature of the federation's key management enables recovery from various failure scenarios. Even if several federation members lose access to their key shares, the remaining members can continue operations and potentially initiate key refresh procedures to restore full operational capacity. Bitcoin custody remains secure even during recovery procedures, as the threshold signature requirements ensure that user funds cannot be accessed without sufficient federation consensus throughout any recovery process. # Federation with Staking {% hint style="info" %} More information coming soon as we continue our development. {% endhint %} # Dynamic Federation {% hint style="info" %} More information coming soon as we continue our development. {% endhint %} # Federation with Staking & Slashing {% hint style="info" %} More information coming soon as we continue our development. {% endhint %} # Permissionless staking {% hint style="info" %} More information coming soon as we continue our development. {% endhint %} # Fully Decentralized Layer 2 {% hint style="info" %} More information coming soon as we continue our development. {% endhint %} # Introduction {% hint style="info" %} **Under construction** This document is currently in draft and will be continuously updated as feedback is captured from readers like you. In case you have any feedback, it can be given on our [Telegram channel](https://t.me/+sp8J07DEGTxmNjc0) or on [Discord](https://botanixlabs.xyz/en/r/discord). {% endhint %} Building on the Botanix EVM is synonymous with building on Ethereum. Building dApps will not require a translation layer and they are easily portable from Ethereum to Botanix. On the following pages, you will find general information on common tools used for developing dApps on EVM-compatible chains. Next, you will find how you can Build on Botanix. We have gathered information for our three main groups of builders: 1. People who built on Bitcoin before and now want to build on the Botanix EVM - see [Chain Information](/botanix/user-tutorials/chain-information) 2. People who are used to building applications on the EVM and want to start from scratch - see [Develop a new dApp](/botanix/build-applications/build-on-the-botanix-evm/develop-a-new-dapp) 3. People who want to migrate an existing application from another chain to the Botanix EVM - see [Migrate existing dApps](/botanix/build-applications/build-on-the-botanix-evm/migrate-existing-dapps) Happy building! # Chain Information
ParameterValue
Network NameBotanix
Chain ID3637
SymbolBTC
RPC URLhttps://rpc.ankr.com/botanix_mainnet
https://rpc.botanixlabs.com
Explorerhttps://botanixscan.io/
# Important contract addresses
ContractAddress
Bridged USDC (USDC.e)0x29ee6138dd4c9815f46d34a4a1ed48f46758a402
Wrapped ETH (wETH)0x3292c42e8E9Ab3C6a12CFdA556BbCB6f113B1E28
Staked Bitcoin (stBTC) 0xF4586028FFdA7Eca636864F80f8a3f2589E33795
Pegged Bitcoin (pBTC)0x0D2437F93Fed6EA64Ef01cCde385FB1263910C56
Palladium Debt Token (PUSD)0x42725b4D9270CFe24F6852401fdDa88248CB4dE9
OpenUSDT (oUSDT)0x1217bfe6c773eec6cc4a38b5dc45b92292b6e189
Multicall30xcA11bde05977b3631167028862bE2a173976CA11
# Tools On the next few pages, you will find: 1. [Useful links](broken://pages/UUCjCssQujblFuydWCpP) 2. [Development Frameworks](/botanix/build-applications/tools/development-frameworks) 3. [Web3 libraries and tools](/botanix/build-applications/tools/web3-libraries-and-tools) # Block explorers A block explorer is a web-based tool that allows users to view and track transactions, blocks, addresses, and other data on a blockchain. It provides detailed information such as transaction histories, block confirmations, wallet balances, and network activity. Block explorers are commonly used for verifying the status of cryptocurrency transactions, viewing block data, and exploring smart contracts on blockchain networks like Bitcoin or Ethereum. # Routescan {% hint style="info" %} **Botanix Block Explorer** You can find the Botanix Block Explorer at [https://botanixscan.io](https://botanixscan.io/) {% endhint %} Routescan is our official block explorer, providing a reliable and user-friendly way to explore blockchain data. With Routescan, users can easily track transactions, view block confirmations, and access wallet information in real-time. Its intuitive interface allows for seamless navigation of the blockchain, ensuring transparency and security. Whether you're verifying transaction statuses or exploring network activity, Routescan delivers comprehensive insights, making it an essential tool for interacting with our blockchain network. {% hint style="info" %} **Routescan API documentation** To learn more about Routescan, read their documentation: {% endhint %} # Multisig Wallets ### What is a Multisig Wallet? A multisig (multi-signature) wallet is a smart contract that requires multiple signatures to authorize transactions, rather than just one private key like traditional wallets. Think of it like a bank vault that needs multiple keys to open—no single person can access the funds alone. ### How Multisig Works Instead of one person controlling a wallet with a single private key, a multisig wallet distributes control among multiple parties. Common configurations include 2-of-3, 3-of-5 or any other combination that fits your security needs. ### Key Benefits **Enhanced Security**: No single point of failure—if one key is compromised, funds remain safe since multiple signatures are still required. **Shared Control**: Perfect for organizations, DAOs, or groups that need collective decision-making over funds. **Reduced Risk**: Eliminates the "what if I lose my key" problem by distributing responsibility across multiple trusted parties. **Transparency**: All signers can see proposed transactions before signing, ensuring accountability. ### Common Use Cases on EVM Chains * **Treasury Management**: DAOs and organizations use multisigs to secure community funds * **Team Wallets**: Startups and companies protect operational funds with executive approval * **Investment Groups**: Multiple investors jointly control pooled assets * **Smart Contract Upgrades**: Protocol teams secure admin functions behind multisig controls * **Escrow Services**: Third-party dispute resolution for complex transactions ### EVM Implementation On EVM-compatible chains, multisig functionality is implemented through smart contracts rather than being built into the protocol layer. Popular implementations include Gnosis Safe or Fireblocks, which provide user-friendly interfaces for creating and managing multisig wallets with features like transaction batching, spending limits, and integration with DeFi protocols. The flexibility of EVM smart contracts allows for sophisticated multisig logic, including time delays, role-based permissions, and integration with other protocols—making them a cornerstone of institutional and organizational crypto adoption. # Gnosis Safe {% hint style="info" %} **Gnosis Safe on Botanix** You can find the Safe wallet on Botanix at or just through {% endhint %} Gnosis Safe (now simply called "Safe") is the most widely adopted multisig wallet solution in the Ethereum ecosystem and EVM-compatible chains. Originally developed by Gnosis, Safe has become the gold standard for securing digital assets through multi-signature technology. ### What Makes Safe Special Safe goes beyond basic multisig functionality by offering a comprehensive smart contract wallet platform. It provides an intuitive web interface that makes complex multisig operations accessible to both technical and non-technical users. The platform supports customizable security policies, transaction batching, and seamless integration with hundreds of DeFi protocols. ### Key Features * **Flexible signature schemes**: Configure any M-of-N setup (2-of-3, 3-of-5, etc.) * **Transaction batching**: Execute multiple operations in a single transaction * **Spending policies**: Set daily limits and automatic approvals for routine transactions * **DeFi integration**: Native support for popular protocols like Uniswap, Aave, and Compound * **Mobile app**: Manage your Safe on-the-go with iOS and Android applications * **Gas optimization**: Advanced transaction bundling reduces overall gas costs ### Industry Adoption Safe secures over $100 billion in digital assets and is trusted by major organizations, DAOs, and protocols throughout the crypto ecosystem. From small teams managing project treasuries to large institutions securing hundreds of millions in assets, Safe has proven its reliability at every scale. ### Learn More For detailed setup guides, API documentation, and advanced configuration options, visit the official Safe documentation at: or visit their website about the Safe Wallet: The Safe team maintains comprehensive resources covering everything from basic wallet creation to advanced smart contract integrations and developer tools. # Fireblocks {% hint style="info" %} **Fireblocks on Botanix** Botanix is a supported network on Fireblocks. {% endhint %} Fireblocks is the leading institutional-grade digital asset infrastructure platform, powering the custody, transfer, and settlement of digital assets for financial institutions, exchanges, and Web3 companies. Since launching in 2019, Fireblocks has transferred more than half a trillion dollars worth in total assets and has become the backbone of institutional crypto operations worldwide. ### What Makes Fireblocks Different Unlike traditional multisig solutions, Fireblocks is built around Multi-Party Computation (MPC) technology. MPC is a cryptographic technology that stores secret information with each party, then solves a problem that requires the unshared, decentralized input of all these parties' secret information. This means the Fireblocks MPC-CMP protocol redefines private key security, never gathering a private key as one whole, eliminating risk. ### Key Advantages Over Traditional Multisig **Protocol Agnostic**: Fireblocks uses MPC over other technologies such as Multisig because MPC is protocol agnostic, operationally flexible, and less costly as signing occurs off-chain. **Cost Efficiency**: MPC-based wallets are represented on the blockchain as a single wallet address, with the actual distributed signature computed outside of the blockchain, significantly reducing gas fees compared to multisig smart contracts. **Operational Flexibility**: MPC allows for ongoing modification and maintenance of the signature scheme, making it easier to scale teams and adapt to changing business needs. ### Enterprise Features * **Policy Engine**: Automated governance policies for transaction rules and admin approvals * **Fireblocks Network**: Institutional asset transfer network that eliminates deposit address risks * **Cold Storage Integration**: MPC-CMP available with cold storage signing for maximum security * **Compliance Tools**: Built-in AML/KYT monitoring and travel rule support * **Multi-Cloud Architecture**: Cryptographic shares distributed across multiple tier-1 cloud environments ### Institutional Trust Fireblocks has nearly doubled its client list, from 60 to over 110 institutional clients, including major banks, asset managers, and fintech companies. Retail-facing businesses like Revolut, BlockFi Trading and Celsius are boosting growth on the crypto custody platform, with some clients reporting hundreds of thousands of new users after integration. ### Developer-Friendly Platform Fireblocks offers comprehensive APIs, SDKs, and developer tools supporting over 100 EVM and non-EVM chains. The platform includes a Developer Sandbox for testing and provides both direct custody and embedded wallet solutions for businesses looking to integrate crypto functionality. ### Learn More For detailed API documentation, security specifications, and integration guides, visit the official Fireblocks developer documentation at: The platform documentation covers everything from basic wallet creation to advanced MPC implementation, compliance features, and enterprise-grade security configurations. # Oracles ### What are Oracles? Oracles are services that connect blockchains to external systems, enabling smart contracts to execute based on inputs and outputs from the real world. Think of them as bridges that allow blockchain applications to interact with off-chain data sources, APIs, and traditional systems that exist outside the blockchain ecosystem. Want to learn more? Check out the [explanation by Cointelegraph](https://cointelegraph.com/learn/what-is-a-blockchain-oracle-and-how-does-it-work) or the [explanation by Chainlink](https://chain.link/education/blockchain-oracles). ### The Oracle Problem Blockchains are intentionally isolated systems—they're designed to be deterministic and consensus-driven. However, this creates a fundamental limitation: smart contracts can only access data that exists on-chain. They cannot directly fetch information from the internet, make API calls, or access external databases. This isolation, while crucial for security and decentralization, limits the functionality of smart contracts. ### How Oracles Work Oracles solve this problem by acting as intermediaries that: 1. **Fetch external data** from various sources (APIs, websites, sensors, databases) 2. **Verify and aggregate** the information to ensure accuracy 3. **Submit the data** to the blockchain in a format smart contracts can understand 4. **Trigger smart contract execution** when specific conditions are met The process is typically automated and happens continuously, ensuring smart contracts have access to up-to-date, reliable external information. ### Types of Data Oracles Provide
TypeExplanation
Price FeedsThe most common use case—providing real-time cryptocurrency and traditional asset prices for DeFi applications like lending protocols, DEXes, and derivatives platforms.
Market DataStock prices, forex rates, commodity prices, and other traditional financial market information for bridging TradFi and DeFi.
Weather InformationTemperature, rainfall, and weather conditions for agricultural insurance, supply chain applications, and weather derivatives.
Sports ResultsGame outcomes, player statistics, and tournament results for prediction markets and sports betting applications.
IoT Sensor DataReal-world sensor readings for supply chain tracking, environmental monitoring, and smart city applications.
Identity VerificationKYC/AML data, credit scores, and identity attestations for compliance and reputation systems.
### Oracle Types by Architecture
TypeExplanation
Centralized OraclesSingle-source oracles that are faster and cheaper but introduce a single point of failure. Suitable for non-critical applications or during development phases.
Decentralized OraclesMultiple independent oracle nodes aggregate data from various sources, providing greater security and reliability through consensus mechanisms.
Hybrid OraclesCombine on-chain and off-chain infrastructure to provide both decentralized data delivery and advanced computation capabilities.
### Critical Role in DeFi Oracles are the backbone of the DeFi ecosystem, enabling: * **Lending Protocols**: Determining collateral values and liquidation thresholds * **Decentralized Exchanges**: Calculating fair prices and preventing arbitrage exploitation * **Derivatives Trading**: Settling contracts based on real-world price movements * **Insurance Products**: Triggering payouts based on external events * **Stablecoins**: Maintaining pegs to fiat currencies or commodities * **Yield Farming**: Calculating returns and rebalancing strategies ### Security Considerations Oracle security is paramount because: * **Data manipulation** can lead to massive financial losses * **Oracle attacks** have resulted in millions of dollars in DeFi exploits * **Centralization risks** can compromise the entire application's decentralization * **Latency issues** can cause outdated data to trigger incorrect contract execution ### Impact on Smart Contract Functionality Oracles transform smart contracts from simple, deterministic programs into dynamic applications that can: * React to real-world events automatically * Make decisions based on external conditions * Integrate with existing business processes * Enable complex financial products and services * Bridge the gap between blockchain and traditional systems Without oracles, smart contracts would be limited to processing only the data that already exists on the blockchain, severely restricting their utility and preventing the development of sophisticated decentralized applications that users expect in modern Web3 ecosystems. Oracles are essential infrastructure that unlock the full potential of smart contracts, enabling them to be truly useful in real-world applications while maintaining the security and decentralization benefits of blockchain technology. # Supra [Supra](https://supra.com) is a novel, high-throughput Oracle & IntraLayer: A vertically integrated toolkit of cross-chain solutions (data oracles, asset bridges, automation network, and more) that interlink all blockchains, public (L1s and L2s) or private (enterprises). Supra provides decentralized oracle price feeds that can be used for on-chain and off-chain use-cases such as spot and perpetual DEXes, lending protocols, and payments protocols. Supra’s oracle chain and consensus algorithm makes it the fastest-to-finality oracle provider, with layer-1 security guarantees. The pull oracle has a sub-second response time. Aside from speed and security, Supra’s rotating node architecture gathers data from 40+ data sources and applies a robust calculation methodology to get the most accurate value. The node provenance on the data dashboard also provides a fully transparent historical audit trail. Supra’s Distributed Oracle Agreement (DORA) paper was accepted into ICDCS 2023, the oldest distributed systems conference. Check out their developer docs [here](https://supra.com/docs/overview/). {% hint style="info" %} **Botanix** Pull Contract: 0x6bf7b21145Cbd7BB0b9916E6eB24EDA8A675D7C0 Storage Contract: 0x6Cd59830AAD978446e6cc7f6cc173aF7656Fb917 {% endhint %} # Chainlink # Indexers ### What are Indexers? Indexers are specialized services that process, organize, and store blockchain data in a structured format that makes it fast and easy to query. Think of them as sophisticated database systems that continuously monitor blockchain networks, extract relevant information from transactions and smart contract events, and organize this data for efficient retrieval by applications. ### The Data Access Problem While blockchains are excellent at storing data immutably and transparently, they're not designed for efficient data retrieval. Accessing specific information from a blockchain presents several challenges: * **Linear data structure**: Blockchains store data chronologically in blocks, making complex queries slow and expensive * **Limited query capabilities**: You can't easily search for specific events, filter by criteria, or aggregate data across multiple transactions * **Performance constraints**: Querying blockchain nodes directly is slow and puts unnecessary load on the network * **Complex data relationships**: Smart contract interactions create complex relationships that are difficult to trace without proper indexing ### How Indexers Work Indexers solve these problems through a systematic process: 1. **Real-time monitoring**: Continuously watch blockchain networks for new blocks and transactions 2. **Data extraction**: Parse transactions, smart contract events, and state changes 3. **Transformation**: Convert raw blockchain data into structured, queryable formats 4. **Storage**: Store processed data in optimized databases (often GraphQL endpoints) 5. **API provision**: Provide fast, flexible APIs for applications to query the indexed data This process transforms slow, complex blockchain queries into fast database lookups. ### Types of Data Indexers Process
TypeExamples
Transaction Data
  • Sender and receiver addresses
  • Transaction amounts and fees
  • Transaction timestamps and block numbers
  • Success/failure status and gas usage
Smart Contract Events
  • Event logs emitted by smart contracts
  • Function calls and their parameters
  • State changes and contract interactions
  • Token transfers and approvals
DeFi Protocol Data
  • Liquidity pool reserves and prices
  • Trading volumes and swap history
  • Lending/borrowing positions
  • Yield farming rewards and staking data
NFT Metadata
  • Token ownership history
  • Marketplace transactions
  • Collection statistics
  • Rarity and trait information
Governance Data
  • Proposal creation and voting
  • Delegation changes
  • Treasury movements
  • Parameter updates
### Critical Importance for Applications #### **Performance Enhancement** Without indexers, applications would need to scan entire blockchains to find relevant data. A simple query like "show me all transactions for this address" could take minutes or hours. With indexers, the same query returns results in milliseconds. #### **Complex Analytics** Indexers enable sophisticated analysis that would be impossible with raw blockchain data: * Historical price charts and trading volume * User behavior analysis across multiple protocols * Portfolio tracking and performance metrics * Risk assessment and liquidation monitoring #### **Real-time Applications** Many DeFi and Web3 applications require real-time data updates: * Trading interfaces showing live prices * Liquidation bots monitoring # Alchemy Subgraphs # The Graph Getting historical data on a smart contract can be frustrating when building a dapp. [The Graph](https://thegraph.com/) provides an easy way to query smart contract data through APIs known as subgraphs. The Graph’s infrastructure relies on a decentralized network of indexers, enabling your dapp to become truly decentralized. ## Quick Start These subgraphs only take a few minutes to set up. To get started, follow these three steps: 1. [Initialize your subgraph project](#id-1.-initialize-your-subgraph-project) 2. [Deploy & Publish](#id-2.-deploy-and-publish) 3. [Query from your dapp](#id-3.-query-your-subgraph) Here’s a step by step walk through: ### 1. Initialize your subgraph project #### Create a subgraph on Subgraph Studio⁠ Go to the [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet. Once your wallet is connected, you can begin by clicking “Create a Subgraph”. When choosing a name, it is recommended to use Title Case: “Subgraph Name Chain Name.” ![Create a Subgraph](https://raw.githubusercontent.com/alinobrasil/the_graph_getting_started/refs/heads/main/img/studio-create-subgraph.png) You will then land on your subgraph’s page. All the CLI commands you need will be visible on the right side of the page: ![CLI commands](https://raw.githubusercontent.com/alinobrasil/the_graph_getting_started/refs/heads/main/img/studio-graphcli-commands.png) #### Install the Graph CLI⁠ On your local machine run the following: ``` npm install -g @graphprotocol/graph-cli ``` #### Initialize your Subgraph⁠ You can copy this directly from your subgraph page to include your specific subgraph slug: ``` graph init --studio ``` You’ll be prompted to provide some info on your subgraph like this: ![cli sample](https://raw.githubusercontent.com/alinobrasil/the_graph_getting_started/refs/heads/main/img/cli-sample.png) Simply have your contract verified on the block explorer and the CLI will automatically obtain the ABI and set up your subgraph. The default settings will generate an entity for each event. ### 2. Deploy & Publish #### Deploy to Subgraph Studio⁠ First run these commands: ```bash $ graph codegen $ graph build ``` Then run these to authenticate and deploy your subgraph. You can copy these commands directly from your subgraph’s page in Studio to include your specific deploy key and subgraph slug: ```bash $ graph auth --studio $ graph deploy --studio ``` You will be asked for a version label. You can enter something like v0.0.1, but you’re free to choose the format. #### Test your subgraph⁠ You can test your subgraph by making a sample query in the playground section. The Details tab will show you an API endpoint. You can use that endpoint to test from your dapp. ![Playground](https://raw.githubusercontent.com/alinobrasil/the_graph_getting_started/refs/heads/main/img/studio-playground.png) #### Publish Your Subgraph to The Graph’s Decentralized Network Once your subgraph is ready to be put into production, you can publish it to the decentralized network. On your subgraph’s page in Subgraph Studio, click on the Publish button: ![publish button](https://raw.githubusercontent.com/alinobrasil/the_graph_getting_started/refs/heads/main/img/studio-publish-button.webp) Before you can query your subgraph, Indexers need to begin serving queries on it. In order to streamline this process, you can curate your own subgraph using GRT. When publishing, you’ll see the option to curate your subgraph. As of May 2024, it is recommended that you curate your own subgraph with at least 3,000 GRT to ensure that it is indexed and available for querying as soon as possible. ![Publish screen](https://raw.githubusercontent.com/alinobrasil/the_graph_getting_started/refs/heads/main/img/studio-publish-modal.png) > **Note:** The Graph's smart contracts are all on Arbitrum One, even though your subgraph is indexing data from Ethereum, BSC or any other [supported chain](https://thegraph.com/docs/en/developing/supported-networks/). ### 3. Query your Subgraph Congratulations! You can now query your subgraph on the decentralized network! For any subgraph on the decentralized network, you can start querying it by passing a GraphQL query into the subgraph’s query URL which can be found at the top of its Explorer page. Here’s an example from the [CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari: ![Query URL](https://raw.githubusercontent.com/alinobrasil/the_graph_getting_started/refs/heads/main/img/explorer-query-url.png) The query URL for this subgraph is: `https://gateway-arbitrum.network.thegraph.com/api/`**\[api-key]**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK` Now, you simply need to fill in your own API Key to start sending GraphQL queries to this endpoint. #### Getting your own API Key ![API keys](https://raw.githubusercontent.com/alinobrasil/the_graph_getting_started/refs/heads/main/img/getting-api-key.png) In Subgraph Studio, you’ll see the “API Keys” menu at the top of the page. Here you can create API Keys. ## Appendix ### Sample Query This query shows the most expensive CryptoPunks sold. ```graphql { trades(orderBy: priceETH, orderDirection: desc) { priceETH tokenId } } ``` Passing this into the query URL returns this result: ``` { "data": { "trades": [ { "priceETH": "124457.067524886018255505", "tokenId": "9998" }, { "priceETH": "8000", "tokenId": "5822" }, // ... ``` 💡 Trivia: Looking at the top sales on \[CryptoPunks website]\() it looks like the top sale is Punk #5822, not #9998. Why? Because they censor the flash-loan sale that happened. ### Sample code ```jsx const axios = require('axios'); const graphqlQuery = `{ trades(orderBy: priceETH, orderDirection: desc) { priceETH tokenId } }`; const queryUrl = 'https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK' const graphQLRequest = { method: 'post', url: queryUrl, data: { query: graphqlQuery, }, }; // Send the GraphQL query axios(graphQLRequest) .then((response) => { // Handle the response here const data = response.data.data console.log(data) }) .catch((error) => { // Handle any errors console.error(error); }); ``` ### Additional resources: * To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](https://thegraph.com/docs/en/developing/creating-a-subgraph/). * For more information about querying data from your subgraph, read more [here](https://thegraph.com/docs/en/querying/querying-the-graph/). # SubQuery SubQuery is a leading blockchain data indexer that provides developers with fast, flexible, universal, open source and decentralised APIs for web3 projects. SubQuery SDK allows developers to get rich indexed data and build intuitive and immersive decentralised applications in a faster and more efficient way. SubQuery supports 280+ ecosystems including Botanix, Cosmos, Ethereum, Near, Polygon, Polkadot, Algorand, and Avalanche. Another one of SubQuery's competitive advantages is the ability to aggregate data not only within a chain but across multiple blockchains all within a single project. This allows the creation of feature-rich dashboard analytics and multi-chain block scanners. Other advantages include superior performance with multiple RPC endpoint configurations, multi-worker capabilities and a configurable caching architecture. ### Useful resources: * SubQuery Docs: [SubQuery Academy (Documentation)](https://subquery.network/doc/) * Intro Quick Start Guide: [1. Create a New Project](https://subquery.network/doc/quickstart/quickstart.html) * [Botanix Testnet Quickstart Guide](https://subquery.network/doc/indexer/quickstart/quickstart_chains/botanix.html) * [Botanix Testnet Starter Project](https://github.com/subquery/ethereum-subql-starter/tree/main/Botanix/botanix-testnet-starter) * [Botanix Mainnet Starter Project](https://github.com/subquery/ethereum-subql-starter/tree/main/Botanix/botanix-starter) For technical questions and support reach out to `start@subquery.network` ### Running and Hosting your Botanix SubQuery APIs SubQuery is open-source and designed to be easy to run, meaning you have the freedom to run it a variety of ways: * [Locally on your own computer or on your cloud provider of choice.](https://subquery.network/doc/indexer/run_publish/introduction.html#locally-run-it-yourself) * [By publishing it to the decentralised SubQuery Network](https://subquery.network/doc/indexer/run_publish/introduction.html#publish-to-the-subquery-network), the most open, performant, reliable, and scalable data service for dApp developers. * [Leveraging a centralised hosting partner in the SubQuery community](https://subquery.network/doc/indexer/run_publish/introduction.html#other-hosting-providers-in-the-subquery-community), like OnFinality or Traceye. # RPC Providers {% hint style="info" %} **Set up your own RPC node** If you are looking to set up your own RPC node, head over to the right section: [Run a node](/botanix/run-a-node/rpc-vs-federation-node) {% endhint %} ### What are RPC Providers? RPC (Remote Procedure Call) providers are services that offer API access to blockchain networks, allowing applications to interact with blockchains without running their own full nodes. They act as gateways between your application and the blockchain, handling the complex infrastructure required to maintain reliable connections to blockchain networks. ### Why RPC Providers Matter Running your own blockchain node is complex and expensive—requiring terabytes of storage, continuous synchronization, high bandwidth, and 24/7 maintenance. RPC providers eliminate these challenges by operating professional node infrastructure and offering simple API access. ### Core Functions **Transaction Management**: Submit transactions, check status, and handle network congestion **Data Access**: Query account balances, transaction history, and smart contract state **Smart Contract Interaction**: Call contract functions, estimate gas costs, and simulate transactions **Real-time Updates**: WebSocket connections for live blockchain events and notifications ### Key Benefits * **Instant Setup**: Connect to blockchains immediately without node synchronization * **Cost Efficiency**: Eliminate expensive infrastructure and maintenance costs * **Global Access**: Professional providers offer worldwide node distribution * **Reliability**: Enterprise-grade uptime and performance guarantees * **Developer Focus**: Build applications instead of managing infrastructure ### Service Types **Free Tiers**: Basic access with rate limits, perfect for development and small apps **Premium Services**: High-performance access with enhanced features and support **Enterprise Solutions**: Dedicated infrastructure with custom SLAs and specialized support ### Integration Considerations When choosing an RPC provider, consider rate limits, geographic coverage, uptime guarantees, and cost structure. Implement caching strategies and fallback providers to ensure application reliability and manage costs as you scale. RPC providers are the invisible backbone of Web3, democratizing blockchain development by making it accessible without significant infrastructure investment. They enable the responsive, reliable applications that drive blockchain adoption and innovation. # Alchemy {% hint style="info" %} **Alchemy on Botanix** Find the public RPC information for Alchemy on Botanix here: {% endhint %} Alchemy is the leading Web3 development platform, providing enterprise-grade RPC services and comprehensive blockchain infrastructure tools. With over 1.3 million monthly visits, Alchemy has become the go-to choice for developers building sophisticated blockchain applications. ### Key Features **Enhanced APIs**: Beyond standard RPC endpoints, Alchemy offers specialized APIs including NFT API, Webhook API, and Debug API for comprehensive blockchain data access. **Multi-Chain Support**: Native support for Ethereum, Solana, Arbitrum, Optimism, Polygon, Starknet, and Astar with consistent performance across all networks. **Developer Tools**: Complete development platform including SDKs, account abstraction tools, debugging capabilities, and real-time monitoring dashboards. **Reliability**: Enterprise-grade infrastructure with guaranteed uptime and performance SLAs, trusted by major DeFi protocols and Web3 applications. ### Service Tiers **Free Tier**: 300 million compute units per month with access to the full development platform, SDKs, and APIs **Growth & Scale Tiers**: Enhanced compute units, priority support, and advanced features for production applications Alchemy's compute unit system measures resource usage more precisely than simple request counting, ensuring fair pricing based on actual API complexity and resource consumption. **Learn More**: # Ankr {% hint style="info" %} **Ankr on Botanix** Find the public RPC information for Ankr on Botanix here: {% endhint %} Ankr is a decentralized Web3 infrastructure provider that offers cost-effective blockchain RPC services across 75+ blockchains, making it one of the most comprehensive multi-chain platforms available. Ankr's Decentralized Physical Infrastructure Network (DePIN) of nodes ensures Ankr's clients always have the shortest roundtrip path for RPC requests, providing fast Web3 experiences no matter where users are. ### Key Features **Extensive Chain Support**: Node API grants access to the largest number of blockchains on the market — 75+ chains with both Mainnets and Testnets available **Decentralized Infrastructure**: Unlike centralized providers, Ankr operates a distributed network of nodes globally, reducing single points of failure and improving reliability. **Cost-Effective Pricing**: From $10/100M API Credits with flexible pay-as-you-go options, making it accessible for projects of all sizes. **Advanced APIs**: Beyond standard RPC, Ankr offers Advanced API that introduces a superior way to query blockchains and provides access to optimized, indexed, and cached archive blockchain data that allows for near-instant speeds and single-request multi-chain queries. ### Service Tiers * **Free Tier**: 30 reqs/sec for Node API, 30 reqs/min for Advanced API, 65+ chains * **Premium**: Enhanced rate limits and additional features * **Enterprise**: Custom solutions with dedicated support and SLAs Ankr has established itself as a reliable infrastructure partner for major protocols and has been among the first RPC providers for emerging blockchains like Aptos and Sui, demonstrating its commitment to supporting the expanding Web3 ecosystem. **Learn More**: # Muticall3 {% hint style="info" %} **Multicall3 Address** The contract is deployed at `0xcA11bde05977b3631167028862bE2a173976CA11` {% endhint %} ## What is Multicall3? Multicall3 is a smart contract that serves two primary functions in blockchain ecosystems. First, it allows users to **aggregate results from multiple contract reads** into a single JSON-RPC request, which reduces the number of separate requests needed, guarantees all values come from the same block, and improves performance. Second, it enables **executing multiple state-changing calls in a single transaction**. This utility contract is deployed at the same address (`0xcA11bde05977b3631167028862bE2a173976CA11`) across more than 250 blockchain networks, making it a standard tool for efficient blockchain interactions. Sources * * # Development Frameworks The following tools will help you develop and test your decentralized apps (dApps): ### Hardhat[​](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/development-frameworks#hardhat) [Hardhat](https://hardhat.org/) is a comprehensive development environment designed specifically for EVM developers. It streamlines the process of creating, compiling, deploying, testing, and debugging smart contracts. By providing a robust and customizable framework, Hardhat makes it easy to manage complex projects and integrate with other tools in the ecosystem. Its features include a built-in console, advanced debugging capabilities, and support for extending functionality through plugins, allowing developers to create efficient and secure decentralized applications. Make sure to try the [HardHat](https://hardhat.org/) - [Tutorial](https://hardhat.org/tutorial). ### Foundry[​](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/development-frameworks#foundry) [Foundry](https://github.com/foundry-rs/foundry) is a high-performance, portable, and modular toolkit designed for EVM application development, leveraging the Rust programming language. It offers a comprehensive suite of tools to streamline the process of creating, testing, and deploying smart contracts on any EVM network. Foundry facilitates seamless interaction with EVM smart contracts, transactions, and chain data, while also providing a local node and a user-friendly Solidity REPL environment for efficient development. ### Remix [Remix IDE](https://remix.ethereum.org/#lang=en\&optimize=false\&runs=200\&evmVersion=null) is a no-setup tool with a GUI for developing smart contracts. Used by experts and beginners alike, Remix will get you going in double time. Remix plays well with other tools, and allows for a simple deployment process to the chain of your choice. Remix is famous for its visual debugger. ### Truffle[​](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/development-frameworks#truffle) [Truffle](https://trufflesuite.com/) is a comprehensive suite of tools for smart contract development, providing an end-to-end solution for building, testing, debugging, and deploying on EVM compatible chains. It features advanced debugging capabilities, fast EVM simulation with Ganache, a user-centered design with a VS Code extension, and robust L1 & L2 support. Truffle prioritizes security and partners with ConsenSys Diligence to bring continuous security to projects, providing a seamless and secure developer experience. ### thirdweb[​](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/development-frameworks#thirdweb) [thirdweb SDK](https://portal.thirdweb.com/sdk) covers all aspects of the web3 development stack, including connecting to user’s wallets, interacting with the blockchain and smart contracts, decentralized storage, authentication, and more; enabling you to build scalable and performant web3 applications on any EVM-compatible blockchain. Out of the box, infrastructure is provided for everything required to create decentralized applications, including connection to the blockchain (RPC), decentralized storage (IPFS + pinning services), and tools to create powerful user experiences; such as gasless transactions, wallet connection components, FIAT on-ramps, data APIs, and more. ### Brownie[​](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/development-frameworks#brownie) [Brownie](https://github.com/eth-brownie/brownie) is a Python-based framework designed for developing and testing smart contracts on the Ethereum Virtual Machine. It offers full support for Solidity and Vyper programming languages and utilizes pytest for contract testing. Brownie also incorporates trace-based coverage evaluation, property-based and stateful testing with Hypothesis, and powerful debugging tools, including python-style tracebacks and custom error strings. # Web3 libraries and tools The following frameworks will help you build your decentralized apps (dApps): ### Ethers[​](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/web3-libraries-tools#ethers) [Ethers.js](https://docs.ethers.org/) is a comprehensive and compact library designed for seamless interaction with EVM-compatible blockchains and their ecosystems. With secure client-side private key management, compatibility with various nodes, and ENS name integration, it serves as a one-stop solution for decentralized application development needs. The library supports JSON wallet import/export, BIP 39 mnemonic phrases, and HD wallets, while remaining lightweight. Ethers.js also offers extensive documentation, full TypeScript readiness, and a generous collection of test cases, all under the open-source MIT License. ### thirdweb[​](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/web3-libraries-tools#thirdweb) [thirdweb SDK](https://portal.thirdweb.com/sdk) SDK covers all aspects of the web3 development stack, including connecting to user’s wallets, interacting with the blockchain and smart contracts, decentralized storage, authentication, and more; enabling you to build scalable and performant web3 applications on any EVM-compatible blockchain. Out of the box, infrastructure is provided for everything required to create decentralized applications, including connection to the blockchain (RPC), decentralized storage (IPFS + pinning services), and tools to create powerful user experiences; such as gasless transactions, wallet connection components, FIAT on-ramps, data APIs, and more. ### Viem[​](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/web3-libraries-tools#viem) [Viem](https://viem.sh/) is a lightweight and modular tool designed to build applications and libraries interfacing with EVM-compatible blockchains. It's optimized for performance and provides flexible programmatic APIs with extensive TypeScript typing. It offers features such as abstractions over the JSON-RPC API, APIs for smart contract interaction, language closely aligned with official Ethereum terminology, and utilities for working with ABIs. It also provides support for Anvil, Hardhat, and Ganache. ### Web3.js[​](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/web3-libraries-tools#web3js) [Web3.js](https://github.com/web3/web3.js/) is a versatile JavaScript library enabling developers to interact with EVM compatible nodes via HTTP, IPC, or WebSocket. It simplifies tasks like sending Ether, checking smart contract data, and creating contracts. As a JavaScript binding for the JSON RPC interface, web3.js is easily usable in popular web browsers, server-side Node.js applications, and Electron-based apps. Often used with the MetaMask browser extension, web3.js helps developers create decentralized applications and manage transactions directly from their preferred browser. ### Web3.py[​](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/web3-libraries-tools#web3py) [Web3.py](https://github.com/ethereum/web3.py/) is a Python library designed for interacting with EVM compatible blockchains. It's widely used in decentralized apps (dapps) to manage transactions, work with smart contracts, and access block data. Originally derived from the web3.js JavaScript API, it has evolved to cater to the needs of Python developers. The library enables users to develop clients for reading and writing data on the blockchain, including smart contract interactions, making it a versatile tool for EVM-based applications. # Cross-chain communication # CCIP & Transporter {% hint style="success" %} **Transporter Bridge** {% endhint %} ### What is Chainlink CCIP? Chainlink CCIP is a blockchain interoperability protocol that enables developers to build secure applications that can transfer tokens, messages, or both across different blockchain networks. Launched in July 2023, CCIP is powered by Chainlink oracle networks, which have secured tens of billions of dollars and enabled over $18 trillion in onchain transaction value. The protocol provides a standardized messaging interface that enables blockchains to interconnect and communicate. CCIP operates through Router contracts deployed on each supported blockchain, OnRamp and OffRamp contracts for message handling, and a Risk Management Network for monitoring and anomaly detection. The protocol supports both arbitrary messaging for sending data between smart contracts and programmable token transfers that combine asset movement with executable instructions. ### Why CCIP Exists The blockchain ecosystem faces fundamental fragmentation, where each network operates as an isolated island with its own assets, users, and liquidity. Before CCIP, applications across multiple blockchains endured fragmentation since they were restricted to specific chains. Without a blockchain interoperability protocol, systems would need separate implementations for each cross-chain interaction, which is time-consuming and complex. CCIP's security-first approach addresses that cross-chain interactions introduce significant risks. With almost $3B lost, bridge hacks are responsible for nearly 50% of all value hacked in the blockchain industry. CCIP achieves "Level-5 security" through three independent decentralized oracle networks that each execute and verify every cross-chain transaction. The Risk Management Network operates independently and can detect and halt anomalous activity in real-time. ### What is Transporter? Transporter is a hyper-secure and intuitive app for bridging tokens and messages across blockchains, powered by Chainlink CCIP. Built in association with the Chainlink Foundation, Transporter serves as a user-friendly frontend for accessing CCIP's capabilities across networks including Arbitrum, Avalanche, Base, BNB Chain, Ethereum, Optimism, Polygon, and WEMIX. Transporter addresses typical user experience challenges of cross-chain bridging by providing real-time visibility into transaction status, 24/7 global support, and an intuitive interface that abstracts away technical complexities. Users can track their assets at every step through both the Transporter app and the Chainlink CCIP Explorer. ### Why Transporter Exists Traditional bridging solutions often suffer from poor user experiences, lack of transparency, and security vulnerabilities. Too often cross-chain bridging apps are needlessly opaque, leaving users wondering about the status of their tokens. Transporter makes it easier to utilize the security benefits of Chainlink CCIP for transferring large token value and critical messages across chains. The application was designed to make cross-chain interactions accessible to users regardless of their technical expertise, providing a secure way to move both value and data across chains with complete peace of mind. ### Technical Implementation CCIP's architecture centers on Router contracts that handle message routing and fee calculation. The protocol supports multiple token transfer mechanisms including burn and mint for controlled supply tokens, and lock and unlock for tokens like ETH. The Risk Management Network continuously monitors all transactions for suspicious patterns and can halt operations if anomalies are detected. Transporter builds on this foundation by providing a streamlined interface that handles CCIP interaction complexities. The application charges no additional fees beyond standard CCIP costs, which are approximately 0.063% when paid with LINK tokens or 0.07% when paid with wrapped gas tokens. ### Integration with Botanix For Botanix, CCIP and Transporter integration provides enterprise-grade cross-chain connectivity with major blockchain ecosystems. The protocol's emphasis on security and institutional-grade infrastructure makes it suitable for Bitcoin-based DeFi applications requiring high assurance levels. CCIP's arbitrary messaging capabilities enable Botanix applications to trigger actions on other blockchains, while programmable token transfers could facilitate complex multi-chain DeFi strategies. The protocol's support for traditional financial institutions, including partnerships with SWIFT, positions it well for bridging Bitcoin DeFi with traditional finance. ### Security Considerations CCIP's Level-5 security model represents the highest tier in Chainlink's security classification system. The protocol's defense-in-depth approach includes multiple independent verification networks, separation of responsibilities between different node operators, and a dedicated risk management system that can rapidly respond to threats. The Risk Management Network's ability to trigger emergency shutdowns and impose transaction limits provides additional safeguards against potential attacks, while leveraging established Chainlink oracle infrastructure that has secured tens of billions of dollars in value. ### Further Reading For detailed technical specifications and implementation guides, refer to the official Chainlink CCIP documentation at [docs.chain.link/ccip](https://docs.chain.link/ccip) and the Transporter application at [transporter.io/help](https://www.transporter.io/help). These resources provide comprehensive guides for developers looking to integrate with CCIP, including security best practices, fee structures, and network-specific implementation details. # LayerZero & Stargate {% hint style="success" %} **Stargate Bridge** {% endhint %} {% hint style="info" %} **Endpoint information** * chainKey: botanix * stage: mainnet **Endpoint V2 Contracts:** * **EID**: 30376 * **endpointV2**: 0x6F475642a6e85809B1c36Fa62763669b1b48DD5B * **sendUln302**: 0xC39161c743D0307EB9BCc9FEF03eeb9Dc4802de7 * **receiveUln302**: 0xe1844c5D63a9543023008D332Bd3d2e6f1FE1043 * **blockedMessageLib**: 0xc1ce56b2099ca68720592583c7984cab4b6d7e7a * **executor**: 0x4208D6E27538189bB48E603D6123A94b8Abe0A0b * **deadDVN**: 0x6788f52439ACA6BFF597d3eeC2DC9a44B8FEE842 {% endhint %} ### Overview LayerZero and Stargate represent critical infrastructure components for cross-chain interoperability that can enhance Botanix's ecosystem capabilities. This documentation provides a comprehensive understanding of both technologies and their potential integration with Botanix. ### What is LayerZero? LayerZero is an open-source, immutable messaging protocol designed to facilitate the creation of omnichain, interoperable applications. It serves as a foundational communication layer between different blockchain networks, enabling seamless cross-chain interactions without requiring trusted intermediaries. LayerZero enables the realization of cross-chain applications with a low level communication primitive. The protocol is designed to be VM-agnostic, working across different virtual machines including EVM, Solana, and Aptos environments. The protocol operates through a four-step process. A smart contract on the source chain calls the endpoint's send function, which generates a standardized message packet. Decentralized Verification Networks (DVNs) verify the message on the destination chain, replacing traditional oracles with a more robust verification system. Finally, the destination endpoint executes the verified message through its lzReceive function. LayerZero is like the Internet for blockchains - where TCP/IP allows different computers running different operating systems to communicate, LayerZero enables smart contracts coded in different languages on different blockchains to communicate. ### Why LayerZero Exists The blockchain ecosystem faces a fundamental challenge: networks are designed to be secure and autonomous, but this creates silos that limit interoperability. This challenge has been exacerbated by the differing security models of various Layer-1s, Layer-2s, and modular networks. LayerZero addresses this by providing a standardized communication protocol that maintains security while enabling cross-chain functionality. LayerZero employs an immutable code approach where updates are applied through new module versions, which are implemented securely, while old versions remain operational and are never deleted. This ensures long-term stability and security for applications built on the protocol. ### What is Stargate? Stargate is a fully composable liquidity transport protocol that lives at the heart of Omnichain DeFi, enabling instant, secure movement of tokenized assets between 70+ blockchains. Built on LayerZero, Stargate provides the liquidity layer that enables seamless cross-chain asset transfers with guaranteed finality. Unlike other cross-chain solutions, Stargate does not use wrapped native tokens to move between chains. Instead, it combines the cross-validation mechanism between Oracle and LayerZero as well as the full-chain mechanism to ensure and enhance user security when bridging assets between chains. The protocol operates through unified liquidity pools that span multiple blockchains. When users initiate transfers, Stargate leverages LayerZero's messaging system to communicate transfer details across chains while providing instant settlement from its liquidity pools. Stargate transfers have instant guaranteed finality - a transfer submitted on the source chain is guaranteed on the destination. ### Why Stargate Exists Cross-chain DeFi faces significant liquidity fragmentation, where assets and activities on each chain remain isolated within their own ecosystems. Stargate Finance addresses the scalability concerns prevalent in traditional DeFi platforms through LayerZero's efficient communication protocol, ensuring that transactions are fast while reducing congestion and lowering transaction fees across networks. When LayerZero and Stargate come together, they create a powerful combination that enables seamless cross-chain transactions while providing unified liquidity across all supported networks. This combination solves the fundamental problem of accessing liquidity across different blockchain ecosystems without complex bridging solutions. ### Integration with Botanix For Botanix, LayerZero and Stargate integration enables Bitcoin-based DeFi applications to interact seamlessly with other blockchain ecosystems. This allows Botanix to connect its liquidity with major DeFi protocols on Ethereum, Arbitrum, and other networks, creating new opportunities for cross-chain Bitcoin derivatives and yield farming. The modular security model of LayerZero allows Botanix to configure appropriate security parameters for Bitcoin-specific requirements while maintaining the protocol's censorship resistance and immutability guarantees. The protocol ensures all messages are delivered without selective interference and the underlying technology framework for sending and receiving messages will never change in perpetuity. ### Technical Implementation LayerZero's architecture centers on immutable endpoint contracts deployed on each supported blockchain. These endpoints handle message dispatch and reception, while configurable message libraries generate standardized packets for cross-chain communication. The security stack includes DVNs for verification and executors for message execution, providing a robust framework for cross-chain interactions. Stargate builds upon this foundation by maintaining cross-chain liquidity pools that can be accessed instantly from any supported network. The protocol uses LayerZero's messaging system to coordinate transfers while ensuring that users receive native assets rather than wrapped tokens. ### Security Considerations LayerZero is an immutable, censorship-resistant, and permissionless protocol that enables any blockchain user to send, verify, and execute messages on a supported destination network. The protocol's security model relies on configurable verification networks and immutable endpoints, providing long-term security guarantees. For Stargate, security depends on sufficient liquidity provision across all chains and the correct implementation of complex cross-chain logic. The protocol inherits the security properties of all connected chains while adding its own layer of liquidity management and transfer guarantees. ### Further Reading For detailed technical specifications and implementation guides, refer to the official LayerZero documentation at [docs.layerzero.network](https://docs.layerzero.network/) and the Stargate protocol documentation at [docs.stargate.finance](https://docs.stargate.finance/introduction/overview). These resources provide comprehensive guides for developers looking to integrate with these protocols, including API documentation, security best practices, and network-specific implementation details. The combination of LayerZero and Stargate represents mature infrastructure for cross-chain interoperability that enhances significantly Botanix's connectivity and utility within the broader multi-chain ecosystem. # Account Abstraction with BTC Connect An initial introduction and step-by-step guide to working with BTC Connect on the Spiderchain EVM through the SDK. Particle Network's BTC Connect is the first account abstraction protocol for the Bitcoin ecosystem. It unifies smart accounts on Bitcoin Layer-2s and standard BTC accounts through native wallet interfaces. To achieve this, Particle Network has deployed ERC-4337 AA infrastructure natively on the Spiderchain EVM, which developers can tap into to leverage smart accounts. BTC Connect achieves this by, firstly, allowing users to connect to your dApp with their UniSat, OKX, TokenPocket, Bybit, or Bitget wallet. Upon connecting, a smart account is generated on the Spiderchain EVM and assigned to their BTC account. This smart account can then be used and authenticated directly through their BTC wallet, providing native Bitcoin users a simple interface to interact with applications on the Spiderchain EVM. BTC Connect natively supports the Spiderchain EVM within its flagship SDK, `@particle-network/btc-connectkit`, and has been deployed on Testnet.This document will provide an initial introduction and step-by-step guide to working with BTC Connect on the Spiderchain EVM through the SDK. ## Introduction This guide aims to showcase BTC Connect's granular integration process within a standard `create-react-app` application structure. After following the steps outlined in this document, you'll be prepared to build an application on the Spiderchain EVM that can fully utilize BTC Connect in under 50 lines of code. Currently, this is done exclusively through Particle Network's React-based SDK, `@particle-network/btc-connectkit`, which facilitates the configuration, initialization, and implementation of BTC Connect. ### Prerequisites Before getting started, you'll need to meet two essential prerequisites: 1. Generating your project’s authentication keys on the Particle dashboard. 2. Fulfilling three dependencies from Particle Network. **Dashboard Configuration** Particle Network requires the retrieval and usage of three keys to authenticate BTC Connect. These are your **Project ID**, **Client Key**, and **App ID**. To retrieve these values, head over to the [Particle dashboard](https://dashboard.particle.network) and do the following: 1. Create a new project for your application. Click on it to enter its project dashboard. 2. Within the project dashboard, create an application. 3. Finally, with an application made, copy your **Project ID**, **Client Key**, and **App ID**. If applicable, save these as environment variables within your application. **Dependency Installation** Additionally, you'll need to install a number of dependencies to use BTC Connect to its full extent. We'll be focusing on three libraries from Particle Network, including: * `@particle-network/btc-connectkit`, the primary SDK driving implementation of BTC Connect. * `@particle-network/chains`, a library that contains the `BotanixTestnet` object for connecting to the Spiderchain EVM. Any standard package manager can facilitate the installation of these dependencies, although the below example will focus on `npm` and `yarn`. ```shell yarn add @particle-network/btc-connectkit @particle-network/chains # OR npm install @particle-network/btc-connectkit @particle-network/chains ``` ## Step 1: Configuration Within this example, we'll be integrating BTC Connect into an application following a standard `create-react-app` structure. As such, we'll need to begin by configuring and initializing `@particle-network/btc-connectkit` within our `index.tsx` file (or on top of your application’s JSX leveraging BTX Connect). BTC Connect is configured through a React component. This wraps your application component (in this example, `App`) and contains various parameters, such as the aforementioned `projectId`, `clientKey`, and `appId` keys. You can start by importing the following objects from `@particle-network/btc-connectkit`: * `ConnectProvider`, the React component used for initialization. * `OKXConnector` * `UnisatConnector` * `BitgetConnector` * `TokenPocketConnector` * `BybitConnector` Between the five wallet connectors listed above, you can pick those that are best suited for your application. We'll use them in a moment to define the wallet supported by BTC Connect. For now, we'll need to configure `options` within the `ConnectProvider` component, populating the following parameters: * `projectId`, `clientKey`, `appId`. Your authentication keys, previously retrieved from the [Particle dashboard](https://dashboard.particle.network). * `aaOptions`, which contains `accountContracts`. * `BTC`, the type of smart account we'll be leveraging. * `chainIds`, an array of supported chains intended to use within the application. This should be `BotanixTestnet.id`. * `version`, the version of the smart account you're using. This should be `'2.0.0'` for now, as the Spiderchain EVM is only supported within version 2 of Particle Network’s BTC smart account implementation. * `walletOptions`, which contains: * `visible`, a Boolean determining whether or not Particle Network's embedded wallet modal will be shown after a user connects their Bitcoin wallet. If set to `true`, users will have direct access to their associated smart accounts through this embedded interface. Otherwise, if `false`, developers will need to retrieve and reflect core wallet information, such as balances, independently. With `options` defined, you'll additionally need to specify the native Bitcoin wallets you intend to support within your application through the `connectors` property. `connectors` is an array of objects corresponding with the previously imported wallet connectors; each connector instance should be expressed similarly to: `new UnisatConnector()`. Now that you've configured both `options` and `connectors` within the `ConnectProvider` component, you're ready to move on to your primary application file (`App.tsx` in this example). Below is an example of what a complete `index.tsx` file may look like in this context. ```ts import React from 'react'; import ReactDOM from 'react-dom/client'; import { ConnectProvider, OKXConnector, // UnisatConnector, // BitgetConnector, // -- Only one connector is required, although any combination of these five may be used. TokenPocketConnector, // BybitConnector // } from '@particle-network/btc-connectkit'; import { BotanixTestnet } from '@particle-network/chains'; // The component in which you're using BTC Connect import App from './App'; ReactDOM.createRoot(document.getElementById('root') as HTMLElement).render( ) ``` ## Step 2: Application Implementation At this point, you have: * Created a new project and application on the [Particle dashboard](https://dashboard.particle.network). * Installed various libraries from Particle Network. * Configured BTC Connect through `ConnectProvider` from `@particle-network/btc-connectkit`. Before BTC Connect is ready to be used within your application, you'll need to: * Decide and configure the mechanism for interacting with the Spiderchain EVM through BTC Connect (such as Ethers, as we'll do in this example). * Create a "Connect Wallet" button. * Test your BTC Connect implementation by executing transactions on both the Spiderchain EVM and native Bitcoin. We'll start by focusing on the first item there, configuring our point of interaction with the smart account generated by BTC Connect. Transactions on the Spiderchain EVM can be executed through BTC Connect with one of two mechanisms: either directly through the `useETHProvider` hook or by using a standard Web3 library such as Ethers. Let's walk through the latter. *** To begin, it's important to understand that BTC Connect is primarily controlled through React hooks, such as `useConnectModal`, `useETHProvider`, `useBTCProvider`, and so on. Therefore, to configure our Ethers object, we'll need to use `provider` from the `useETHProvider` hook. `provider` is the EIP-1193 Ethereum provider object associated with the smart account, which allows you to use existing Web3 libraries (such as Ethers) as an interface with the account. We’ll be using `provider` to construct a custom Ethers object. Below is an example of what this flow may look like with the above objects imported and defined. ```ts import React, { useState, useEffect } from 'react'; import { useETHProvider, useBTCProvider, useConnectModal, useConnector } from '@particle-network/btc-connectkit'; import { ethers } from 'ethers'; import './App.css'; const App = () => { const { provider } = useETHProvider(); const customProvider = new ethers.providers.Web3Provider(provider, "any"); ... } ``` *** With a mechanism of interacting with the user's smart account established, you'll also need to determine the mechanism by which you'll facilitate wallet connection on the front end. By default, BTC Connect has a built-in connection modal accessible through the `openConnectModal` function from the `useConnectModal` hook. Upon calling `openConnectModal`, an interface aggregating each wallet previously defined within `connectors` on `ConnectProvider` will be shown. In this scenario, `openConnectModal` can be tied directly to a "Connect Wallet" button. After a user chooses a wallet and connects, the resulting account will populate `provider` and therefore your Ethers object. An example of defining and using `openConnectModal` can be found below. ```ts import React, { useState, useEffect } from 'react'; import { useETHProvider, useBTCProvider, useConnectModal, useConnector } from '@particle-network/btc-connectkit'; import { ethers } from 'ethers'; import './App.css'; const App = () => { const { openConnectModal } = useConnectModal(); ... openConnectModal(); ... } ``` Alternatively, if you'd rather build your own interface to facilitate wallet connection, you'll need to define the `connect` function from the `useConnector` hook. `connect` will allow you to pass a specific wallet you'd like to shortcut connection to, bypassing the built-in connection interface and allowing you to build your own, as is shown below. ```ts import React, { useState, useEffect } from 'react'; import { useETHProvider, useBTCProvider, useConnector, useConnector } from '@particle-network/btc-connectkit'; import { ethers } from 'ethers'; import './App.css'; const App = () => { const { connect } = useConnector(); ... connect('unisat'); // Or 'okx', 'bybit', etc. ... } ``` ## Step 3: Transaction Execution ### The Spiderchain EVM Using the smart account, which we've configured through `ConnectProvider` and loaded into an Ethers object through `provider`, we'll be able to execute any type of transaction on the Spiderchain EVM. In this case, we'll execute a gasless (sponsored) burn of 0.001 BTC. Because the smart account (attached to the connected Bitcoin wallet) is used as the signer within our Ethers object, we can construct and execute a standard transaction by simply: 1. Loading the signer (`customProvider.getSigner()`). 2. Constructing the transaction (an object containing fields such as `to`, `value`, `data`, etc.) 3. Sending the transaction (`signer.sendTransaction(tx)`). Upon sending the transaction, the user will need to confirm (sign) it through a prompt within their connected Bitcoin wallet. BTC Connect will automatically convert this signature to an EVM-compatible one and authenticate the transaction. Below is an example of this flow, as described above. ```ts const executeTxEvm = async () => { const signer = customProvider.getSigner(); const tx = { to: "0x000000000000000000000000000000000000dEaD", // Burn address value: ethers.utils.parseEther('0.001'), // 0.001 BTC data: "0x" // Optional }; // Gasless due to usage of SendTransactonMode.Gasless within customProvider const txResponse = await signer.sendTransaction(tx); const txReceipt = await txResponse.wait(); notification.success({ message: "Transaction Successful", description: (
Transaction Hash: {txReceipt.transactionHash}
) }); }; ``` ### Bitcoin (Layer-1) Through the mechanism of connecting their native Bitcoin wallet, users can send transactions both on the Spiderchain EVM (through their assigned smart account, as covered above) and native Bitcoin. BTC Connect features a hook, `useBTCProvider`, for interacting with Bitcoin through a user's connected wallet. Specifically, from this hook, we'll need to define `sendBitcoin` for the execution of a standard P2P transaction, as shown below. ```ts import React, { useState, useEffect } from 'react'; import { useETHProvider, useBTCProvider, useConnector, useConnector } from '@particle-network/btc-connectkit'; import { ethers } from 'ethers'; import './App.css'; const App = () => { const { sendBitcoin, accounts } = useBTCProvider(); ... } ``` `sendBitcoin` is a simple function that, upon calling, will construct a transaction and request a signature from the user, leading to execution on Bitcoin. This function takes the following parameters: * `toAddress`, the recipient of the transaction. This should be a Bitcoin address of any type, such as Native Segwit, Taproot, etc. * In this example, we'll be defining `toAddress` as accounts\[0] to send this BTC back to the address executing the transaction. * `satoshis`, the value of the transaction (amount to be sent), denominated in satoshis. * Optionally, `options` can be defined to specify: * `feeRate`, used for making manual adjustments to the transaction's gas fee. In this example, we'll wrap `sendBitcoin` within `executeTxBtc`, which should look similar to the snippet below. ```ts const executeTxBtc = async () => { // Sends 1 satoshi back to the sender const hash = await sendBitcoin(accounts[0], 1); notification.success({ message: 'Transaction Successful', description: (
Transaction Hash: {hash}
) }); }; ``` ## Conclusion As a result of this tutorial, you should have now built an application that: 1. Onboards a user through their native Bitcoin wallet (such as UniSat). 2. Assigns and handles an attached smart account on the Spiderchain EVM. 3. Executes a sample transaction on the Spiderchain EVM using this smart account. 4. Sends BTC on native Bitcoin through the same connected wallet. To view and try the complete demo application based on the snippets shown in this guide, visit their [dedicated GitHub repository](https://github.com/TABASCOatw/particle-botanix-demo). [Particle Network](https://particle.network) has extensive documentation covering the implementation of BTC Connect within applications built on the Spiderchain EVM, which can be found [here](https://developers.particle.network/reference/introduction-to-btc-connect). ## Video Tutorial {% embed url="" %} # BTC <> pBTC <> stBTC # Build on the Botanix EVM We have gathered information for our three main groups of builders: 1. People who built on Bitcoin before and now want to build on the Botanix EVM - see [Broken mention](broken://pages/AYNcShOruQfNHIpuUyrs) 2. People who are used to building applications on the EVM and want to start from scratch - see [Develop a new dApp](/botanix/build-applications/build-on-the-botanix-evm/develop-a-new-dapp) 3. People who want to migrate an existing application from another chain to the Botanix EVM - see [Migrate existing dApps](/botanix/build-applications/build-on-the-botanix-evm/migrate-existing-dapps) Happy building! # Gas fees Understanding Gas Fees on the EVM and How to Optimize Transaction Costs {% hint style="warning" %} **TL;DR** Some versions of the Ethers.js library hardcode the `maxPriorityFee` to 1.5 gwei which may be unnecessarily high depending on the current base fee. To avoid overpaying for a transaction, calculate the `maxPriorityFee` manually. {% endhint %} Gas fees are a critical component of the Ethereum Virtual Machine (EVM) ecosystem, ensuring that the network remains secure and efficient. They incentivize validators to process transactions and execute smart contracts, playing a pivotal role in maintaining decentralized operations. ### The Role of Gas Fees in the EVM Every transaction on the EVM requires computational resources, and gas fees are the mechanism by which users pay for those resources. Gas fees consist of two main components: 1. **Base Fee**: Introduced with Ethereum's London Hard Fork (EIP-1559), the base fee is a mandatory, network-determined amount that adjusts dynamically based on network demand. It is burned, reducing the total ETH supply, which helps stabilize gas prices over time. 2. **Priority Fee (Tip)**: The priority fee is an optional amount that users can include to incentivize miners or validators to prioritize their transactions. This tip is paid directly to the miner or validator and is in addition to the base fee. ### The Problem with Hardcoded maxPriorityFee in Ethers.js The popular Ethers.js library, widely used by developers for building decentralized applications (dApps), hardcodes the `maxPriorityFee` to 1.5 gwei in some versions. While this value might suffice in high-demand situations, it often leads to users overpaying for transactions, particularly when network or application demand is low. #### Example Scenario * **Base Fee**: 0.000000008 gwei * **Max Priority Fee**: 1.5 gwei (hardcoded by Ethers.js) In this scenario, the priority fee is disproportionately high compared to the base fee. Instead of paying a small additional amount to incentivize miners, the user ends up paying almost the entire transaction cost as a tip. This inefficiency can significantly increase transaction expenses, especially for frequent users or in low-cost networks like Botanix. ### The Fix: Calculating the maxPriorityFee Dynamically To prevent overpayment, developers should avoid relying on the hardcoded `maxPriorityFee` value provided by Ethers.js. Instead, they can calculate an appropriate priority fee dynamically based on the current base fee and network conditions. #### Steps to Calculate the maxPriorityFee Dynamically 1. **Fetch the Current Base Fee** Use the network’s RPC endpoint to retrieve the current base fee from the latest block. 2. **Calculate an Appropriate Priority Fee** Determine a reasonable multiplier or fixed amount relative to the base fee. For example: ```javascript const priorityFee = Math.max(baseFee * 2, 0.0001); // Example logic ``` 3. **Override the Default Ethers.js Behavior** Explicitly set the `maxPriorityFee` when sending transactions: ```javascript const transaction = { to: recipient, value: amount, maxPriorityFeePerGas: priorityFee, maxFeePerGas: baseFee + priorityFee }; await signer.sendTransaction(transaction); ``` By calculating the `maxPriorityFee` dynamically, developers can significantly reduce transaction costs for their users while ensuring fair compensation for validators. # Develop a new dApp {% hint style="info" %} **Information** This section is meant for people who have experience developing dApps on an EVM-compatible blockchain like Botanix. {% endhint %} Have you ever deployed a dApp on another chain? In that case, developing dApps on Botanix will feel 100% familiar! You can find the chain details here - [Chain Information](/botanix/build-applications/chain-information). # Migrate existing dApps Here you will find some tips and tricks on how to migrate existing dApps to Botanix Developing a new dApp on Botanix is going to feel very familiar for those who are used to developing dApps but migrating requires some more work than a simple copy-paste job! In general, migrating the existing smart contracts is rather easy. One might face more issues when migrating the front end, back end or database. Some things to take into account are: * Developers may encounter issues with other infrastructure requirements see [here](https://docs.botanixlabs.xyz/botanix-labs/build-dapps/migrate-existing-dapps#differences-in-block-and-network-properties) * Look for open source projects with low dependencies * Chain independent * \= not depending on any specific property of a chain * For example: project doesn't depend on PoS on ETH * Do not require cloud provisioned nodes * Many ETH projects use Infura but that doesn't really exist outside of ETH. * This can make it tough to port backends and dApps over. * Has a active contributors / issues ## Differences in block and network properties Developers might encounter logic errors stemming from variations in block and network properties. **Differences in block properties** * Botanix does not use `total_difficulty`, `nonce`, `withdrawals`, `omners`, `mix_hash` or `parent_beacon_block_root` (EIP-4788) * Botanix stores consensus specific material in the extra data portion * Extra data larger than what Ethereum consensus allows **Differences in Network properties** * Botanix has 1 block finality * Botanix has \~ 6 second block times # RPC vs Federation Node {% hint style="warning" %} **Federation node vs RPC node** It is possible to run your own RPC node. On the other hand, it is not possible yet to run your own Federation node. {% endhint %} The Botanix network supports two types of nodes that serve different purposes in the ecosystem. ### RPC Node Running your own RPC node is an essential step for those who value decentralization and want full control over their interactions with the blockchain. By hosting your own node, you eliminate reliance on third-party services, ensuring greater privacy, reliability, and direct access to the network. Additionally, it allows you to validate transactions and support the network's decentralization. Setting up your node may involve selecting the right hardware, syncing the blockchain, and configuring the RPC settings to match your use case. For comprehensive, step-by-step instructions, visit Botanix Labs' guide on running an RPC node. **Setup Guide**: ### Federation Node Federation nodes are the backbone of the Botanix network, participating in consensus and securing the Spiderchain through the distributed multisig architecture. These nodes are operated by selected members of the Botanix Federation. #### Current Status: Closed Federation The initial federation has been carefully selected and is now closed to new participants. All current federation slots have been filled with qualified operators who meet our security, reliability, and operational standards. We are not currently accepting applications for new federation members. #### Future Opportunities As the Botanix network grows and matures, we will expand the federation to include additional members. The long-term vision for Botanix includes transitioning to a fully permissionless network where anyone can participate in consensus by staking Bitcoin and operating federation nodes. Future opportunities to join the federation will be announced through official Botanix channels. This phased approach ensures network security during critical growth phases while building toward our vision of a truly decentralized Bitcoin Layer 2. # Introduction & Mission ## About Botanix Labs Founded in 2023, Botanix Labs is the protocol research and development team that initiated and coined the Spiderchain protocol and developed Botanix, the Bitcoin-based blockchain powering the Bitcoin economy. With Botanix fully decentralized and independently operated, Botanix Labs contributes through research, developer tooling, and ecosystem growth. ## About Botanix Botanix is the first fully decentralized Bitcoin-based blockchain, enabling Bitcoin-native financial applications like lending, staking, and yield generation without wrapping or bridges for the Bitcoin economy. Powered by the Spiderchain protocol, Botanix provides EVM compatibility to Bitcoin, unlocking new use cases while preserving Bitcoin’s base layer integrity. ## Mission Statement Our mission is to enhance Bitcoin’s utility by providing secure, scalable, and decentralized solutions that empower users, developers, and institutions to leverage Bitcoin for everyday and advanced financial applications. ## Value Proposition Statement Botanix builds technologies that safeguard a decentralized financial system on Bitcoin, enabling secure, on-chain Bitcoin-native applications on its application layer, powering a global Bitcoin economy where Bitcoin is the world’s soundest money. # Glossary An explanation of often-used terms and abbreviations ## Glossary
TermAbbreviationExplanation
Botanix EVM-Name of the blockchain network developed by Botanix Labs, the first EVM equivalent layer 2 built on top of Bitcoin.
Bridging-The act of transferring bitcoin from the Bitcoin main chain to the Botanix EVM (peg-in) or the other way around (peg-out).
Byzantine Fault ToleranceBFTA property of distributed systems that allows them to continue operating correctly even when some nodes fail or act maliciously. In Botanix, the consensus mechanism can tolerate up to 5 out of 16 federation members behaving incorrectly.
CometBFT-CometBFT is a blockchain application platform that provides Byzantine Fault Tolerant (BFT) State Machine Replication (SMR) for arbitrary deterministic, finite state machines. It serves as the consensus engine for Botanix.
Consensus-The process by which distributed nodes in a blockchain network agree on the current state of the blockchain. Botanix uses CometBFT consensus with a 16-member federation.
Decentralized applicationdAppA software application that runs on a distributed computing system, often a blockchain, rather than on a single centralized server. dApps operate autonomously, with code executed on a blockchain network that is maintained by multiple nodes, ensuring transparency, security, and resistance to censorship.
Distributed Key GenerationDKGA cryptographic process that allows multiple parties to collectively create shared cryptographic keys without any single party knowing the complete key. Botanix's federation uses DKG to generate Bitcoin custody keys.
Epoch Block-Special blocks created approximately every 10 minutes that synchronize with Bitcoin blocks and trigger batch processing of peg-out requests.
Ethereum Virtual MachineEVMA decentralized computing engine that executes smart contract code on the Ethereum blockchain. It allows for the creation and execution of decentralized applications (dApps) by interpreting and running bytecode in a secure and isolated environment.
Federation-The group of 16 trusted entities that collectively secure the Botanix network through multi-signature Bitcoin custody, block production, and consensus participation.
Finality-The point at which a transaction becomes irreversible. Botanix provides immediate finality through CometBFT consensus, meaning transactions cannot be reversed once confirmed.
Flexible Round-Optimized Schnorr Threshold SignaturesFROSTA protocol that minimizes the number of rounds of communication between participants in Schnorr signature schemes. It requires a maximum of three rounds for signing and can implement 'n-of-m' threshold signatures represented by a single signature on the blockchain, saving block space and increasing privacy.
Multi-signatureMultisigA cryptographic mechanism that requires multiple signatures to authorize a transaction. Botanix uses a 12-of-16 multi-signature scheme for Bitcoin custody, meaning at least 12 federation members must sign to spend Bitcoin.
Peg-in-The process of depositing Bitcoin to receive equivalent tokens on Botanix. Users send Bitcoin to a derived deposit address and receive Botanix tokens after confirmation and federation verification.
Peg-out-The process of withdrawing Botanix tokens to receive equivalent Bitcoin. Users burn their Botanix tokens and receive Bitcoin at their specified address through federation-coordinated transactions.
Proof of AuthorityPoAA consensus mechanism where network validation is performed by approved identities, known as validators or authorities. Botanix uses PoA with its 16-member federation as the authorities.
Proof of StakePoSA consensus mechanism used in blockchain networks where validators are chosen to create new blocks based on the amount of cryptocurrency they are willing to "stake" or lock up as collateral. It aims to achieve network security and consensus more energy-efficiently compared to Proof of Work (PoW).
Proof of WorkPoWA consensus mechanism used by certain blockchains to secure the network and validate transactions. It requires participants (miners) to solve complex mathematical puzzles, which consume computational resources. Successfully solving the puzzle proves the work was done, allowing the miner to add a new block to the blockchain and receive a reward.
ReorganizationReorgA situation where previously confirmed blocks are replaced by an alternative chain. Unlike some blockchain networks, Botanix's CometBFT consensus makes reorganizations impossible, providing immediate finality.
Rust EthereumRethReth (short for Rust Ethereum) is an Ethereum full node implementation that is focused on being user-friendly, highly modular, as well as being fast and efficient. Botanix uses a modified version of Reth to run its EVM-compatible execution layer.
Spiderchain-A series of successive multisigs between Botanix Orchestrators. The security is achieved through the decentralization of these multisig wallets. This series of successive multisigs effectively creates a network that safeguards the bitcoin of the Botanix EVM.
Threshold Cryptography-A cryptographic system that allows a group of participants to collectively perform cryptographic operations without any single participant having complete control. Botanix uses threshold cryptography for Bitcoin custody and transaction signing.
Threshold Signature-A digital signature scheme where multiple parties must collaborate to create a valid signature, but no single party can create the signature alone. Botanix uses 12-of-16 threshold signatures for Bitcoin transactions.
Unspent Transaction OutputUTXOIt represents the amount of digital currency someone has left remaining after conducting transactions. In blockchain systems like Bitcoin, a UTXO serves as a token that can be spent as input in a new transaction, effectively acting as the blockchain's version of a coin or currency note.
Validator-In the context of Botanix, the federation members who participate in consensus by validating transactions and voting on block proposals. All 16 federation members serve as validators in the CometBFT consensus process.
# OFAC Compliance This page describes what OFAC is and which measures we have implemented to be OFAC compliant. ## What is OFAC? The Office of Foreign Assets Control (OFAC) is the office within the U.S. Department of the Treasury that is responsible for administering and enforcing economic sanctions against targeted foreign countries, geographic regions, entities, and individuals to further U.S. foreign policy and national security goals. Economic sanctions are used by the U.S. government to prevent targets such as terrorists, international narcotics traffickers, weapons of mass destruction proliferators, and perpetrators of serious human rights abuse from accessing the U.S. financial system for purposes contrary to U.S. foreign policy and national security interests, and to change the behavior of such targets. In this way, among others, economic sanctions can be a powerful foreign policy tool, but the effectiveness of sanctions relies upon the active participation of everyone subject to U.S. jurisdiction, including those within the virtual currency industry. ## Why OFAC compliance on virtual currencies? Virtual currencies are beginning to play an increasingly prominent role in the global economy. The growing prevalence of virtual currency as a payment method likewise brings greater exposure to sanctions risks—like the risk that a sanctioned person or a person in a jurisdiction subject to sanctions might be involved in a virtual currency transaction. Accordingly, the virtual currency industry, including technology companies, exchangers, administrators, miners, wallet providers, and users, plays an increasingly critical role in preventing sanctioned persons from exploiting virtual currencies to evade sanctions and undermine U.S. foreign policy and national security interests. OFAC sanctions compliance obligations apply equally to transactions involving virtual currencies and those involving traditional fiat currencies. Members of the virtual currency industry are responsible for ensuring that they do not engage, directly or indirectly, in transactions prohibited by OFAC sanctions, such as dealings with blocked persons or property, or engaging in prohibited trade- or investment-related transactions. ## What are OFAC sanctions? OFAC administers over 35 different sanctions programs—each designed to respond to specific threats and to further U.S. foreign policy and national security goals. As a result, the types of sanctions employed in each program may differ. Generally, OFAC sanctions can be either comprehensive or targeted in nature and can require the blocking of assets or impose restrictions on financial or trade-related activities with a specific person, country, region, or government. The most comprehensive sanctions programs that OFAC administers typically include several or all of the following types of sanctions, while other sanctions programs may only employ some of these options:
TypeDescription

Broad trade-based sanctions or embargoes


prohibit dealings with an entire country or geographic region, unless exempt or authorized. This type of sanction usually

includes a prohibition on importing or exporting goods or services to or from the sanctioned jurisdiction. Such sanctioned jurisdictions currently include Cuba, Iran, North Korea, Syria, and the Crimea region of Ukraine

Government or regime sanctionseither (1) require the blocking of all property and interests in property of a particular foreign government or regime that are or come within the United States or the possession or control of a U.S. person, or (2) prohibit specific types of transactions and activities involving a particular foreign government or regime.

List-based sanctions


target specific, listed individuals and entities and either (1) require the blocking of all property and interests in property of those listed persons that are or come within the United States or the possession or control of a U.S. person, or (2) prohibit specific types of transactions and activities with listed persons.
Sectoral sanctionstarget individuals and entities operating in specific sectors of a foreign country’s economy or prohibit specific activities associated with a sector of a foreign country’s economy.
## Who must comply with OFAC sanctions? **All U.S. persons are required to comply with OFAC regulations**. This includes all U.S. citizens and lawful permanent residents, wherever located; **all individuals and entities within the United States; and all entities organized under the laws of the United States or any jurisdiction within the United States, including any foreign branches of those entities**. Accordingly, anyone engaging in virtual currency activities in the United States, or that involve U.S. individuals or entities, should be aware of OFAC sanctions requirements and the circumstances in which they must comply with those requirements. Depending on the authorities governing each sanctions program, others may also be required to adhere to OFAC sanctions requirements. For example, OFAC’s Cuba, Iran, and North Korea sanctions programs extend sanctions prohibitions to certain foreign entities owned or controlled by U.S. persons or U.S. financial institutions. Certain activities by non-U.S. persons that involve the United States, U.S. persons, or goods or services exported from the United States may also be subject to OFAC sanctions regulations. Additionally, in most sanctions programs, any transaction that causes a violation — including a transaction by a non-U.S. person that causes a U.S. person to violate sanctions — is also prohibited. For certain sanctions programs, U.S. persons, wherever located, also are prohibited from facilitating actions on behalf of non-U.S. persons if the activity would be prohibited by sanctions regulations if directly performed by a U.S. person or within the United States. ## Implemented measures **Blocking of IP addresses coming from sanctioned jurisdictions** Based on the jurisdictions provided by the OFAC, we have implemented measures that prevent people from these jurisdictions of using our Bridge. **Blocking of addresses on SDN list** Based on the [SDN list](https://sanctionslist.ofac.treas.gov/Home/SdnList) provided by the OFAC, we block EVM addresses that are registered on that list. ### Reporting Potential Sanctions Violations Botanix Labs is committed to full compliance with OFAC regulations and has established a robust process for identifying, investigating, and reporting potential sanctions violations. If a transaction is flagged for involving a sanctioned person, entity, or jurisdiction (e.g., via SDN list screening, geolocation tools, or transaction monitoring), our compliance team, led by the designated OFAC compliance officer, will promptly investigate. This includes analyzing transaction details (e.g., wallet addresses, IP data, KYC information) within 24 hours to confirm the violation. If confirmed, we will file a Blocked Property Report or Rejected Transaction Report with OFAC within 10 business days, as required, and implement remedial measures to address root causes. Suspected violations or inquiries can be reported to , ensuring swift action to maintain compliance and mitigate risks. ## Sources * Sanctions Compliance Guidance for the Virtual Currency Industry (October 2021) - [Link]() * A Framework for OFAC Compliance Commitments - [Link]() * Chainalysis Oracle - [Link]() * OFAC Risk Matrix - [Link]() * Everything You Need to Know About OFAC’s New Sanctions Guidance for Cryptocurrency Businesses - [Link]()