# What is Bool Network An Open, Decentralized, Secure Bitcoin Verification Layer Bool Network is a permissionless, decentralized, and secure Bitcoin verification layer that aims, within the premise of not altering Bitcoin’s consensus rules, to securely and decentralize the expansion of the Bitcoin network, thereby fostering prosperity within the Bitcoin ecosystem. The transaction throughput of Bitcoin has long been a crucial concern for users. Despite Bitcoin’s clear advantages in security and decentralization, its limited transaction speed restricts its ability to effectively handle a large volume of transactions. This issue is an integral part of the blockchain impossible trilemma. To address this challenge, one of the primary solutions is the adoption of Layer 2 technologies. However, due to Bitcoin’s inherent lack of smart contract functionality, current Layer 2 solutions commonly encounter issues related to centralization. To overcome these challenges, we propose Bool Network, a decentralized and secure Bitcoin verification layer driven by MPC-based distributed key management. It aims to address the constraints on Bitcoin’s transaction speed. Bool Network comprises an evolving committee of hidden members [Dynamic Hidden Committees (DHC)](/interoperability-protocol/dynamic-hidden-committee-dhc) to safeguard the identities of committee members, we introduce the [Ring Verifiable Random Function (Ring VRF)](/interoperability-protocol/dynamic-hidden-committee-dhc/lifecycle) protocol. In this protocol, the genuine public keys of VRF instances are concealed within a ring. Furthermore, to ensure the privacy and integrity of key components, all key management procedures are executed within a Trusted Execution Environment (TEE), such as Intel SGX. This proposal seeks to mitigate Bitcoin’s transaction speed limitations while upholding its decentralization and security. #### Resources: Website: Explorer: GitHub: Dashboard: Bridge Explorer: #### Social: Twitter: Discord: Telegram: Medium: Youtube: #### Articles: * White paper: * Yellow paper: # Key features and benefits Discover the powerful key features and benefits of Bool Network into six aspects Bool Network is a decentralized and trustless network aimed at providing decentralized signature services. It employs Zero-Knowledge Proofs, Multi-Party Computation, and Trusted Execution Environment technologies, and introduces the Dynamic Hidden Committee (DHC) in an innovative manner to address the challenges of secure computation in a decentralized environment. Cross-chain capability is the key to enhance Bitcoin scalability. In this section, we will delve into six key aspects of Bool Network, evaluating its performance based on the conventional impossible triangle in the context of cross-chain.

Impossible hexagon for cross-chain bridges

#### Cost * Gas cost of cross-chain verification is incredibly economical, equivalent to a single on-chain signature verification. * Bool Network's cost-efficiency aligns with externally verified bridges, providing a budget-friendly option for cross-chain operations. * Economical cross-chain transactions make Bool Network an attractive solution for various blockchain use cases. #### Speed * Optimized design results in minimal on-chain and off-chain calculations, contributing to impressive cross-chain transaction speed. * Absence of relay chain design eliminates redundant second-order verification, further enhancing cross-chain speed. * Bool Network's high-speed cross-chain communication significantly improves the overall blockchain user experience. #### Security * The advanced security model within Bool Network effectively safeguard against external hacker attacks, ensuring assets and data integrity. * Internal conspiracy prevention mechanisms prevent collusion and insider threats, bolstering the trustworthiness of the network. * The strong security foundation inspires confidence in users, making BOOL Network an ideal platform for decentralized signature services. #### Liveness * Each Dynamic Hidden Committee (DHC) in Bool Network is equipped with one or more backup DHCs upon creation, ensuring continuous availability. * Backup DHCs effectively mitigate the risks associated with potential downtime due to a significant number of Trusted Execution Environment (TEE) nodes being offline. * The high level of liveness in Bool Network guarantees uninterrupted operations, crucial for time-sensitive cross-chain transactions. #### Generality * Bool Network's versatility extends to supporting various asset types, enabling seamless cross-chain exchange of assets. * The network's capability for arbitrary message transmission across heterogeneous networks makes it a flexible solution for diverse use cases. * With its general approach, Bool Network can accommodate new and evolving blockchain assets and protocols, ensuring long-term relevance. #### Scalability * Bool Network's efficient deployment process for supporting new heterogeneous chains involves a set of simple contracts. * This streamlined approach ensures scalability, as adding support for new chains can be accomplished quickly and with minimal development time. * The network's successful integration with all mainstream blockchains and non-Turing complete chains like Bitcoin further demonstrates its scalability. * Bool Network's ability to adapt to diverse blockchain ecosystems positions it as a robust and forward-looking infrastructure for cross-chain bridges. # Roadmap and Milestones Explore Bool Network's ambitious roadmap and significant milestones #### January 2024 * Release the Bool Network [whitepaper](https://github.com/boolnetwork/whitepaper/blob/main/Bool_Network_A_Bitcoin_Verification_Layer.pdf) and [yellowpaper](https://github.com/boolnetwork/yellowpaper/blob/main/BoolNetwork_yellowpaper.pdf), detailing design principles and vision. * Optimize the [Bitcoin-to-Layer 2 bridge](https://boolbridge.com/) to enhance efficiency and reliability. * Design the framework for Bool Network’s economic model, ensuring balanced incentives and inflation control. * Integrate Trusted Execution Environment (TEE) into the testnet for enhanced security. #### February 2024 * Launch the BRC20 cross-chain bridge for asset exchange between Layer 2 and Bitcoin. * Complete the audit of the Bitcoin cross-chain bridge contract. * Release a test version of the Bitcoin Taproot Escape Hatch module. * Initiate the Alpha testnet and gather feedback from the community. #### March 2024 * Launch a test version of the economic model for evaluation. * Continue integration of cross-chain support for multiple Bitcoin Layer 2 networks. #### April 2024 * Launch the [Beta testnet](https://beta-testnet.boolscan.com/) for comprehensive testing. * Release a test version of the Forced Exit module to ensure reliable withdrawal operations. #### May 2024 * Conduct integration testing and performance optimization of Bool Network. * Launch the incentivized Beta testnet, encouraging community participation in cross-chain transaction testing through rewards. * Complete the Beta testnet upgrade, improving tokenomics, DHC nodes, and staking requirements. #### June 2024 * Complete the audit of the EVM cross-chain bridge contract. * Launch the [EVM cross-chain](https://boolbridge.com/evm/) functionality, supporting major EVM-compatible blockchains and Layer 2s. * Support liquidity cross-chain solutions for major assets like $ETH, $USDT, and $USDC. * Integrate mainstream Web3 wallets. * Integrate UTXO-based blockchains. #### July 2024 * Upgrade multiple versions of DHC nodes, improving stability and security. * Launch the [Bool Bot](https://t.me/boolfamily_Bot), a Web3 application on Telegram, facilitating staking and cross-chain transactions. * Enable cross-chain support for RUNES tokens. * Complete the audit of the RUNES cross-chain bridge contract. * Launch TON cross-chain functionality. * Host joint reward events with major wallet partners. #### August 2024 * Integrate BRC20 and RUNES [cross-chain](https://boolleap.com/) functionality with Nervos Network (UTXO-based). * Optimize and update the Bool Bot product, surpassing 1 million Telegram Bot users. * Launch the global ambassador program. * Start the “[Bool Tech Daily](https://www.youtube.com/@bool_official)” series to introduce the community to DHC and BTCFi innovations. #### September 2024 * Integrate Fractal Bitcoin (UTXO-based) and launch BTC and BRC20 [cross-chain](https://fractal.boolbridge.com/) functionalities. * Integrate Babylon’s decentralized Restaking functionality. * Launch the [Pioneer Nodes Plan](https://bool.network/pioneer-nodes). * Complete a test version combining Taproot, DHC, and HTLC for decentralized asset custody. * Release a test version of the infrastructure for BTC-collateralized stablecoins. * Continue optimizing and updating Bool Bot, reaching over 2 million Telegram Bot users. #### October 2024 and Beyond * Launch the Beta mainnet. * Conduct the Token Generation Event (TGE). * Release the stable version of the infrastructure for BTC-collateralized stablecoins. * Release the stable version of decentralized Restaking functionality. * Update the mainnet version of Bool Bot. * Conduct comprehensive core code security audits. * Expand the DHC nodes count to over 500. * Continue expanding the community ambassador program and key opinion leaders (KOLs). * Expand Ecosystem and Partnerships. * Open source the code for Bool Network to encourage community participation and review. # Overview Building from zero to one has never been an easy question, especially for builders in the rapidly evolving Web3 industry. A successful and sustainable protocol does not come from optimizing existing products, but it originates from filling in blanks in the industry. We have witnessed the bloom of blockchains and cryptocurrencies, the craze of DeFi summer, and the romanticism of NFTs. However, the extensibility of the whole industry has been trapped in the isolated status of different ecosystems. Although diversified protocols have contributed to this field, none of them has properly solved security, decentralization, and scalability simultaneously. Based on our experience in privacy computing, we proposed Bool Network. An innovative omnichain interoperability protocol relies on an external but decentralized signature scheme to facilitate secure and arbitrary message transmission across heterogeneous ecosystems, regardless of consensus mechanism. [Dynamic Hidden Committees](/interoperability-protocol/dynamic-hidden-committee-dhc) are the executors of the decentralized signature scheme. Each MPC-based DHC manages a private key of which the security is ensured by our innovative Ring VRF protocol and three underlying technologies. DHC ensures off-chain message security and generates verifiable on-chain claims to prove the validity of cross-chain messages, which makes Bool Network highly scalable to heterogeneous blockchain ecosystems. Omnichain protocols built on Bool Network are truly trustless since the security of their cross-chain channel neither depends on protocol builders themselves nor any centralized entities, but on customizable DHCs which operate consistently based on the systematic logic and private key fragments stored in TEE hardware of their members - MPC nodes. # Architecture

### Underlying Technologies Bool Network is the first permissionless cross-chain protocol based on Multi-Party Computation (MPC), Trusted Execution Environment (TEE), and Zero Knowledge Proof (ZKP) to facilitate omnichain interoperability across heterogeneous ecosystems. We furthermore proposed [Ring VRF](/interoperability-protocol/dynamic-hidden-committee-dhc/lifecycle#ring-vrf-protocol), a ZKP-based protocol to guarantee the underlying security of the system. Technical details about Ring VRF can be found in this [paper](https://ieeexplore.ieee.org/document/9903072). ### Key Components In general, the kernel of Bool Network consists of three main modules: Dynamic Hidden Committees, BoolChain and an External Relayers System. Each of these is described below, along with their functionality in Bool Network. #### [Dynamic Hidden Committees (DHC)](#dynamic-hidden-committees-dhc) * Security guards in Bool Network to ensure the safety of cross-chain messages from the application layer. * Each committee manages a unique private key which has been distributed to a specific group of MPC nodes. * Each collection of private key fragments is separately stored in the TEE hardware of a committee's members, i.e. MPC nodes. * Ring Verifiable Random Function (Ring VRF) protocol is the underlying algorithm to protect and prove the committee's membership of an MPC node. #### Bool Chain * A public chain which performs as an ordinarily distributed ledger. * At the early stage, the chain is specialized to support and record the lifecycles and actions of [Dynamic Hidden Committees](/interoperability-protocol/dynamic-hidden-committee-dhc) in the network. * It is an EVM-compatible blockchain where applications can be built on top of the Bool Chain in the future. #### External Relayers * Refer to participants who are responsible for submitting destination transactions in Bool Network. * Designed as a competitive, efficient, and highly accessible system which is open to the market. * Participants can profit from each transaction that they submitted to the destination chain. * Do not guarantee the security of cross-chain messages. ### Infrastructure Layer We deployed several primary contracts on each blockchain to help developers build their omnichain applications on Bool Network: * `AnchorFactory`: deploy `Anchor` contracts which serve as application-specific endpoints to connect users' contracts with the core module of Bool. * `Messenger`: an official cross-chain message delivery port which connects to all the anchor contracts on the same chain. It has two main functionalities: transmit source chain messages to Bool Network and forward messages to registered anchor contracts on the destination chain. {% hint style="info" %} The above description of the infrastructure layer only fits ecosystems that have smart contracts or similar structures. The alternative design for exotic networks will be published in the future. {% endhint %} ### Application Layer This layer contains all the ecosystems/protocols/applications built on top of BOOLNetwork, including but not limited to tokens, NFTs, DeFis, cross-chain protocols, Oracles and public chains. # Dynamic Hidden Committee (DHC) Customizable security guards follow a decentralized signature mechanism to process cross-chain messages Different from existing cross-chain solutions, Bool Network applies an external verification model to securely process cross-chain messages in a decentralized and distributed manner. Dynamic Hidden Committee (DHC) is proposed to guarantee the security of omnichain applications built on top of it. Each DHC manages a private key in Bool Network and the private key is distributed into key shares and stored in the DHC members, i.e a group of MPC nodes. DHC follows a decentralized signature scheme which uses its underlying private key to sign cross-chain messages and yield signatures as on-chain verifiable "claims" to indicate the validity of cross-chain messages. More specifically, each user in Bool Network can deploy his application-specific DHCs to serve his own application's cross-chain bridge. Bool Network has provided a comprehensive [interface](https://boolscan.com/dashboard/) for its users, i.e. bridge builders, to construct their personal and customizable bridge safeguards (DHC) and on-chain message endpoints ([`Anchor`](/evm-ecosystem/smart-contracts/on-chain-endpoint-anchor/anchor.sol)). {% hint style="info" %} Bool Network Testnet has been launched and developers can follow the guides provided [here](/evm-ecosystem/amt-bridges) to build bridges and test their cross-chain applications in EVM ecosystems. {% endhint %} # Security trust flow Bool Network applies an external verification model to guarantee the security and consistency of arbitrary cross-chain messages where the security is ultimately controlled by private keys managed in the network. The following graph depicts the trust flow of cross-chain message security from the perspective of a user smart contract which is represented as `Consumer` in the following case.

The security trust flow of cross-chain messages.

# Lifecycle ### Lifecycle of a committee

The lifecycle of a series of committes that manages a specific private key in Bool Network.

### Ring VRF Protocol Ring Verifiable Random Functions protocol is based on Non-Interactive Zero-Knowledge Proof. It is implemented to ensure the underlying security of DHCs. More specifically, Ring VRF protocol is used to protect the committee members where the real identites of a group of MPC nodes are hidden among a ring, which eliminates the possibility of internal collusions and considerablely increase the cost of external attacks. # Messaging Layer The following graph demonstrates how the messaging layer of Bool processes a cross-chain message: * The Monitor server captures the cross-chain message emitted by the Messenger contract on the source chain and submits the message onto the Bool chain. * DHCs in Bool Network fetch the cross-chain message from the Bool chain and decodes the packed message following a pre-defined standard. More specifically, a valid cross-chain message must include two vital destination information: Chain ID and the identification of Anchor, such as `address`. * The only committee controlling the destination Anchor will reorganize the cross-chain message based on the standard of the destination. * The committee members independently verify the finality of the message on the source chain and sign the message based on the Threshold Signature Scheme (TSS). * A signature is generated which can be verified on-chain to prove the validity of the corresponding message. * The External Relayers system will synthesize `(message, signature)` and submit the packed information to the destination chain.

# Self Custody By combining Taproot with [DHC](https://docs.bool.network/interoperability-protocol/dynamic-hidden-committee-dhc), Bool Network enables Bitcoin DeFi with self-custody, ensuring cryptographic trust for Restaking, Bitcoin-Collateralized Stablecoin, and Bridge applications on native Bitcoin.

# Channels A Self Custody protocol is composed of three channels. ## Whale Two-way Channel Any user is eligible to submit an application to the system to open an exclusive whale channel. After a strict review process, applicants who meet the requirements will be granted the identity of a valid channel. While ensuring the characteristics of decentralization and self-custody, this channel can successfully mint BTC into WBTC. When users use the whale channel to convert WBTC back to BTC, they need to obtain the explicit confirmation of the owner of the whale channel. If the whale owner does not confirm and exceeds the preset time-lock period of the channel, the system will intervene and safely transfer the BTC in the whale channel to the one-way channel, and this operation is called a forced withdrawal.Users can retrieve their BTC via a one-way Channel. Once the DHC fails, and the time lock expires, the project will have the right to withdraw BTC assets from the Whale Channel and ensure that these assets are distributed to each user in a fair and orderly manner. Asset unlocking conditions: * The owner of the channel and the committee agree. * The time lock for forced withdrawal expires. * The escape time lock expires. ## Retail Two-way Channel The retail channel, as a special case of the whale channel, has the privilege of being opened exclusively by the Bool Network team. It not only has all the functions of the whale channel but is also renowned for its automation, high-efficiency response, and convenience in handling small-amount operations, bringing users an unprecedented user experience. Asset unlocking conditions: * The Bool Network team and the committee agree. * The time lock for forced withdrawal expires. * The escape time lock expires. ## One-way Channel The one-way channel focuses on the one-way conversion from WBTC to BTC and is used to store assets from forced withdrawals. It can smoothly convert WBTC back to BTC even in the face of failures in the whale or retail channels. Once the one-way channel fails, all assets will be quickly and safely transferred to the multi-signature address to ensure the safety of the assets. Asset unlocking conditions: * The committee agrees. * The escape time lock expires.

Two time periods that need attention are the "escape lock time" and the "forced withdrawal lock time". Generally, the escape lock time is longer than the forced withdrawal lock time. The system sets the escape lock time equal to the forced withdrawal lock time plus six months, which means that the system has a six-month response time to transfer the assets of abnormal channels to the one-way channel. Meanwhile, the escape lock time of the one-way channel is longer than that of the non-one-way channels, so that users have sufficient response time to convert WBTC back to BTC. > **Note: The escape lock time of the one-way channel > The escape lock time of the non-one-way channels > The forced withdrawal lock time.** # Workflow The diagram illustrates the process of creating and spending various Bitcoin outputs through different transactions as described in the following paragraphs.

There are four types of transactions in the Self Custody system: * Mapping Credential Transaction * Burning Credential Transaction * Forced Withdrawal Transaction * Escape Hatch Transaction ### Mapping Credential Transaction The mapper generates WBTC by creating a mapping transaction. This is a Bitcoin transaction where a certain amount of bitcoins to be minted is submitted to a mapping script approved by Bool Network. These scripts lock a selected number of BTC. The requirements for a valid mapping transaction are: * It can contain an arbitrary number of inputs. * It can contain any number of outputs. One of these outputs must be the taproot output submitted to the BTC mapping script recognized by Bool Network. Hereafter called the mapping output. The output must also contain an OP\_RETURN with the information that needs to be map. ### Burning Credential Transaction When BTC mappers want to redeem their assets before the originally promised time lock expires, they use the burning credential transaction. The requirements for a valid burning credential transaction are: * It can contain any number of inputs that point to the mapping output of the mapping credential transaction。 * It can contain at least two outputs, the first is the address of the BTC mapper. the second must also contain an OP\_RETURN with burn information. If the selected input amount has excess BTC assets after deducting the burn amount, a taproot output of the BTC mapping script identified by Bool Network is added. ### Forced Withdrawal Transaction When the BTC mapper does not burn the assets before the time lock expires, due to disagreements over the content of the burning credential transaction, the committee will use a forced withdrawal transaction to transfer the assets out of the mapping script. The requirements for a valid forced withdrawal transaction are: * It can contain any number of inputs that point to the mapping output of the mapping transaction. * It contains only one output, which must be the taproot output submitted to the mapping script recognized by Bool Network. Unlike mapping credential transaction, the output of a forced withdrawal transaction does not require an additional OP\_RETURN. ### Escape Hatch Transaction # Escape Hatch Multi-Sign Escape Hatch uses the multi-sign tapscript and timelock tapscript to support joint asset maintenance by multiple parties. It has two payment methods, when all signers agree on a certain spending output, then execute a multi-sign trapscript script. If any of them do not agree and the time expires, the time lock trapscript is executed and the output is spent by the validator specified in the script. A standard Taproot address generation formula: ``` Q= P+H(P|c)G Q = the final Taproot public key P = the internal public key H(P|c) = A hash of the internal public key and the commitment c = MAST ``` To sign a transaction with our private key, adjust the private key using the same hash value H (P|c) as the public key and commitment. Taproot uses a simple trick involving something called a "merkle tree". ``` hash(ab, cd) <- Final hash (the root) / \ hash(a, b) hash(c, d) <- Combined hash (the branches) / \ / \ hash(a) hash(b) hash(c) hash(d) <- Initial hash (the leaves) [ script(a), script(b), script(c), script(d) ] ``` Combine the previous knowledge to finally generate the Escape Hatch address: ``` Q = PK + H(PK | Fh)G | | +-----------+ +----------------+ | | PK +-------Final|hash---+ | | | | | | PK1+PK2 | | hash(a) hash(b) Multi-sign script Timelock script +-------------------+ +-----------------+ | PK1 | | TIME | | OP_CHECKSIGVERIFY | | OP_CLTV | | PK2 | | OP_DROP | | OP_CHECKSIG | | PK3 | | | | OP_CHECKSIG | +-------------------+ +-----------------+ ``` # Rules Bool Network is currently conducting online testing for its point rewards campaign on [**Beta Testnet**](/user-guide/beta-testnet). This testing phase aims to evaluate the campaign's functionality, identify potential issues, and gather user feedback before a full-scale launch. The campaign portal: {% embed url="" %} There are three types of point rewards in the campaign. ### **Cross-Chain Rewards** * Earn 200 points for each cross-chain transaction of BTC, BRC20, and Runes. * All SAVM bridge-related point rewards are increased by 10%. ### **Staking Rewards** * Earn 1 point per day for every 1000 tBOL staked. * Points are distributed daily based on the total staked balance of each address. ### **Social Rewards** {% hint style="danger" %} * Invitation codes **will only be activated** after completing one of the three cross-chain, staking, and social campaign tasks and **earning points**. Using an inactive invitation link or invitation code will not result in any registration points, referral points, or second-level referral points. * Each inviter address or invitation code has a maximum invitation limit of **1,000 invitees**. Once this limit is exceeded, subsequent invitations using the same address or code will not be eligible for corresponding first-level or second-level invitation points rewards. {% endhint %} #### **Referral Rewards** * Invitees earn 10 points for each successful referral. #### **Registration Rewards** * New users earn 1 point upon their first log-in using an invitation link or manually entering an invitation code. * To be eligible for the registration reward, please use an invitation link or code during registration. #### **Second-Level Referral Rewards** * 1 point will be awarded to first-level inviters upon successful registration of their second-level invitees. #### **Social Campaign Rewards** * Points are awarded for participating in social campaigns. [**TaskOn**](https://taskon.xyz/) is the first partner of social campaign tools. * We use campaign tools like TaskOn to collect your social activity points. These points are automatically added to your BOOL points balance once per day for accurate tracking. So you can focus on completing tasks and earning rewards! # Links ### Bool Campaign: Bridge: ### Binance Campaign: Bridge: ### OKX Campaign: Bridge: ### Bitget Campaign: Bridge: ### Gate Campaign: Bridge: ### TP Campaign: Bridge: ### Math Campaign: Bridge: # FAQ ### What is the benefit of the BOOL points? Bool Network is rewarding users with points for various activities within its ecosystem. These points can be accumulated and redeemed for various benefits such as $BOOL airdrop when the BOOL Mainnet is going alive. ### How can I participate in the campaign? You can join the campaign via the [campaign page](https://campaign.bool.network/) and complete the task step by step. # Beta Mainnet Welcome to Bool Network Beta Mainnet. It is a new era for all Booleans! Just follow the steps one by one before diving into the new ocean. Step 1. Get to know the chain [configuration information](/user-guide/beta-mainnet/network-information). Step 2. Configure the network information in your web3 wallet, such as MetaMask. Step 3. Stay tuned! # Network Information | Variable | Value | | ----------------------------- | --------------------------------------------------------------------------- | | Network Name | Bool Beta Mainnet | | RPC URL | | | Chain ID | 11100 | | Currency symbol | BOL | | Decimals | 18 | | Block explorer URL (optional) | [https://beta-mainnet.boolscan.com/](< https://beta-mainnet.boolscan.com/>) | # Beta Testnet #### For normal users, you can start from here： {% content-ref url="/pages/TJnaoAzaYYuuftlOIqTw" %} [Getting Started](/user-guide/beta-testnet/getting-started) {% endcontent-ref %} {% content-ref url="/pages/uiYSEBmxh7HEqXAEIQD9" %} [Network Information](/user-guide/beta-testnet/network-information) {% endcontent-ref %} {% content-ref url="/pages/k0iv6FAl1RhqAbpkwVjF" %} [Wallet Setup](/user-guide/beta-testnet/wallet-setup) {% endcontent-ref %} {% content-ref url="/pages/vS12tBUkvjc0i0OMN1el" %} [Token Faucet](/user-guide/beta-testnet/token-faucet) {% endcontent-ref %} #### For node owners, you will need to know: {% content-ref url="/pages/jyB1pRevH1rtrIxoNQxS" %} [DHC Update](/user-guide/beta-testnet/dhc-update) {% endcontent-ref %} #### For node participants, you will need to know: {% content-ref url="/pages/qYR7C9LQMuTB6NCk3QRB" %} [Node Server](/user-guide/beta-testnet/node-server) {% endcontent-ref %} {% content-ref url="/pages/OMOnBQxJWFuBz9p2GFm1" %} [Node Setup](/user-guide/beta-testnet/node-setup) {% endcontent-ref %} {% content-ref url="/pages/b4jyMgt0Iuigyhj96ZPD" %} [Node Management](/user-guide/beta-testnet/node-management) {% endcontent-ref %} # Getting Started Welcome to Bool Network Beta Testnet! The Beta Testnet is an upgraded version of the Alpha Testnet, optimized for economic modeling, chain scalability, and overall functionality. ### Overview Here are the key steps to familiarize yourself with **Beta Testnet**: 1. [**Network Information**](/user-guide/beta-testnet/network-information)**:** Get to know the chain configuration information of Beta Testnet. 2. [**Wallet Setup**](/user-guide/beta-testnet/wallet-setup)**:** Set up your EVM wallet like MetaMask to handle tBOL on Beta Testnet. 3. [**Token Faucet**](/user-guide/beta-testnet/token-faucet)**:** Obtain tBOL to conduct transactions on Beta Testnet. 4. [**DHC Update**](/user-guide/beta-testnet/dhc-update)**:** Get the latest image version and boot-node information from here. ### Node Related 1. [**Node server**](/user-guide/beta-testnet/node-server): Get to know the requirements of the device machine for the node. 2. [**Node setup**](/user-guide/beta-testnet/node-server): How to set up the code script of node service step by step. 3. [**Node management**](/user-guide/beta-testnet/node-management): How to run or join the node service and manage the node. ### Useful Links * Explorer： Blockchain Explorer: Bridge Explorer: Oracle Explorer： (Not Open) Node Explorer： * Doc： White paper: Yellow paper: GitHub: Developer： ### About Refund When the test phase is over, the USDT refund will be arranged directly to the payer addresses of the participant who prepaid USDT for tBOL on Beta Testnet. Note: The former participant who prepaid USDT for tBOL on Alpha Testnet will get the same quantity of tBOL airdrop directly to the same wallet address. # Network Information | Variable | Value | | ----------------------------- | --------------------------------------------- | | Network name | Bool Beta Testnet | | RPC URL (http) | | | RPC URL (wss) | wss\://betatest-rpc-node-ws.bool.network | | Chain ID | `481` | | Currency symbol | `tBOL` | | Block explorer URL (optional) | | # Wallet Setup To interact with Bool Network Beta Testnet and manage tBOL on this network, setting up a MetaMask wallet is essential. Follow these steps to configure MetaMask for Bool Network: ### Installing Wallet Install the wallet browser extension or mobile app if you haven't already. MetaMask: [https://metamask.io/download](https://metamask.io/download/) OKX: [https://www.okx.com/download](https://www.okx.com/download/) Bitget: [https://web3.bitget.com/en/wallet-download](https://web3.bitget.com/en/wallet-download/) TP: ### Wallet Import or Creation Import existing EVM wallets into the wallet or create new wallets specifically for managing tBOL on Bool Network. ### Network Configuration Configure the network to interact with the Beta Testnet. Add the network [details](/user-guide/beta-testnet/network-information), including the RPC endpoints and chain ID, to enable seamless communication. # Token Faucet {% hint style="info" %} **Disclaimer** During the testing network phase, the system automatically distributes tBOL to users proportionally as they complete relevant operations. This streamlines functionality testing. However, the testnet tokens only serve temporary purposes and hold no real value. {% endhint %} ### The faucet link [**BOOL Network Faucet**](https://faucet.bool.network/) ### Option 1: Exchange with USDT (Not available) Connect the browser plug-in wallet (e.g. MetaMask, etc.), and then use the wallet address to transfer USDT to the receiving address below. Once the system detects a balance change in the receiving address, it will automatically trigger the release of tBOL at a fixed ratio of 1:10. Please use the EVM address as the sender account and add the test network configuration to the wallet in advance. USDT receiving address (supports BSC, Polygon, Optimism chains): **0x2000B83c88DC238B66A9E72e1B62C446d39ceef7**

Please be patient as the transfer may take up to five minutes. ### Option 2: Claim free airdrop User can claim **200 tBOL** airdrops for each **BTC** cross-chain interaction via the bool main bridge or the partners bridges below. #### Main Bridge BOOL Bridge: #### Partners Bridge SAVM Bridge: AIL2 Bridge: B2 Bridge: # DHC Update ### Beta Testnet Image Version: ``` Version 39: v0.12.20 ``` Bootnode: ``` /ip4/172.210.130.200/tcp/38701/p2p/12D3KooWQBrkBWb3tLoUpxqXebxg1Eab24LfcFP3hv37ZF2c6qgz /ip4/20.81.161.179/tcp/38701/p2p/12D3KooWMDqap7HMjA6nos1HpHpWt8JBcPepnZgYSd5PPmovAqD7 ``` # Node Server {% content-ref url="/pages/NsgqYeGwsvh5KTpmP6P5" %} [Recommend List](/user-guide/beta-testnet/node-server/recommend-list) {% endcontent-ref %} {% content-ref url="/pages/KD5rF79vBfbWCvZPip9X" %} [Purchase Guide](/user-guide/beta-testnet/node-server/purchase-guide) {% endcontent-ref %} # Recommend List {% hint style="danger" %} NOTE that DHC nodes **MUST support Intel® SGX2** (TEE hardware). {% endhint %} ### Physical Machine * CPU: Intel Xeon 4310 \* 1 * Memory: 16G DDR4 ECC REG \* 8 * Storage Disk: 1.92T SATA SSD \* 1 * System Disk: 480G SATA SSD \* 1 * Network: Gigabit Ethernet (Integrated RJ45 1000Gb \* 2 + Independent 1000Mbps \* 1 ) * Power: 2 hot-swappable supplies (Support 550W 1+1 redundancy) * Others: PCI-E Gen.4 x8 slots \* 2 / PCIe Gen.4 x16 slots \* 3 ### Cloud Service * AliCloud: g7t, c7t, r7t * Tencent Cloud: M6ce * Microsoft Cloud: DCsv3, DCdsv3 # Purchase Guide ### AliCloud * **Purchase Links:** [**https://ecs-buy.aliyun.com/**](https://ecs-buy.aliyun.com/) * **Buyer's Guide:** Note: The ecs.g7t series, ecs.c7t series, and ecs.r7t series all support Intel® SGX2. {% embed url="" %} * **Configuration Reference:** Payment Type: **Yearly & Monthly | Volume Based Payment** Territory: **China (HONG KONG)** Instance: **Security Enhanced g7t，ecs.g7t.xlarge，8vCPU 32GiB** Mirror: **Ubuntu 18.04 64-bit UEFI Edition** System Disk: **ESSD cloud disk 2048GiB** Public IP address：**Assign public IPv4 addresses** Bandwidth billing model: **by fixed bandwidth** Bandwidth：**20Mbps** Management Settings: **Password** * **Reference quote:** **￥5231.2/month | ￥6.855/hour + ￥1.000/GB** ### Tencent cloud * **Purchase Links:** [**https://buy.cloud.tencent.com/cvm**](https://buy.cloud.tencent.com/cvm) * **Buyer's Guide:** Note: The Security Enhanced Memory M6ce supports Intel® SGX2 and is only in stock in Shanghai and Beijing. {% embed url="" %} * **Configuration Reference:** Configuration mode: **Customized** Billing Mode: **Yearly and Monthly | Volume Based Billing** Region: **China - Hong Kong, China** Instance: **M6Ce.2XLARGE64 (Security Enhanced Memory Type M6ce, 8-core 64GB)** System: **Ubuntu Server 20.04 LTS 64-Bit** Storage: **Universal SSD Cloud Drive - 2048GiB** Bandwidth: **20Mbps** Login: **Password (self-set)** * **Reference quote:** **4Core32GB：￥3187.54/month | ￥3.41/hour + ￥0.80/GB** ### Microsoft cloud * **Purchase Links:** [**https://portal.azure.com/#create/Microsoft.VirtualMachine-ARM**](https://portal.azure.com/#create/Microsoft.VirtualMachine-ARM) * **Buyer's Guide:** Note: The **DCsv3** series and **DCdsv3** series support Intel® SGX2 in the following regions: Central Canada, Eastern United States, Eastern United States2, Western United States, Western United States2, Central United States, South Central United States, Northern Europe, Western Europe, Eastern Japan, Western Japan, Northern Switzerland, Southeast Asia, Northern Italy, Central India, and Southern United Kingdom. {% embed url="" %} * **Configuration Reference:** Virtual Machine Name: **Set it up yourself** Region: **(Asia Pacific) Southeast Asia** Image: **Ubuntu Server 20.04 LTS - x64 Gen2** Size: **Standard DC4s\_v3-4 vcpus, 32 GiB RAM (US$350.40/month)** Authentication Type: **Password** Username: **Set by yourself** Password: **Self-set** OS Disk Size: **2TiB (P40)** * **Reference quote:** **0.4800USD/hr** ### Google cloud No available TEE models ### Amazon cloud No available TEE models # Node Setup {% content-ref url="/pages/osIil0MJ0KAWCNxn2WGL" %} [DHC Node Setup](/user-guide/alpha-testnet/node-setup/dhc-node-setup) {% endcontent-ref %} {% content-ref url="/pages/HOMolkhB7uVlVfZklOft" %} [Case Study](/user-guide/alpha-testnet/node-setup/case-study) {% endcontent-ref %} # DHC Node Setup ### Create Wallet Account You can create a new wallet address directly within the browser plugin wallet like MetaMask and export the private key for later use. ### Remote SSH server login To log into the SSH server via the account password set when purchasing the server and the public IPv4 address automatically assigned to the instance by the cloud service provider. **Option 1.** The built-in system terminal: * For Mac systems and native Linux systems, you can use the built-in terminal simulator to log in. * For Windows systems, you can use the built-in PowerShell tool to log in. You need to run PowerShell as administrator and install the OpenSSH plugin. The plugin installation tutorial link is as [**Get started with OpenSSH for Windows**](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse?tabs=powershell) login Method: After opening the terminal, enter "ssh username\@public IP address" (e.g. ssh test\@1.1.1.1), then enter the password according to the prompt to complete the login. **Option 2.** The third-party SSH login tools: Third-party SSH login tools such as Xshell, PuTTY, SimpleRemote, Terminus, etc. You can refer to the relevant product tutorials to log in by yourself. **Option 3.** The built-in server method of cloud service: Different cloud service providers may provide their online server management consoles, through which you can log in graphically, such as logging in to EC2 instances on Amazon Web Services through the EC2 console page. Please refer to the help documents provided by each cloud service provider.

### Install runtime environment ```powershell # Install the Docker runtime environment sudo curl -fsSL https://get.docker.com | bash -s docker sudo systemctl enable docker sudo systemctl start docker # Check if the Docker service started correctly sudo systemctl status docker # Use "ctrl+c" to resume command status sudo chmod 666 /var/run/docker.sock docker version # Download the docker-compose program sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose # Install docker-compose sudo chmod +x /usr/local/bin/docker-compose docker-compose --version ``` ### Create a node storage directory and startup file {% hint style="success" %} Exposing the node's external IP is important to increase DHC's stability ``` --public-addr ... Public address that other nodes will use to connect to this node. This can be used if there's a proxy in front of this node. PUBLIC_ADDR example: "/ip4/8.8.8.8/tcp/30333" ``` {% endhint %} ```powershell # Create a node storage catalog mkdir -p bool-beta-testnode/node-data # Enter the node storage catalog cd bool-beta-testnode # Adjust user permissions chmod 777 node-data # Add a configuration file # You can also use "cat > docker-compose.yaml" first and then use "vim docker-compose.yaml" # Then paste the the remaining code between "< docker-compose.yaml < ports: - 9944:9944 - 30333:30333 EOF # Start the service docker-compose up -d ``` Synchronizing blocks will take more time, and we provide snapshots to speed up chain startup. Reference run a chain via snapshot. {% hint style="info" %} Some of the built-in terminals will recognize space characters as indent characters during code copying, which may lead to YAML program runtime errors. Please check and replace it. {% endhint %} ### Configure the sgx server ```powershell # Back to root catalog cd .. # Pull github repositories git clone https://github.com/boolnetwork/mining-scripts.git # Install the sgx driver apt update apt install build-essential automake autoconf libtool wget python libssl-dev dkms wget https://download.01.org/intel-sgx/latest/linux-latest/distro/ubuntu18.04-server/sgx_linux_x64_driver_1.41.bin bash sgx_linux_x64_driver_1.41.bin # View sgx status cd mining-scripts && ./sgx-detect ``` ### Modify keyring.toml configuration file Please check out the latest DHC bootnodes [**here**](/user-guide/beta-testnet/dhc-update) in advance and do the replacement if changed. {% hint style="info" %} **`external_multiaddrs:` Exposing the server's external IP is important, thereby increasing the reward.** ``` example: external_multiaddrs = ["/ip4/127.0.0.1/tcp/38700"] ``` {% endhint %} ```powershell # Enter the configuration mode of keyring.toml file vim configs/keyring.toml # Modify the file internally as follows: node_ws_url = "ws://127.0.0.1:9944" # import your wallet public address starting with "0x" and do the replacement device_owner = "0x0000000000000000000000000000000000000000" # database path db_path = "/host/data" # tokio console port console_port = 5555 #This corresponds to using an image, epid=1, dcap=2 attestation_style = 2 exe_policy = { Multiply = { executors = 8 } } # database start option [db_option] create_if_missing = true atomic_flush = true [network_config] port = 38700 boot_nodes =["/ip4/172.210.130.200/tcp/38701/p2p/12D3KooWQBrkBWb3tLoUpxqXebxg1Eab24LfcFP3hv37ZF2c6qgz","/ip4/20.81.161.179/tcp/38701/p2p/12D3KooWMDqap7HMjA6nos1HpHpWt8JBcPepnZgYSd5PPmovAqD7"] share_peer_interval = 30 only_global_ips = true protocol_id = "betatestnet" #external_multiaddrs = ["/ip4/127.0.0.1/tcp/38700"] ``` ### Modify sgx\_default\_qcnl.conf file {% hint style="warning" %} Try the local solution [**here** ](/user-guide/beta-testnet/node-setup/dhc-node-setup/local-lan-configuration-for-sgx)if you can't find the solutions for the cloud services below. {% endhint %} ```powershell # Enter the configuration mode of qcnl.conf file vim configs/sgx_default_qcnl.conf # Modify the file internally as follows: # Ali Cloud # [Region-ID] is the region of the server you purchased, like cn-hongkong and etc. # you can refer to https://help.aliyun.com/document_detail/140601.html { "pccs_url": "https://sgx-dcap-server.[Region-ID].aliyuncs.com/sgx/certification/v3/", "use_secure_cert": true, # To accept insecure HTTPS cert, set this option to FALSE "retry_times": 6, "retry_delay": 10, "pck_cache_expire_hours": 168 } # Tencent Cloud { "pccs_url": "https://sgx-dcap-server-tc.bj.tencent.cn/sgx/certification/v3/", "use_secure_cert": true, # To accept insecure HTTPS cert, set this option to FALSE "retry_times": 6, "retry_delay": 10, "pck_cache_expire_hours": 168, "verify_collateral_cache_expire_hours": 168 } # Microsoft Cloud { "pccs_url": "https://global.acccache.azure.net/sgx/certification/v3/", "use_secure_cert": true, # To accept insecure HTTPS cert, set this option to FALSE "retry_times": 6, "retry_delay": 10, "pck_cache_expire_hours": 168 } ``` ### Modify docker-compose file (Optional) You need to change the configuration here and replace the "\" underneath only when the official image version is updated, please refer to this link for the exact version information. {% hint style="info" %} Before changing version numbers, make sure your device is in Standby status, or not registered. Otherwise, you will be punished. {% endhint %} The latest version of the image is: [**v0.12.20**](https://github.com/boolnetwork/mining-scripts/blob/master/docker-compose.yml#L5) ```powershell # Enter the configuration mode vim docker-compose.yaml # Modify the file internally as follows: version: "3" services: bnk-occlum-keyring: image: boolnetwork/bnk-occlum-keyring-dcap: restart: always network_mode: "host" environment: RUST_LOG: info,p2p_net=debug volumes: - ./configs:/configs - ./data:/root/occlum_instance/data - ./configs/sgx_default_qcnl.conf:/etc/sgx_default_qcnl.conf devices: - /dev/sgx/enclave:/dev/sgx/enclave - /dev/sgx/provision:/dev/sgx/provision command: bash -c 'cp /configs/keyring.toml /root/occlum_instance; apt update;apt install curl -y;source /root/.bashrc; cd /root/occlum_instance; occlum print mrsigner; occlum print mrenclave; occlum run /bin/bnk-watcher run /host/keyring.toml' ``` ### Start DHC Node Service ```powershell # Start DHC node service docker-compose up -d # View node service Logs docker-compose logs --tail 200 -f # Check P2P connection Logs docker-compose logs --tail 200 -f |grep 'Current peers' ``` ### Update Device Version Please maintain your image of the DHC server by updating it with the latest official version. You can follow this step by step: #### 1. Exit the service Device upgrades must be performed on "**Standby"** status. If the device is on "Serving" status, it must be exited before starting the upgrade. If the device is on "Exiting" status, wait up to one day until the process is complete before proceeding. #### 2. Update the script file ```powershell # Shut down the script and back up your data docker-compose down && mv data/ data-bak/ # Replace the image version of the device # 0.12.x is your current version and 0.12.0 is the latest version sed -ri 's/0.12.x/0.12.20/g' docker-compose.yaml # Restart the service docker-compose up -d ``` Then check out the version of your device on the [**Node Explorer**](https://dhc.boolscan.com/beta_testnet/).

#### 3. Rejoin the service You can join the service again after all the steps above are done and wait until the device changes to "Serving" status. #### 4. Remove backup data (Optional) ``` rm -rf data-bak/ ``` ### Case Study If you're facing problems in the setup process, try to find a solution [**here**](/user-guide/beta-testnet/node-setup/case-study). # Local LAN Configuration for SGX To realize local LAN Configuration for SGX, you need to start a local LAN PCCS service locally or on the LAN, and then change the `pccs_url` in the `sgx_default_qcnl.conf` file on all local DHC nodes to the local LAN PCCS link (for example, if the PCCS service is deployed on `host1`, then it should be "pccs\_url": ""). You may refer to the steps for more details: ### Applying for an Intel API Key You'll need to acquire an Intel API key to utilize Intel's Software Development Kit (SDK) for Intel SGX (Software Guard Extensions). This key grants you access to Intel's resources and enables you to develop and deploy SGX-based applications. **Steps:** 1. **Create an Intel Developer Zone Account:** If you don't already have one, create an account on the Intel Developer Zone website. 2. **Navigate to the Intel API Key Management Page:** Once logged in, go to the Intel API Key Management page. 3. **Select the "Intel SGX SDK" Product:** Choose the "Intel SGX SDK" product from the list of available products. 4. **Provide Required Information:** Fill out the requested information, including your name, organization, and project details. 5. **Submit the Request:** Review the information you've provided and submit the request. Intel will evaluate your request and notify you of the outcome. {% embed url="" %}

### Installing a Local LAN PCCS Service ```powershell curl -fsSL https://download.01.org/intel-sgx/sgx_repo/ubuntu/intel-sgx-deb.key | sudo apt-key add - sudo add-apt-repository "deb [arch=amd64] https://download.01.org/intel-sgx/sgx_repo/ubuntu $(lsb_release -cs) main" sudo curl -sL https://deb.nodesource.com/setup_16.x | sudo bash - sudo apt-get install -y nodejs sudo apt install cracklib-runtime -y sudo apt-get install sgx-dcap-pccs libsgx-dcap-default-qpl ```

During the installation process, enter the API key you applied for earlier, and set a password for PCCS. Here, we will use "pccs12345678" as an example.

Once you have completed the above steps, you can skip the remaining steps by simply pressing the Enter key.

The above steps indicate that the PCCS service installation is complete. However, upon restarting the service, the following error message is encountered:

#### Solution: Step 1. Install the register tool for SGX ```powershell sudo apt install sgx-pck-id-retrieval-tool ``` Step 2. Modify the configuration file ``` cat /opt/intel/sgx-pck-id-retrieval-tool/network_setting.conf ``` PCCS\_URL=

Step 3. Use the PCK ID Retrieval Tool ``` PCKIDRetrievalTool ```

``` systemctl status pccs ```

Step 4. Enable the SGX function If the error message persists, you may need to reseat the motherboard battery, reset the machine's BIOS, and re-enable the SGX feature, as shown in the following image:

Step 5. Run the PCK ID Retrieval Tool Keep running the tool until the registration has been done.

Step 6. Start the DHC node processes Once SGX registration is successful, you can start the DHC node processes. However, due to data caching, you may encounter the following error message upon the first attempt:

Try more attempts until the registration has been done.

# Run a chain via snapshot ## Workflow of running a chain node * Download snapshot ``` wget https://github.com/ipfs/kubo/releases/download/v0.29.0/kubo_v0.29.0_linux-amd64.tar.gz tar -xzvf kubo_v0.29.0_linux-amd64.tar.gz cd kubo/ sudo install -C ipfs /usr/local/bin/ ipfs init nohup ipfs daemon >> ipfs.log & ipfs get QmarXGUefS13Kve52iLraMwP2VHU93yzkB8Lj8z8yhPLqw ``` * Replace data `QmarXGUefS13Kve52iLraMwP2VHU93yzkB8Lj8z8yhPLqw` has been downloaded. Unzip the `node-data.tar.gz` to the specified chain node data directory, replace the original data directory node-data, and then restart the chain service node. Assume that your link node data directory is `~/bool-beta-testnode` ``` mv ~/bool-beta-testnode/node-data ~/bool-beta-testnode/node-data_old tar -zxvf kubo/QmarXGUefS13Kve52iLraMwP2VHU93yzkB8Lj8z8yhPLqw/node-data.tar.gz -C ~/bool-beta-testnode/ ``` * (Optional) Modify docker-compose.yaml Modify the node's docker-compose.yaml configuration to remove `--state-pruning archive` and `--block-pruning archive` ``` sed -i '/--state-pruning archive/d;/--blocks-pruning archive/d' docker-compose.yaml ``` * Start the chain service node ``` docker-compose up -d ``` # Case Study ### Case 1

```jsx git clone https://github.com/occlum/enable_rdfsbase.git cd enable_rdfsbase make && make install #if still error，remake && reinstall ``` ### Case 2

* Mirror is incorrect. * Curl is not installed in the container. ### Case 3

* Install curl within the container. * Missing sgx\_default\_gcnl.conf or sgx\_default\_qcnl.conf file ### Case 4

* Mirror version is not correct, please check the mirror ID. * Wrong version ### Case 5

Mirroring is wrong, this time apply epid mirroring on Azure. ### Case 6

Configuration file error, private key length is not correct. ### Case 7

Check current configuration of max\_map\_count: `cat /proc/sys/vm/max_map_count` Not persistent way to modify the max\_map\_count: `sysctl -w vm.max_map_count=3097152` To make the changes persistent you should modify `/etc/sysctl.conf` and then (optionally) execute `sysctl -p` to apply the changes without reboot ``` echo "vm.max_map_count=3097152" >> /etc/sysctl.conf sysctl -p ``` ### Case 8

If you are using the v0.11.9 image version of DHC, the Linux kernel version of the Operating System must be greater than 6.2. Another option is to reinstall the operating system, using at least 22.04 Ubuntu version. ### Case9

If the "current peers" is **0**, it means your device can not be connected through the P2P network. You should check the internet connection and the public IP first. Then you should check the security configuration of the cloud service which you can refer to the official docs for help. ### Case 10

For images with versions greater than `v0.12.8`, you need to add the `run` command to the startup command line, for example `occlum run /bin/bnk-watcher run /host/keyring.toml`. # Node Management For DHC node, there are two type of roles which called "Owner" and "Voter". * Owner is the person running the node, which can be the project owner, KOL, community leader, etc. * Voter is the person who delegates his/her tBOL to the node for farming tBOL staking rewards. User can choose to be a node owner or a node voter or both. {% content-ref url="/pages/kZwgRJ0bDMwvFp2SBrtk" %} [For DHC Voter](/user-guide/beta-testnet/node-management/for-dhc-voter) {% endcontent-ref %} {% content-ref url="/pages/BYV0UANUB84zoZCQuZhZ" %} [For DHC Owner](/user-guide/beta-testnet/node-management/for-dhc-owner) {% endcontent-ref %} # For DHC Voter Any tBOL holders can participate in the voting progress of DHC nodes to share the staking rewards by delegating their tBOL.

### Vote Nodes Click on the "Vote" button on the right of the statistics cards, select the DHC nodes that need to participate (single selection only), input the quantity of tBOL delegating on the node, and submit a voting transaction. Please be aware of the voting limits below. * The maximum quantity for a single DHC node is **3000 voters** * The minimum voting quantity of each DHC node is **200 tBOL** Note: Only the DHC nodes selected on-chain as the committee nodes will receive the era income and the voters will receive tBOL rewards depending on their staking rate. Choose wisely if you want to farm the maximum return from your staking. Here are some useful tips for you: * "Standby": Consider it as a community support option. * "Service": It is a wise option for all new voters as you can start farming ASAP from the next rewards era. * "Exiting": Forget about it. It is a bad option if you are not an Owner.

### Change Staking Click the "Update" button on the list, then change the staking amount down or up depending on your needs and submit a transaction on chain. Click the "Unstake All" button to unstake all your staking amount from the node.

Note: the changes will only take effect on-chain until the next era. Please be patient for waiting up to about **60 minutes** if you choose to raise the staking amount. However, if you choose to reduce the staking amount, you should to claim it manually after **24 hours**. ### Rewards Distribution In each reward era, the staking rewards will be given automatically to the wallet address, depending on the share percentage of the total staking. # For DHC Owner

### View Devices After completing the configuration with the cloud server, you can use the [**node client**](https://dhc.boolscan.com/beta_testnet/) to configure your device. The system will automatically show the device of the corresponding cloud server according to the connected wallet address (tBOL is required as the gas). The default status is "Standby". ### Stake Node Option 1. Click the "Launch" button in the device's menu and the system will automatically calculate the remaining tBOL to meet the requirement for the DHC node. Option 2. Click the "Vote" button to vote 20000 tBOL for the node you own. Option 3. Click the "Vote" button to start with 10000 tBOL and wait for other voters to join the crowdfunding progress until 100%. Please be aware of the node limits below. * The minimum staking for a DHC Owner is **10000 tBOL** * The minimum requirement for a DHC node to join the service is **20000 tBOL** ### Join Service When the node staking threshold is met, the node service of the current device can be formally activated by clicking the "Join Service" button in the device's menu. Then the device will turn into the "Service" status, which means it has joined the DHC service network. Note: the image version of the device must be the [**latest**](https://github.com/boolnetwork/mining-scripts/blob/master/docker-compose.yml) or the device will not be able to join service. ### Checkout Rewards If the node operates without anomalies such as disconnections, the node rewards will be released automatically at the end of every reward era. You can check out the total rewards on the statistics cards and the device rewards from the device list respectively. Note: The reward distribution ERA of DHC nodes is **1,200 blocks**, about **60 minutes**. ### Manage Device Users can perform the administrative operations such as: * "Launch": do a quick staking to meet the minimum requirement of the device for the owner; * "Join Service": join the current device to the DHC service network. Please note that your device must be updated to the latest version or it may fail to join the service. The button will be displayed when the minimum requirement for a DHC node to join the service is done; * "Update Commission": change the commission rate. The higher the rate is, the more rewards will be distributed to the owner's address; * "Refuse New Voters": stop receiving the stakings from new voters; * "Allow New Voters": allow receiving the stakings from new voters; * "Remove Device Voters": remove the voters from the current ; * "Exit Service": apply to exit the current device from the DHC service network. The button is only displayed in the "service" status; * "Remove Device": shun down the device from the DHC lists in any status. Here are the consequences:\ 1\. **1000 tBOL** will be charged as the punishment which will be deducted from the owner's staking shares if you perform in the status of "Service" or "Exiting" as a force quit.\ 2\. All the staking of tBOL will be returned to the voters' wallet address.\ 3\. The current device will be removed from the DHC device lists.\ 4\. All the node income of the current era collected on-chain will be **burned directly as a punishment**. Note: The operations like "Launch", "Update Commission" and "Remove Device Voters" above need to wait until the next rewards era to be activated. ### Stop Service Please follow the following steps one by one if you want to stop the node service: 1. The owner can exit the DHC network by **"Exit service"** to change the device status to "Exiting" **without penalty** or perform a forced quit directly by **"Remove Device" with a forced quit penalty** to get the refund immediately. 2. If you choose to exit without penalty, you will need to wait up to **one day** which is 144 heartbeat circles to complete the exiting process and the device status will be changed to "Standby". 3. Click the **"Remove Device"** button to remove your device and get your tBOL refund from the current device. Removing the device with **"Standby"** status **will not incur a penalty**. 4. Shut down the physical device or the cloud server when all the above actions are completed. You can log in to the cloud service client like Microsoft Cloud and delete the virtual machine you purchased to prevent the cloud service provider from deducting fees. ### The Punishment Here are some important rules for the owner: * Disconnect Penalty: The device is required to keep the heartbeat connections per heartbeat cycle which lasts **10 mins**. The failure of disconnection for more than **2 heartbeat cycles** will result in a penalty of **10 tBOL** per heartbeat cycle. The penalty will be only charged to **the owner**. * Forced Quit Penalty: **1000 tBOL** will be charged as the forced quit penalty when the owner decides to perform "Remove Device". The penalty will be only charged to **the owner**. * Automatic Exit: The system will auto-perform "Exit Service" for the devices that disconnect for more than **10 heartbeat cycles**. There will only be a penalty for not submitting a heartbeat connection. However, the device with the exiting status still needs to submit heartbeat connections. # Alpha Testnet #### For normal users, you can start from here： {% content-ref url="/pages/4rekQtP61aaHooIbdhrH" %} [Getting Started](/user-guide/alpha-testnet/getting-started) {% endcontent-ref %} {% content-ref url="/pages/Zy7A1dGyIqRFZqDDrBIm" %} [Network Information](/user-guide/alpha-testnet/network-information) {% endcontent-ref %} {% content-ref url="/pages/NJ0WqyeHInKMBkUFwnkQ" %} [Wallet Setup](/user-guide/alpha-testnet/wallet-setup) {% endcontent-ref %} #### For node participants, you will need to know: {% content-ref url="/pages/bq4dI9VixG3j6BAQx4kW" %} [Node Server](/user-guide/alpha-testnet/node-server) {% endcontent-ref %} {% content-ref url="/pages/EDe46426TN2VIU1wncBC" %} [Node Setup](/user-guide/alpha-testnet/node-setup) {% endcontent-ref %} {% content-ref url="/pages/zfFFUnSfoggGNLEWg4ar" %} [Node Management](/user-guide/alpha-testnet/node-management) {% endcontent-ref %} # Getting Started Welcome to Bool Network! This guide will help you to kickstart your journey on this EVM-compatible network. ### Overview There are the key steps to familiarize yourself with **Alpha Testnet**: 1. [**Network Information**](/user-guide/alpha-testnet/network-information)**:** Understand the basics of Bool Network - its compatibility, and the parameters of the Testnet for interaction. 2. [**Wallet Setup**](/user-guide/alpha-testnet/wallet-setup)**:** Set up your MetaMask wallet to handle tBOL/BOL on Bool Chain. ### Node Related 1. [**Node server**](/user-guide/alpha-testnet/node-server): The advise for purchasing the device machine which is suitable for running the node sevice. 2. [**Node setup**](/user-guide/alpha-testnet/node-setup): How to set up the code program of node sevice step by step. 3. [**Node management**](/user-guide/alpha-testnet/node-management): How to run your own node sevice by using the node client or join the others' nodes and claim your rewards. ### Useful Links * Explorer： Blockchain Explorer: Bridge Explorer: Oracle Explorer： Node Explorer： * Doc： White paper: Yellow paper: GitHub: Developer： ### About Refund When the test phase is over, we will arrange a form to collect the application of prepaid USDT Refunding for the participant who participated in Alpha-testnet. * The tBOL need to be returned in the original way. * USDT and tBOL are equal in and out, how much was prepaid will be refunded according to the original ratio. * The rewards collected from node income will not be involved in the return of USDT, but it can deduct the penalty. * If the node has incentive and penalty events and penalties > revenues, then the corresponding proportion to be refunded to be deducted from USDT, and if not there will be no effect. # Network Information | Variable | Value | | ----------------------------- | ---------------------------------------------- | | Network name | Bool Alpha Testnet | | RPC URL (http) | | | RPC URL (wss) | wss\://alphatest-rpc-node-ws.bool.network | | Chain ID | `480` | | Currency symbol | `tBOL` | | Block explorer URL (optional) | | # Wallet Setup To interact with Bool Network and manage tBOL on this network, setting up a MetaMask wallet is essential. Follow these steps to configure MetaMask for Bool Network: #### Installing MetaMask Install the [MetaMask](https://metamask.io/) browser extension or mobile app if you haven't already. #### Wallet Import or Creation Import existing Ethereum wallets into MetaMask or create new wallets specifically for managing tBOL on Bool Network. #### Network Configuration Configure MetaMask to interact with the Bool Network. Add the network [details](/user-guide/alpha-testnet/network-information), including the RPC endpoints and chain ID, to enable seamless communication. # Node Server {% content-ref url="/pages/HXfrS6HayClpg5bNW1Hq" %} [Recommend List](/user-guide/alpha-testnet/node-server/recommend-list) {% endcontent-ref %} {% content-ref url="/pages/JSRnjhoza7a1wgsYbpkk" %} [Purchase Guide](/user-guide/alpha-testnet/node-server/purchase-guide) {% endcontent-ref %} # Recommend List {% content-ref url="/pages/yYzVDOP9OWscEiIPUOBE" %} [DHC Server](/user-guide/alpha-testnet/node-server/recommend-list/dhc-server) {% endcontent-ref %} # DHC Server {% hint style="danger" %} NOTE that DHC nodes **MUST support Intel® SGX2** (TEE hardware). {% endhint %} ### Basic Requirements * Operating system: Ubuntu 18.04 * CPU: 8 Cores and support SGX2 * Memory: 32GB RAM * Storage: 2TB SSD * Network: Individual IP + 20M network bandwidth ### Recommend List #### Physical Machine * CPU: 16 Cores (Intel Xeon Ice Lake) * Memory: 64GB DDR4 * Storage Disk: 2TB SSD * System Disk: 480GB SSD * Network: Gigabit Ethernet #### Cloud Service * AliCloud: g7t, c7t, r7t * Tencent Cloud: M6ce * Microsoft Cloud: DCsv3, DCdsv3 ### Deployment Options #### Physical Machine * CPU: Intel Xeon Silver 4309Y(8C) \* 2 * RAM: 32GB DDR4 \* 2 * HD: 480GB SSD \* 2 (System) + 1.92T SSD \* 1 (Storage) * Network: Gigabit Ethernet \* 2 #### Cloud Service * AliCloud: g7t * CPU: 8vCPU * RAM: 32G * HD: 2T HDD * Network: 20M # Validator Server ### Basic Requirement： * OS：Ubuntu 18.04 or Linux Kernel 5.16 * CPU：4 Cores * RAM：16GB RAM * Hard drive：1TB SSD/HHD * Bandwidth：Individual IP + 20M network bandwidth ### Deployment Options #### Cloud service All cloud server providers are supported, only the configuration requirements need to be met. AliCloud (Hong Kong): 4vCPU, 16G, 1T HDD, 20M Quote (pay per volume): $350/month + $0.1428/GB Quote (yearly and monthly package): $490/month # Purchase Guide {% content-ref url="/pages/FZWeNRSlTDJanNJpwNGE" %} [DHC Server](/user-guide/alpha-testnet/node-server/purchase-guide/dhc-server) {% endcontent-ref %} # DHC Server ### AliCloud * **Purchase Links:** [**https://ecs-buy.aliyun.com/**](https://ecs-buy.aliyun.com/) * **Buyer's Guide:** Note: The ecs.g7t series, ecs.c7t series, and ecs.r7t series all support Intel® SGX2. {% embed url="" %} * **Configuration Reference:** Payment Type: **Yearly & Monthly | Volume Based Payment** Territory: **China (HONG KONG)** Instance: **Security Enhanced g7t，ecs.g7t.xlarge，8vCPU 32GiB** Mirror: **Ubuntu 18.04 64-bit UEFI Edition** System Disk: **ESSD cloud disk 2048GiB** Public IP address：**Assign public IPv4 addresses** Bandwidth billing model: **by fixed bandwidth** Bandwidth：**20Mbps** Management Settings: **Password** * **Reference quote:** **￥5231.2/month | ￥6.855/hour + ￥1.000/GB** ### Tencent cloud * **Purchase Links:** [**https://buy.cloud.tencent.com/cvm**](https://buy.cloud.tencent.com/cvm) * **Buyer's Guide:** Note: The Security Enhanced Memory M6ce supports Intel® SGX2 and is only in stock in Shanghai and Beijing. {% embed url="" %} * **Configuration Reference:** Configuration mode: **Customized** Billing Mode: **Yearly and Monthly | Volume Based Billing** Region: **China - Hong Kong, China** Instance: **M6Ce.2XLARGE64 (Security Enhanced Memory Type M6ce, 8-core 64GB)** System: **Ubuntu Server 20.04 LTS 64-Bit** Storage: **Universal SSD Cloud Drive - 2048GiB** Bandwidth: **20Mbps** Login: **Password (self-set)** * **Reference quote:** **4Core32GB：￥3187.54/month | ￥3.41/hour + ￥0.80/GB** ### Microsoft cloud * **Purchase Links:** [**https://portal.azure.com/#create/Microsoft.VirtualMachine-ARM**](https://portal.azure.com/#create/Microsoft.VirtualMachine-ARM) * **Buyer's Guide:** Note: The **DCsv3** series and **DCdsv3** series support Intel® SGX2 in the following regions: Central Canada, Eastern United States, Eastern United States2, Western United States, Western United States2, Central United States, South Central United States, Northern Europe, Western Europe, Eastern Japan, Western Japan, Northern Switzerland, Southeast Asia, Northern Italy, Central India, and Southern United Kingdom. {% embed url="" %} * **Configuration Reference:** Virtual Machine Name: **Set it up yourself** Region: **(Asia Pacific) Southeast Asia** Image: **Ubuntu Server 20.04 LTS - x64 Gen2** Size: **Standard DC4s\_v3-4 vcpus, 32 GiB RAM (US$350.40/month)** Authentication Type: **Password** Username: **Set by yourself** Password: **Self-set** OS Disk Size: **2TiB (P40)** * **Reference quote:** **0.4800USD/hr** ### Google cloud No available TEE models ### Amazon cloud No available TEE models # Validator Server Region: **China - Hong Kong, China** Instance: **S2.LARGE16 (Standard S2 with 4 cores and 16GB**) System: **Ubuntu Server 20.04 LTS 64-bit** Storage: **Universal SSD Cloud Drive - 1024GiB** Bandwidth: **20Mbps** Login: **Password (self-set)** * **Reference quote:** **¥2805.88/month | ¥2.67/hour + ¥0.67/GB** #### Microsoft cloud * **Purchase Links:** [**https://portal.azure.com/#create/Microsoft.VirtualMachine-ARM**](https://portal.azure.com/#create/Microsoft.VirtualMachine-ARM) * **Configuration Reference:** Virtual Machine Name: **Set it up yourself** Region: **(Asia Pacific) East Asia** System: **Ubuntu Server 20.04 LTS - x64 Gen2** Size: **Standard D4s\_v3-4 vcpu, 16 GiB RAM (US$192.72/month)** Authentication Type: **Password** Username: **Set by yourself** Password: **Self-set** OS Disk Size: **1 TiB (P30)** * **Reference quote:** **0.2640USD/hr** ### Google cloud * **Purchase Links:** [**https://console.cloud.google.com/compute/**](https://console.cloud.google.com/compute/) * **Configuration Reference:** Region：**asia-east2(HONG KONG)** Machine type：**e2-standard-4 (4vCPU，2Core，16 GB RAM)** Boot Disk： OS：**Ubuntu** Version：**Ubuntu 20.04 LTS** Size：**1024** * **Reference quote:** **$249.53/month** ### Amazon cloud * **Purchase Links:** [**https://ap-east-1.console.aws.amazon.com/ec2/**](https://ap-east-1.console.aws.amazon.com/ec2/) * **Configuration Reference:** Region：**Asia-Pacific (Hong Kong) ap-east-1** Name：**Set by yourself** System：**Ubuntu Server 22.04 LTS (HVM), SSD Volume Type** Instance Type：**t3.xlarge (t3 4vCPU 16GiB)** Key Pair: **Create New Key Pair → Enter Name → Default Value to Create** Configuration Storage：**1024GiB** * **Reference quote:** **0.2336USD/hr** # Node Setup {% content-ref url="/pages/osIil0MJ0KAWCNxn2WGL" %} [DHC Node Setup](/user-guide/alpha-testnet/node-setup/dhc-node-setup) {% endcontent-ref %} {% content-ref url="/pages/HOMolkhB7uVlVfZklOft" %} [Case Study](/user-guide/alpha-testnet/node-setup/case-study) {% endcontent-ref %} # Validator Node Setup ## Node Configuration ### SSH terminal login If the original terminal is occupied by the node data synchronization process, you need to open a new terminal tool separately to enter commands. You can also use "ctrl+c" to pause the current log refresh and return to the command entry state. ### Get Docker Information ```powershell # check out the docker service sudo systemctl status docker # get docker container ID docker ps -a | grep bnk-node | awk '{print $1}' ``` Code execution results as: 8b0672d97140 ### Get node key ```powershell # Enter the docker development environment ( needs to be replaced in its entirety with the container ID above, including the <>) docker exec -it bash # Generate RotateKeys curl -X POST http://127.0.0.1:9944 -H "Content-type: application/json" -d '{"id":1,"jsonrpc":"2.0","method":"author_rotateKeys","params":[]}' ``` \ Code execution results as:{"jsonrpc":"2.0","result":"0x963d40e26c1d69acf3f75f96cd7782576382713b650d2ea81f5c8dbeb3797e1f17df3a8ab0d3a2dc3218972fdebe47a4463523ae1bbc0a6c91f3b33ace76c0eb","id":1} \ Please save the results of the "result" value after the run, here for your node rotateKeys, the subsequent configuration will be used. ### Node client login Open the [**node client**](https://dashboard.boolscan.com/node?network=alpha_testnet) interface and select the browser plugin wallet to connect. Must use the EVM address which has received tBOL. ## Apply Validator ### Prerequisite * Run at least one DHC/validator node server * Holding tBOL >= 20000 ### Become a Node Validator After users have completed node deployment, they need to configure the node authenticator information (bind the wallet management address to the node key) . Click the "Become a Validator" button on the card on the right side of the page to enter the configuration pop-up window. The form fields are described below: * Fee: the percentage of the management fee set by the validator. The smaller the value, the higher share of rewards that can be distributed to nominator. As it is an open network, a low fee rate will facilitate more tBOL holders to participate in the node rewards distribution; * Allows new nominator: whether or not to enable the nominator mode. When the mode is enabled, it allows others to join as a nominator. Then the final rewards will be distributed according to the proportion of all participating tBOL staked; * RotateKeys: the node keys used to bind the admin wallet address to the current node; * taking Amount: the number of tokens pledged, the number of tokens used by the current block node to pledge in the BOOL network. Note that a single pledge must be greater than or equal to **20000 tBOL;** * Income Distribution: the mode of income distribution, divided into two modes: continue to stake and directly withdraw. Then the statistics dashboard and the management buttons will be displayed on the page. As shown in the figure below, after the validator node is added, you can directly view your node information on the blockchain browser. [**Bool Chain Explorer - Alpha Testnet Validators**](https://alpha-testnet.boolscan.com/validators)
Note: Newly added nodes are initially in a "waiting" status, and need to wait until the end of the current reward era (half an hour) before they can join the chain service. The nodes that have been successfully elected by the chain system will be able to farm the node income.

### Receive rewards When the node is successfully selected and participates in the block recording, the system will release tBOL income at the end of each reward era. At this time, you can check the gained rewards in the dashboard of the node client and claimthe rewards to the associated admin wallet through the "Claim Rewards" button. \ Note: As the current era rewards of validator node will expire after **84 Eras** (42 hours), so it is important for node owners to claim the unpaid rewards in time!

### Validator Configuration Node-related configuration parameters can be freely adjusted according to the actual demand scenario. * Stop: exit the node candidate state. It will be used when you need to exit the node service or change the admin address; * Add Stake: increase the amount of staking. The rewards of each node will be distributed according to the staking ratio; * Reduce Stake: reduce the amount of tokens staked. The reward for each node will be distributed according to the staking ratio; * Claim Reward: withdraw the node rewards. Only the unpaid rewards can be withdrawn; * Distribution Mode: Adjust the revenue distribution mode, can be switched to "Rewards Restake" or "Direct Withdraw" mode; * Redeem: unstake tBOL. You can only redeem the tokens that have been unlocked; * Change Key: used when replacing the device server. Note that you need to exit the node candidate status first. ## Apply Nominator ### Prerequisite * Holding tBOL >= 100 ### Become a Node Nominator The tBOL holders who are unable to deploy a VALIDATOR node on their own can also choose to become a nominator to farm tBOL by joining an existing node service. You can click the "Become a Nominator" button on the left side of the page to enter the configuration pop-up window, select the online nodes you want to join, and stake more than **100 tBOL** to the selected nodes. \ \ Note: If you choose to participate in multi-node staking at the same time, the system will dynamically allocate the current staking amount for each participating node according to the intelligent algorithm in order to maximize the stakubg yield. Each nominator can join up to **16 nodes**.

### Receive rewards When the node is successfully selected, the system will release node income at the end of each reward era. You can check the gained rewards in the node dashboard and withdraw the rewards to the associated wallet through the "Claim Rewards" button. ### Nominator Configuration Node-related configuration parameters can be freely adjusted according to the actual demand scenario. * Stop: exit the farming state. It will be used when you need to exit the node service; * Add Stake: increase the amount of staking. The rewards of each node will be distributed according to the staking ratio; * Reduce Stake: reduce the amount of tokens staked. The reward for each node will be distributed according to the staking ratio; * Claim Reward: withdraw the node rewards. Only the unpaid rewards can be withdrawn; * Distribution Mode: Adjust the revenue distribution mode, can be switched to "Rewards Restake" or "Direct Withdraw" mode; * Redeem: unstake tBOL. You can only redeem the tokens that have been unlocked;

## Node Exit ### Stop Block Service Login the node client system and connect to the admin wallet, then click the "Stop" button on the right and send a transaction to stop the service of the current node. The node status will change to "Stop", and it will be removed from the node enrollment list corresponding to the next round of reward era. If the current node has already been selected as a blocking node in the ongoing era, the current round of reward will not be affected. Note that the connection of cloud server must be online all the time, or the node will be penalized.

### Redeem tBOL After confirming that the node status is stopped, you need to unstake tBOL by using "Reduce Stake" button. After the transaction is completed, the node will enter the frozen state first, and then it needs to wait for the end of the current reward era before it transitions to the releasable state for unlocking. Then you can send an on-chain transaction via the "Redeem" button to release all the tBOL to the wallet. ### Shut down cloud servers When the actions above are completed, you can shut down the virtual machine previously purchased to avoid the cloud service provider to continue to deduct fees. # DHC Node Setup ### Create Wallet Account You can create a new wallet address directly within the browser plugin wallet like MetaMask and export the private key for later use. ### Remote SSH server login To log into the SSH server via the account password set when purchasing the server and the public IPv4 address automatically assigned to the instance by the cloud service provider. **Option 1.** the built-in system terminal: * For Mac systems and native Linux systems, you can use the built-in terminal simulator to log in. * For Windows systems, you can use the built-in PowerShell tool to log in. You need to run PowerShell as administrator and install the OpenSSH plugin. The plugin installation tutorial link is as [**Get started with OpenSSH for Windows**](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse?tabs=powershell) login Method: After opening the terminal, enter "ssh username\@public IP address" (e.g. ssh test\@1.1.1.1), then enter the password according to the prompt to complete the login. **Option 2.** the third-party SSH login tools: Third-party SSH login tools such as Xshell, PuTTY, SimpleRemote, Terminus, etc. You can refer to the relevant product tutorials to log in by yourself. **Option 3.** the built-in server method of cloud service: Different cloud service providers may provide their own online server management consoles, through which you can log in graphically, such as logging in to EC2 instances on Amazon Web Services through the EC2 console page. Please refer to the help documents provided by each cloud service provider.

# Create a Node Storage Catalog
mkdir -p bool-testnode/node-data

# Enter the node storage catalog
cd bool-testnode 

# Adjust user permissions
chmod 777 node-data

# Add a Configuration File
# You can also use "cat > docker-compose.yaml" first and then use "vim docker-compose.yaml" 
# Then paste the the remaining code between "<<EOF" and "EOF" and do save it.
cat > docker-compose.yaml <<EOF
version: "3"
services:
  bnk-node1:
    image: boolnetwork/bnk-node:alpha-testnet
    restart: always
    environment:
      RUST_LOG: info
    volumes:
    - "./node-data:/data"
    command: |
      --validator
      --enable-offchain-indexing true
      --rpc-methods Unsafe
      --unsafe-rpc-external
      --rpc-cors all
      --rpc-max-connections 100000
      --pool-limit 100000
      --pool-kbytes 2048000
      --tx-ban-seconds 600
      --ethapi=debug,trace,txpool
      --chain alpha_testnet
    ports:
      - 9944:9944
      - 30333:30333
EOF

# Start the service
docker-compose up -d

Note: Some hosting service providers' built-in terminals will recognize space characters as indent characters during code copying, which may lead to YAML program runtime errors. Please check and replace. ### Configure the sgx server ```powershell # Pull github repositories git clone https://github.com/boolnetwork/mining-scripts.git # Install the sgx driver apt update apt install build-essential automake autoconf libtool wget python libssl-dev dkms wget https://download.01.org/intel-sgx/latest/linux-latest/distro/ubuntu18.04-server/sgx_linux_x64_driver_1.41.bin bash sgx_linux_x64_driver_1.41.bin # View sgx status cd mining-scripts && ./sgx-detect # Initialize the account, the account information needs to be saved, will be used subsequently docker run -it --rm boolnetwork/bnk-node:release identity generate ``` ### Modify keyring.toml configuration file Please checkout the latest DHC bootnodes [**here**](/user-guide/alpha-testnet/node-setup/dhc-node-setup/dhc-bootnode) in advance and do the replacement if changed. Be aware of that **identity = "0x" + "private key"** and the total length must be **66.**

# Enter the configuration mode of keyring.toml file
vim configs/keyring.toml

# Modify the file internally as follows:
node_ws_url = "ws://127.0.0.1:9944"
# local node_call server port.
node_call_port = 8720
# used to generate LocalKeyStore, used to get AccountId in substrate.
# import your privatekey from wallet like MetaMask and do the replacement
# Note that the first two digits must be started with "0x" and then the private key
identity = "0x0000000000000000000000000000000000000000000000000000000000000000"
# database path
db_path = "/host/data"
# tokio console port
console_port = 5555

# database start option
[db_option]
create_if_missing = true
atomic_flush = true

[network_config]
port = 38700
boot_nodes = ["/ip4/172.210.130.200/tcp/38700/p2p/12D3KooWJVjkr19spLuvmWb68zdxki2qucnubPzbHRjxRi8jhwzF"]
share_peer_interval = 30
only_global_ips = true

[key_server_config]
# Pay attention to this place, the first startup may need to be changed to 0, otherwise there will be an error can not get up!
version = 1
attestation_style = 2 #This corresponds to using an image, epid=1, dcap=2
seal_policy = "MRSIGNER"
exe_policy = { Multiply = { executors = 8 } }
round_time_limit = 60
clear_msg_interval = 180

### Modify sgx\_default\_qcnl.conf file Choose wisely with your cloud service provider and make the change. ```powershell # Enter the configuration mode of qcnl.conf file vim configs/sgx_default_qcnl.conf # Modify the file internally as follows: # Ali Cloud # [Region-ID] is the region of the server you purchased, like cn-hongkong and etc. # you can refer to https://help.aliyun.com/document_detail/140601.html { "pccs_url": "https://sgx-dcap-server.[Region-ID].aliyuncs.com/sgx/certification/v3/", "use_secure_cert": true, # To accept insecure HTTPS cert, set this option to FALSE "retry_times": 6, "retry_delay": 10, "pck_cache_expire_hours": 168 } # Tencent Cloud { "pccs_url": "https://sgx-dcap-server-tc.bj.tencent.cn/sgx/certification/v3/", "use_secure_cert": true, # To accept insecure HTTPS cert, set this option to FALSE "retry_times": 6, "retry_delay": 10, "pck_cache_expire_hours": 168, "verify_collateral_cache_expire_hours": 168 } # Microsoft Cloud { "pccs_url": "https://global.acccache.azure.net/sgx/certification/v3/", "use_secure_cert": true, # To accept insecure HTTPS cert, set this option to FALSE "retry_times": 6, "retry_delay": 10, "pck_cache_expire_hours": 168 } ``` ### Modify docker-compose file (Optional) You need to change the configuration here and replace the "\" underneath only when the official mirror version is updated, please refer to this link for the exact version information. The latest version of the mirror is:[ **v0.6.6**](https://github.com/boolnetwork/mining-scripts/blob/master/docker-compose.yml) ```powershell # Enter the configuration mode vim docker-compose.yaml # Modify the file internally as follows: version: "3" services: bnk-occlum-keyring: image: boolnetwork/bnk-occlum-keyring-dcap: restart: always network_mode: "host" environment: RUST_LOG: info volumes: - ./configs:/configs - ./data:/root/occlum_instance/data - ./configs/sgx_default_qcnl.conf:/etc/sgx_default_qcnl.conf devices: - /dev/sgx/enclave:/dev/sgx/enclave - /dev/sgx/provision:/dev/sgx/provision command: bash -c 'cp /configs/keyring.toml /root/occlum_instance; apt update;apt install curl -y;source /root/.bashrc; cd /root/occlum_instance; occlum print mrsigner; occlum print mrenclave; occlum run /bin/bnk-watcher /host/keyring.toml' ``` ### Start DHC Node Service ```powershell # Start DHC node service docker-compose up -d # View node service Logs docker-compose logs --tail 200 -f ``` ### Case Study If you're facing problems in setup process, try to find a solution [**here**](/user-guide/alpha-testnet/node-setup/case-study). # DHC Bootnode ### Alpha Testnet /ip4/172.210.130.200/tcp/38700/p2p/12D3KooWJVjkr19spLuvmWb68zdxki2qucnubPzbHRjxRi8jhwzF ### Alpha Mainnet # Case Study ### Case 1

```jsx git clone https://github.com/occlum/enable_rdfsbase.git cd enable_rdfsbase make && make install #if still error，remake && reinstall ``` ### Case 2

* Mirror is incorrect. * Curl is not installed in the container. ### Case 3

* Install curl within the container. * Missing sgx\_default\_gcnl.conf or sgx\_default\_qcnl.conf file ### Case 4

* Mirror version is not correct, please check the mirror ID. * Wrong version ### Case 5

Mirroring is wrong, this time apply epid mirroring on Azure. ### Case 6

Configuration file error, private key length is not correct. # Node Management {% content-ref url="/pages/rzYdH5KXtxpZvk6xri1w" %} [For DHC Node](/user-guide/alpha-testnet/node-management/for-dhc-node) {% endcontent-ref %} # For DHC Node {% hint style="info" %} You can choose to be an owner of your own nodes and a voter of other nodes at the same time. {% endhint %} {% content-ref url="/pages/4JjeyOCVLTmhpXSGRcMR" %} [Start Service](/user-guide/alpha-testnet/node-management/for-dhc-node/start-service) {% endcontent-ref %} {% content-ref url="/pages/MznZWjGTCkay9p1eyJng" %} [Manage Device](/user-guide/alpha-testnet/node-management/for-dhc-node/manage-device) {% endcontent-ref %} {% content-ref url="/pages/LG0LwIxeA58m8TJygswk" %} [Vote Others](/user-guide/alpha-testnet/node-management/for-dhc-node/vote-others) {% endcontent-ref %} {% content-ref url="/pages/6o9YXGLEX5zPCE4M27fr" %} [Stop Service](/user-guide/alpha-testnet/node-management/for-dhc-node/stop-service) {% endcontent-ref %} # Start Service ### View Associated Devices After completing the configuration of the cloud server, you can login the [**node client**](https://dashboard.boolscan.com/device) to config your device. The system will automatically show the device of the corresponding cloud server according to the connected wallet address (tBOL are required as the gas). The device default status is "Not listed".

### Stake Node Token Click the "More" icon at the end of the device record row to display the device management menu, and then click the "Update PID" button in the menu to enter the staking page and complete the initial staking operation by sending the transaction on the chain. Note: The minimum amount required for the first staking is **4000 tBOL**. After the staking is completed, the system will automatically register the device and assign the corresponding Pid, and then the device will turn into the "Run" status at the same time.

### Join DHC Network When the node staking threshold is met, the node service of the current device can be formally activated by clicking the "Join Service" button in the menu and sending an on-chain transaction. Then the device will turn into the "Service" status, which means it has joined the DHC service network. Note: The minimum staking threshold for joining the DHC service network is **20,000 tBOL**. Users can increase the amount of staking through the "Lock" button from device list menu or wait for other voters' staking to meet the minimum staking threshold.

### Checkout Node Rewards If the node operates without any anomalies such as disconnections, the node income will be released at the end of every reward era. User can check out the total rewards at the statistics cards and the device rewards from the device list respectively. Note: The reward distribution ERA of DHC nodes is **50 minutes** and the unpaid rewards will not expire. # Manage Device Users can perform administrative operations by using the button group at the end of device list row. * Lock: increases the staking amount for the Owner role; * Withdraw: decreases the amount of staking for the Owner role. It will be valid only when the device is stopped; * Start Work: restart the service of the current device. The button is only displayed when the device is stopped. Be aware of the staking amount is more than 4000 tBOL before restarting the device; * Stop Work: stop the current device service. The button is only displayed in the "run/service" status; * Join Service: join the current device to the DHC service network. The button is only displayed in the "run" status; * Exit Service: Exit the current device from the DHC service network. The button is only displayed in the "service" status; * Update Pid: configure the staking information of the current device. The button is only displayed in the initial status of the device; * Unbind Pid: unbind the management wallet from the current device. The button is only displayed in the "stop" status; * Delete Did: delete the current device from the system device list. The button is only displayed in the initial status of the device; # Vote Others Any address of tBOL holders can participate in the distribution of staking rewards for DHC nodes by voting. ### Become Voter Click on the "Vote" button on the right of the statistics cards to enter the voting pop-up page, select the DHC nodes that need to participate in (multiple selection is supported) and submit a voting transaction. Note: Each voter address can vote for up to **5 nodes** at the same time and the minimum quantity for voting is **200 tBOL per node**. Meanwhile, if you want to vote more than one node, the minimum vote will be doubled accordingly. For example, if you are voting 4 nodes at the same time, you need to stake at least 800 tBOL.

### Add Stake Click on the "Lock" button in the group to submit a staking transaction. ### Reduce Stake Click on the "Withdraw" button in the group to submit an unstaking transaction, up to the tBOL balance of staking at the current address. Note: the unstaked tokens will not be released back to the admin wallet until the end of the current reward era. ### Claim Rewards Click on the "Claim" button in the group to submit a withdrawal transaction. Note: DHC node rewards can only be withdrawn manually. It is a real-time transaction directly into the wallet. # Stop Service Please follow the following steps one by one if you want to stop the node service: 1. Exit the DHC network by clicking the "Exit Service" button, and a transaction will be sent to change the device status to "run". 2. Stop the device service by clicking the "Stop Work" button and a transaction will be sent to change the device status to "Stop". 3. Withdraw the node staking of tBOL by clicking the "Withdraw" button and a transaction will be sent to withdraw tBOL from the current device. 4. Unbind the current device by clicking the "Unbind Pid" button and a transaction will be sent to unbind. Then the current device will be changed to the initial status of "Not listed" and the current node will be removed from the DHC list in the blockchain browser. 5. Delete the current device by clicking the "Delete Did" button and a transaction will be sent to delete the current device from the list of client devices associated with the admin wallet address. 6. Shutdown the cloud server when all the above 5 actions are completed. You can login the cloud service client like Microsoft Cloud and delete the virtual machine you purchased to avoid the cloud service provider to continue deducting fees. # Getting Started Bool Network Testnet has achieved its first target of supporting all EVM-compatible blockchains including prominent L1s and L2s. For testing purposes, [primary contracts](/evm-ecosystem/technical-reference/deployment-addresses) are deployed onto [a selection of EVM blockchains](/evm-ecosystem/technical-reference/chain-ids) to enable developers to design and modify their omnichain protocols on top of Bool Network. However, supporting EVM blockchains is far from demonstrating the comprehensive features of Bool Network. Based on its innovative design, Bool Network is capable and robust to support cross-chain message transmission across heterogeneous blockchains. Bool Network's development team is progressively working on supporting more on-EVM blockchains and stay tuned! The outline of developing an omnichain protocol is as follows: * Configure JSON-RPC providers for the chains your protocol plans to support (or running your own nodes). * Request testing tokens from different [Faucet](/evm-ecosystem/technical-reference/faucet). * Construct an AMT bridge through Bool Scan and detailed instructions are given [here](/evm-ecosystem/amt-bridges). * [Integrate ](/evm-ecosystem/amt-bridges/bind-consumer-to-anchor)your smart contracts with chain-specific anchors on each blockchain. * Test your protocol functionalities and monitor the status of each cross-chain message on [BoolScan](https://boolscan.com/bridge/?network=testnet). An [example](/evm-ecosystem/application-examples/helloweb3.sol) has been given. * Remember to keep in touch with the [Bool Network team](https://t.me/BOOLDevCamp) since they are always there to help. # Arbitrary Message Transmission The blew flow scheme depicts a general pattern of transmitting a message across EVM-compatible blockchains where `Consumer` represents a user's smart contract built on top of Bool Network which must have implemented the standard base contract [`BoolConsumerBase.sol`](/evm-ecosystem/smart-contracts/boolconsumerbase/boolconsumerbase.sol).

Lifecycle of a cross-chain message across EVM blockchains.

# AMT Bridges In this section, we provide a detailed guide for developers to build an Arbitrary Message Transmission (AMT) bridge on BOOLNetwork. An outline of each section is as follows: 1. [Network configuration](/evm-ecosystem/amt-bridges/network-configuration): **add** BOOL Testnet chain to your wallet. 2. [Create committees](/evm-ecosystem/amt-bridges/create-committees): **create** at least two dynamic hidden committees on BOOLScan. 3. [Build a bridge](/evm-ecosystem/amt-bridges/build-a-bridge): **deploy** your application-specific Anchor contracts onto at least two blockchains and **submit** your newly created bridge to the BOOL chain to activate it. 4. [Bind your application with Anchor](/evm-ecosystem/amt-bridges/bind-consumer-to-anchor): **fetch** Anchor addresses and **deploy** your application contract which has implemented `BoolConsumerBase.sol`. Go back to your Dashboard, and update the consumer address on each chain. # Network configuration To build AMT bridges on Bool Network, builders are required to send several transactions on the Bool chain. Just to remind you that at the early stage of the Bool chain, it is specialized as a distributed ledger to record vital information about committees, and cross-chain bridges. Hence, before carrying on, please follow the guides in this section to set up the Bool chain in your wallet. Without loss of generality, we take MetaMask as an example. #### Configuration information | Variable | Value | | ----------------------------- | ----------------------------------------- | | Network name | Bool Testnet | | RPC URL | | | Chain ID | `47` | | Currency symbol | `tBOL` | | Block explorer URL (optional) | | {% hint style="info" %} `tBOL` refers to the native token on the Bool Network testnet chain. One can request `tBOL` from the official [faucet](https://faucet.bool.network/). {% endhint %} {% hint style="warning" %} NOTE that `tBOL` has no trading value at the current stage. It serves testing purposes only. {% endhint %} #### Configure MetaMask for Bool testnet 1. Open MetaMask from the browser extensions. 2. Click on your network list on the top, and click `Add network`. 3. By clicking on `Add a network manually`, you should view the following page:

4. Finally, input the configuration information provided above to finish the set-up procedure. 5. **Configurations!** The network configuration has been done, now you can request test tokens from the [faucet](https://faucet.bool.network/) and follow the subsequent instructions to construct your AMT bridges. # Create committees 1.Connect your wallet to [BoolScan's Dashboard](https://dashboard.boolscan.com/?network=testnet).

2.Click `+` button on the "Committee" section to start creating a committee.

3\. One can configure the number of MPC nodes (which is labelled as "`Member`") to control a committee. In general, the number of committee members is positively correlated to the security level while it conversely delays the average time for processing cross-chain messages. By clicking on `Submit`, a user is required to send a transaction to create a committee and record the committee information on the Bool chain.

Create Committees - Sending the creation transaction

{% hint style="warning" %} NOTE that the current Bool testnet only supports a small size of committee members, such as 3 or 5. A higher configuration of the committee members may raise the warning of `Insufficient devices`! {% endhint %} 4\. When the preceding transaction has been submitted, a user should be able to view his newly created committee in his Dashboard. Primary information for a committee has been provided once the creation transaction is completed. The name of each committee is initially given as `default` while the committee creator can change the name to a meaningful one, such as "the prospective bridge/application name" + "the blockchain id".

5\. **Configurations!** You have mastered how to create an ECDSA-type committee in Bool Network. However, please note that a committee can only be used once in Bool Network which means that **at least two committees** are required to be created before building a bridge. * Just created one committee? Why not go above and try the creation process again? * Have owned more than two committees? Forward to the next page and build an AMT bridge! {% hint style="info" %} Remind that each committee manages a private key in Bool Network. At the creation stage of a committee, a unique private key will be assigned to it and instantly distributed into fragments that are stored in the TEE hardware of its MPC-based members. The number of fragments equals the number of committee members. {% endhint %} # Build a bridge {% hint style="info" %} NOTE that for security considerations, a committee can **only be used once** in Bool Network. Hence, building a bridge requires a minimum of two available committees. {% endhint %} 1. Move to `Bridge` the subpage under the Dashboard section.

2. Choose one of the chains from our [supported list](/evm-ecosystem/technical-reference/chain-ids) and a committee you have created. By clicking on `Deploy`, an `Anchor` deployment transaction will be triggered where the committee selected will be automatically assigned to the Anchor to be created.

3. When you have deployed at least two Anchors on independent chains, you can choose either to create an AMT bridge by clicking `Submit` or to continue adding more chains to your bridge (also you can [add more chains](/evm-ecosystem/amt-bridges/other-operations#enable-a-new-chain) after the bridge construction).

4. A few moments later, you should see a newly created bridge with several primary information, including committees' configurations, Anchor addresses and other related.

5. **Congratulations!** You have created your first bridge on Bool Network. Now you can jump to the next section to finish your omni-chain application building process. {% hint style="info" %} NOTE that it may **take a moment** to record information for a newly created bridge. Hence, it is normal to encounter the reminder of "`Synchronizing contracts`" when you hit the `Sumbit` immediately after the last anchor has been deployed. Reach out to [us](https://t.me/BOOLDevCamp) if the problem persists. {% endhint %} # Bind Consumer to Anchor To activate your bridge, there are several steps left to finish the whole process: 1. Fetch the Anchor address, pass it as a constructor parameter and deploy your application contract (should have implemented `BoolConsumerBase.sol`). An application contract example can be found [here](/evm-ecosystem/application-examples/helloweb3.sol).

2. Get the address of your application, and go back to your Dashboard. Click `View` and `Update` to have your application connected to a selected Anchor

3. You may encounter a misconfiguration error here, which implies that either your application does not implement `BoolConsumerBase.sol` or the anchor address in your application does not match the currently selected one. 4. Please refer to our repo at and follow the steps in the section **TokenBridge-3** to configure remote anchors. 5. If everything goes perfectly, you can now send your first cross-chain message and monitor the lifecycle of a message on [BoolScan](https://bridge.boolscan.com/amt/?network=testnet) later. # Other operations ### Enable a new chain Our AMT bridge is not limited to a bidirectional channel, multiple blockchains can be integrated into a single bridge. However, the maximal number of chains to be included in a bridge depends on how many networks are currently supported by Bool Network. A list of supported chains can be found [here](/evm-ecosystem/technical-reference/chain-ids). The following graphs provide a guide to adding new chains to a created bridge: 1. Clicking the `Settings` button:

Enable a new chain - Open the bridge's setting

2. Clicking the Add button to deploy `Anchor` contract on a new chain. **Do remember to create a new committee before this operation**.

Enable a new chain - Configure and deploy

3. Update your bridge by hitting `Submit`.

Enable a new chain - Submit the updating transaction

### Update consumer contract A bridge builder has the right to update the application contract of an Anchor when the application contract has been upgraded on one chain. Alternatively, the builder can choose to build another AMT bridge to support his new application.

{% hint style="info" %} NOTE that updating a consumer contract address means that messages from the previous consumer contract will not be processed by Bool Network anymore since an anchor can be connected to one consumer contract only. {% endhint %} # Smart Contracts # Primary Contracts A set of smart contracts deployed by BOOLNetwork protocol on each supporting blockchain to integrate on-chain applications with BOOL. # AnchorFactory ## Functions ### deployAnchor ```solidity function deployAnchor( string memory name, address committee ) external payable returns (address anchor) ``` Deploys an anchor for a given name and committee. #### Params

Name	Type	Description
`name`	string	The name of the anchor
`committee`	address	The committee which is created in BOOLNetwork

#### Return Values

Name	Type	Description
`anchor`	address	The address of the newly deployed anchor

{% hint style="warning" %} NOTE that although `deployAnchor` is designed as an externally callable function, it should be triggered in BOOLScan to synchronize the connection between a committee and an anchor. {% endhint %} # Messenger ## Variables ### Message ```solidity struct Message { bytes32 txUniqueIdentification; bytes32 crossType; bytes32 srcAnchor; bytes bnExtraFeed; bytes32 dstAnchor; bytes payload; } ``` A properly defined struct to pack essential cross-chain information. #### Params

Name	Type	Description
`txUniqueIdentification`	bytes32	A globally unique identifier for each cross-chain message
`crossType`	bytes32	Indicate the type of a cross-chain message
`srcAnchor`	bytes32	The address of the source chain Anchor in bytes32
`bnExtraFeed`	bytes	Additional data that depends on the `crossType`
`dstAnchor`	bytes32	The address of the destination chain Anchor in bytes32
`payload`	bytes	Application-level data that will be forwarded to the destination consumer contract

### MessageStatus ```solidity enum MessageStatus { DELIVERED, FAILED } ``` Returns `DELIVERED` when the cross-chain message has been successfully delivered to the destination. Otherwise, `FAILED` is signalled, along with an event `MessageCached` emitted. ## Events ### MessageSent ```solidity event MessageSent(Message message); ``` Emits on the source chain with essential cross-chain information packed in a `Message` struct. ### MessageReceived ```solidity event MessageReceived( bytes32 txUniqueIdentification, bytes32 crossType, bytes32 srcAnchor, bytes32 dstAnchor, MessageStatus status ); ``` Emits on the destination chain where the `MessageStatus` can be either `DELIVERED` or `FAILED`. ### MessageCached ```solidity event MessageCached(bytes reason, bytes payload) ``` Emits when the destination transaction reverted for some reason. A bridge builder should define the error logic in their application-level contracts. It can be combined with the corresponding `MessageReceived` event to recover the original message and identify the reverting reason. ## Functions ### sendToBool ```solidity function sendToBool( address payable refundAddress, bytes32 crossType, bytes memory valueFeed, uint32 dstChainId, bytes32 dstAnchor, bytes calldata payload ) external payable onlyRegisteredAnchor returns (bytes32 txUniqueIdentification) ``` Called by registered Anchors to forward cross-chain messages to BOOLNetwork. #### Params

Name	Type	Description
`refundAddress`	address payable	The address to receive the rest of the pre-paid transaction fee
`crossType`	bytes32	Indicate the type of a cross-chain message
`valueFeed`	bytes	Additional data that depends on the `crossType`
`dstChainId`	uint32	ID of the destination chain
`dstAnchor`	bytes32	The address of the destination chain Anchor in bytes32
`payload`	bytes	Application-level data that will be forwarded to the destination consumer contract

#### Return Values

Name	Type	Description
`txUniqueIdentification`	bytes32	A globally unique identifier for each cross-chain message

### receiveFromBool ```solidity function receiveFromBool( Message memory message, bytes calldata signature )external payable returns (MessageStatus status) ``` Receives cross-chain messages from BOOLNetwork. #### Params

Name	Type	Description
`message`	Message	A Message struct consists of all the essential cross-chain information
`signature`	bytes	Signature from a committee which is used to verify the validity of a cross-chain message

#### Return Values

Name	Type	Description
`status`	MessageStatus	An identifier to present the final status of a cross-chain message

# Interfaces # IAnchorFactory ## Variables ### AnchorInfo ```solidity struct AnchorInfo { uint8 version; address anchor; address committee; address deployer; }; ``` Stores the descriptive information of an anchor. It can be fetched via `fetchInfo`. #### Params

Name	Type	Description
`version`	uint8	The version of the anchor contract
`anchor`	address	The address of the anchor
`committee`	address	The committee of the anchor
`deployer`	address	The initial deployer of the anchor

## Events ### AnchorDeployed ```solidity event AnchorDeployed( address indexed deployer, uint32 anchorId, address anchor, address committee ); ``` Emitted when a new anchor deployed. #### Params

Name	Type	Description
`deployer`	address	The deployer of the anchor
`anchorId`	uint32	The unique identification of the anchor
`anchor`	address	The address of the anchor
`committee`	address	The committee of the anchor

## Functions ### messenger ```solidity function messenger( ) external view returns (address) ``` Returns the messenger address on the local blockchain. Any anchor deployed through this AnchorFactory will be initially connected to this messenger. #### Return Values

Type	Description
address	The address of the messenger

### totalAnchors ```solidity function totalAnchors( ) external view returns (uint32) ``` Returns the total number of anchors which have been deployed. #### Return Values

Type	Description
uint32	The total number of anchors which have been deployed via the AnchorFactory

### fetchId ```solidity function fetchId( address anchor ) external view returns (uint32) ``` Returns the unique identification of the input anchor. Each identification is unique on the local blockchain and can be passed as a key to fetch the description information of the corresponding anchor. #### Params

Name	Type	Description
`anchor`	address	The address for which the unique identification will be fetched

#### Return Values

Type	Description
uint32	The unique identification of the input anchor

### fetchInfo ```solidity function fetchInfo( uint32 id ) external view returns (AnchorInfo memory) ``` Returns the description information of the anchor with the input identification. #### Params

Name	Type	Description
`id`	uint32	The unique identification for which the description information will be fetched

# IMessenger ## Functions ### factory ```solidity function factory( ) external view returns (address); ``` Returns the address of `AnchorFactory` on the same chain. #### Return Values

Type
address	The address of AnchorFactory on the same chain

# On-chain endpoint: Anchor # Anchor.sol ## Constants ### PURE\_MESSAGE ```solidity bytes32 public constant PURE_MESSAGE = keccak256("PURE_MESSAGE"); ``` ### VALUE\_MESSAGE ```solidity bytes32 public constant VALUE_MESSAGE = keccak256("VALUE_MESSAGE"); ``` {% hint style="info" %} BOOLNetwork **ONLY** supports `PURE_MESSAGE` type cross-chain messages at the current Testnet stage. `VALUE_MESSAGE` has not been enabled yet and hence submitting this type of message will lead to a transaction revert. {% endhint %} ## Functions ### updateConsumer ```solidity function updateConsumer( address newConsumer ) external onlyOwner ``` Updates the consumer contract that is uniquely binding to the anchor. This method can only be called by the current `owner`. #### Params

Name	Type	Description
`newConsumer`	address	The address of the new consumer to use this Anchor as the cross-chain endpoint

### sendToMessenger ```solidity function sendToMessenger( address payable refundAddress, bytes32 crossType, bytes memory valueFeed, uint32 dstChainId, address dstAnchor, bytes calldata payload ) external payable nonReentrant onlyConsumer returns (bytes32 txUniqueIdentification) ``` Calls anchor to forward the cross-chain message to the BOOLNetwork messenger on the source chain. This method can only be called by the consumer contract that is uniquely binding to the anchor. #### Parameters:

Name	Type	Description
`refundAddress`	address	The address to receive the refund of the pre-paid transaction fee
`crossType`	bytes32	Indicate the type of a cross-chain message
`valueFeed`	bytes	Additional data that depends on the `crossType`
`dstChainId`	uint32	ID of the destination chain
`dstAnchor`	address	The address of the destination chain Anchor
`payload`	bytes	Application-level data that will be forwarded to the destination consumer contract

#### Return values:

Name	Type	Description
`txUniqueIdentification`	bytes32	A globally unique identifier for each cross-chain message

### receiveFromMessenger ```solidity function receiveFromMessenger( bytes32 txUniqueIdentification, bytes32 crossType, bytes memory valueFeed, bytes32 srcAnchor, bytes memory payload ) external payable onlyMessenger ``` Called by the Messenger contract on the local chain to receive the cross-chain message from the source chain and forward it to the connected consumer contract. #### Params

Name	Type	Description
`txUniqueIdentification`	bytes32	A globally unique identifier for each cross-chain message
`crossType`	bytes32	Indicate the type of a cross-chain message
`valueFeed`	bytes	Additional data that depends on the `crossType`
`srcAnchor`	bytes32	The address of the source chain Anchor in bytes32
`payload`	bytes	Application-level data that will be forwarded to the destination consumer contract

# IAnchor.sol ## Functions ### committee ```solidity function committee( ) external view returns (address) ``` Returns the `committee` of the anchor. The committee cannot be changed after the deployment of the anchor since `committee` is immutable. #### Return Values

Type	Description
address	The address of the committee

### consumer ```solidity function consumer( ) external view returns (address) ``` Returns the consumer of the anchor. The consumer can be changed by the anchor's owner via `updateConsumer`. #### Return Values

Type	Description
address	The address of the consumer

### Owner ```solidity function owner( ) public view returns (address) ``` #### Return Values

Type	Description
address	The address of the current owner

### transferOwnership ```solidity function transferOwnership( address newOwner ) public onlyOwner ``` Transfers the ownership of the anchor contract to a new address. This method can only be called by the current `owner`.

Name	Type	Description
`newOwner`	address	The address of the new owner

# BoolConsumerBase To facilitate omnichain development, BOOLNetwork has provided a standard base contract `BoolConsumerBase` for developers to easily integrate their protocol with BOOLNetwork. Details can be found [here](/evm-ecosystem/smart-contracts/boolconsumerbase/boolconsumerbase.sol). # BoolConsumerBase.sol ```solidity // SPDX-License-Identifier: MIT pragma solidity 0.8.16; import {ERC165, IERC165} from "@openzeppelin/contracts/utils/introspection/ERC165.sol"; import {IBoolConsumerBase} from "../interfaces/IBoolConsumerBase.sol"; import {IAnchor} from "../interfaces/IAnchor.sol"; abstract contract BoolConsumerBase is ERC165, IBoolConsumerBase { error NOT_ANCHOR(address wrongAnchor); bytes32 public constant PURE_MESSAGE = keccak256("PURE_MESSAGE"); bytes32 public constant VALUE_MESSAGE = keccak256("VALUE_MESSAGE"); address internal immutable _anchor; constructor(address anchor_) { _anchor = anchor_; } modifier onlyAnchor() { _checkAnchor(msg.sender); _; } function receiveFromAnchor( bytes32 txUniqueIdentification, bytes memory payload ) external virtual override onlyAnchor {} function _checkAnchor(address targetAnchor) internal view { if (targetAnchor != _anchor) revert NOT_ANCHOR(targetAnchor); } function _sendAnchor( uint256 callValue, address payable refundAddress, bytes32 crossType, bytes memory extraFeed, uint32 dstChainId, bytes memory payload ) internal virtual returns (bytes32 txUniqueIdentification) { txUniqueIdentification = IAnchor(_anchor).sendToMessenger{value: callValue}( refundAddress, crossType, extraFeed, dstChainId, payload ); } function supportsInterface( bytes4 interfaceId ) public view virtual override(ERC165, IERC165) returns (bool) { return interfaceId == type(IBoolConsumerBase).interfaceId || super.supportsInterface(interfaceId); } function anchor() external view override returns (address) { return _anchor; } } ``` # IBoolConsumerBase.sol ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import {IERC165} from "@openzeppelin/contracts/utils/introspection/IERC165.sol"; interface IBoolConsumerBase is IERC165 { function anchor() external view returns (address); /// @dev Application builder should define their logic here /// @dev to decode "payload" received from the corresponding Anchor function receiveFromAnchor(bytes32 txUniqueIdentification, bytes memory payload) external; } ``` # User Configurations Several tips for our bridge builders are given here! ## Consumer ### Deployment parameters ```solidity import "./base/BoolConsumerBase.sol"; contract UserMock is BoolConsumerBase { ... constructor(address anchor_) BoolConsumerBase(anchor_) {} ... } ``` Remember to **pass `anchor` to your contract constructor** to match the fundamental requirement of implementing `BoolConsumerBase.sol`. In addition, when updating `consumer` in a deployed Anchor, the Anchor contract will validate the consumer's configuration as follows: ```solidity require( IBoolConsumerBase(consumer_).anchor() == address(this), "Anchor: ANCHOR_MISMATCH" ); ``` Hence, please **DO NOT misconfigure** your consumer contract! Alternatively, you can design an additional function in your consumer contract to update the address of the anchor. However, we do not recommend implementing this function in your contract since in terms of the users' trust, `anchor` should never be changed after the deployment. ### Send cross-chain messages to Anchor Each consumer contract implemented `BoolConsumerBase.sol` should have inherited the following internal function `_sendToAnchor`. It is the intermediary to send cross-chain messages to the connected Anchor contract. ```solidity function _sendToAnchor( address payable refundAddress, bytes32 crossType, bytes memory extraFeed, uint32 dstChainId, address dstAnchor, bytes memory payload ) internal virtual returns (bytes32 txUniqueIdentification) ``` A consumer contract must define an upper-level function to implement this core internal function and several tips are provided to implement `_sendToAnchor`: * **pack** the data to be executed on the destination chain into `payload`, such as using `abi.encode` to pack the target function's parameters. * pass the **correct** `dstAnchor` since cross-chain messages can only be transmitted to remote anchors within the same AMT bridge. * request`extraFeed` from our primary contracts based on the value of`crossType`: either [`PURE_MESSAGE`](/evm-ecosystem/smart-contracts/on-chain-endpoint-anchor/anchor.sol#pure_message) or [`VALUE_MESSAGE`](/evm-ecosystem/smart-contracts/on-chain-endpoint-anchor/anchor.sol#value_message). {% hint style="warning" %} * Leave `extraFeed` **blank** if `PURE_MESSAGE` selected. * `VALUE_MESSAGE` has not been enabled yet. {% endhint %} ### Receive a Message from Anchor ```solidity modifier onlyAnchor() { require(msg.sender == anchor, "BoolConsumerBase: NOT_ANCHOR"); _; } function receiveFromAnchor( bytes memory payload ) external virtual override {} ``` * A consumer contract **must override** `receiveFromAnchor` and define corresponding logic to parse `payload` sent from its corresponding Anchor. * Two basic operations should be included in the override function: decode payload and forward decoded data to subsequent functions. * One can use the provided modifier `onlyAnchor` to restrict the accessibility of `receiveFromAnchor`. ## Anchor ### Transfer the ownership of the `Anchor` contract * The default owner is the initial deployer of an Anchor. One can use [`owner`](/evm-ecosystem/smart-contracts/on-chain-endpoint-anchor/ianchor.sol#owner) to inquire about the address of the current owner. * The most important role played by the owner is to update the connected `consumer`. * The interface for transferring the ownership of an anchor can be found at [`transferOwnership`](/evm-ecosystem/smart-contracts/on-chain-endpoint-anchor/ianchor.sol#transferownership). # Application Examples # HelloWeb3.sol #### A simple use case HelloWeb3 is an omnichain interoperable contract that sends and receives greetings across multiple blockchains. This HelloWeb3 contract can modify the `remoteGreetings` storage of others on remote blockchains. #### Implementation details To perform in an omnichain manner, a contract deployer should have built an AMT bridge on BOOLScan. Recap that an AMT bridge should consist of at least two deployed Anchor contracts which are respectively controlled by two distinct committees in BOOLNetwork. ```solidity // SPDX-License-Identifier: MIT pragma solidity 0.8.16; import {IMessengerFee} from "../../interfaces/messenger/IMessengerFee.sol"; import {IAnchor} from "../../interfaces/IAnchor.sol"; import {BoolConsumerBase} from "../../base/BoolConsumerBase.sol"; contract HelloWeb3 is BoolConsumerBase { // srcChainId => recipient => sender => greeting mapping(uint32 => mapping(bytes32 => mapping(bytes32 => string))) private _greetings; constructor(address anchor_) BoolConsumerBase(anchor_) {} event GreetingSent( uint32 indexed dstChainId, bytes32 indexed recipient, bytes32 indexed sender ); event GreetingReceived( uint32 indexed srcChainId, bytes32 indexed recipient, bytes32 indexed sender ); function sendGreeting( uint32 dstChainId, bytes32 recipient, string memory greeting ) external payable { address sender = msg.sender; bytes memory payload = _encodePayload(recipient, sender, greeting); _sendAnchor(msg.value, payable(sender), PURE_MESSAGE, bytes(""), dstChainId, payload); emit GreetingSent(dstChainId, recipient, _addressToBytes32(sender)); } function receiveFromAnchor( bytes32 txUniqueIdentification, bytes memory payload ) external override onlyAnchor { /** Get Local ChainId */ uint32 srcChainId; bytes memory crossId = abi.encode(txUniqueIdentification); assembly { srcChainId := mload(add(crossId, 4)) } /** Decode Payload */ (bytes32 recipient, bytes32 sender, string memory greeting) = _decodePayload(payload); /** Receive Greeting */ _receiveGreeting(srcChainId, recipient, sender, greeting); } /** View/Pure Functions */ function fetchGreeting( uint32 srcChainId, bytes32 recipient, bytes32 sender ) external view returns (string memory greeting) { greeting = _greetings[srcChainId][recipient][sender]; } function estimateCrossFee( uint32 dstChainId, bytes32 recipient, string memory greeting ) public view returns (uint256 fee) { address srcAnchor = _anchor; bytes memory payload = _encodePayload(recipient, msg.sender, greeting); fee = IMessengerFee(IAnchor(srcAnchor).messenger()).cptTotalFee( srcAnchor, dstChainId, uint32(payload.length), PURE_MESSAGE, bytes("0x") ); } /** Internal/Private Functions */ function _encodePayload( bytes32 recipient, address sender, string memory greeting ) private pure returns (bytes memory payload) { payload = abi.encode(recipient, _addressToBytes32(sender), greeting); } function _decodePayload( bytes memory payload ) private pure returns (bytes32 recipient, bytes32 sender, string memory greeting) { (recipient, sender, greeting) = abi.decode(payload, (bytes32, bytes32, string)); } function _addressToBytes32(address account) private pure returns (bytes32) { return bytes32(uint256(uint160(account))); } function _receiveGreeting( uint32 srcChainId, bytes32 recipient, bytes32 sender, string memory greeting ) private { /** Update Greeting */ _greetings[srcChainId][recipient][sender] = greeting; /** Emit Received Event */ emit GreetingReceived(srcChainId, recipient, sender); } } ``` # Technical Reference All network information on using BOOLNetwork is available in this section. # Chain IDs The network marked with an asterisk (\*) indicates that it has been integrated into Bool Network but are not yet officially open to the public ### Mainnet #### EVM-compatible chains Ethereum: `1` Optimism: `10` Binance Smart Chain: `56` Polygon PoS: `137` zkSync Era: `324` Polygon zkEVM\*: `1101` BEVM: `1501` Base: `8453` Arbitrum One: `42161` Avalanche C-Chain: `43114` Linea: `59144` #### Non EVM-compatible chains Bitcoin Mainnet: `2693367830` ### Testnet #### EVM-compatible chains Ethereum Goerli: `5` BSC Chapel: `97` zkSync Goerli: `280` Optimism Goerli: `420` BEVM Testnet: `1502` opBNB Testnet: `5611` Avalanche Fuji: `43113` Linea Goerli: `59140` Polygon Mumbai: `80001` Base Goerli: `84531` Nautilus Proteus: `88002` Filecoin Calibration: `314159` Arbitrum Goerli: `421613` Scroll Sepolia: `534351` Ethereum Sepolia: `11155111` #### Non EVM-compatible chains Bitcoin Testnet3: `271847360` Solana Testnet\*: `1134131222` SUI Testnet\*: `1918346523` {% hint style="info" %} The team is working on supporting Starknet and more non-EVM blockchains, including Polkadot, Near, etc. {% endhint %} # Deployment Addresses The EVM-domain primary contracts for deploying user-level anchors and processing cross-chain messages. The infrastructure layer of Bool Network consists of two primary contracts to facilitate the connection between user protocols and the core messaging module. Each primary contract has different functionalities which have been outlined in the [Primary Contracts](/evm-ecosystem/smart-contracts/primary-contracts) section. # Devnet ### Ethereum Goerli (Chain ID: 5) #### `AnchorFactory` ``` 0x8dc27800737ace47ca7fb61d69b954e33f68bb2e ``` #### `Messenger` ``` 0xf1aa347deb7d51784d2400b6e62b0275acd52912 ``` ### BSC Chapel (Chain ID: 97) #### `AnchorFactory` ``` 0x3a8122b1128109330fc43c6d0143bdf86b7975d0 ``` #### `Messenger` ``` 0x0a39eefd4c218a6b8edcc812ec09b58c227aaae8 ``` ### Optimism Goerli (Chain ID: 420) #### `AnchorFactory` ``` 0xbcc8f623580ce3bb577b25c7336ac1d21e95f49a ``` #### `Messenger` ``` 0x3e5d843f3d2d0fd7e35e05d5c3500078f52d809a ``` ### Polygon Mumbai (Chain ID: 80001) #### `AnchorFactory` ``` 0x771df9504f998a81cc3092b6ac2a35562a61fac1 ``` #### `Messenger` ``` 0x73564e0599c3ba7a3ab73cae2777eebc5039fe0b ``` ### Arbitrum Goerli (Chain ID: 421613) #### `AnchorFactory` ``` 0xd068d7ab2da06022d98494b6fc317917ea5f7df6 ``` #### `Messenger` ``` 0x166f765ea54a47d5f3febe7f92c9d7713bc2933a ``` ### Ethereum Sepolia (Chain ID: 11155111) #### `AnchorFactory` ``` 0x5491b94ea24d8eb21e4c9f4cf4d815e8691b2e53 ``` #### `Messenger` ``` 0x2acdafe79bd7ae035e6e83396f70829d39f7c1f9 ``` # Testnet ### Ethereum Goerli (Chain ID: 5) #### `AnchorFactory` ``` 0x0da8f8356ae2e97a5a776749e76c37f47057fcc0 ``` #### `Messenger` ``` 0xf68f872f0dde0ec1ba8c28eed9d0674760aa8eb1 ``` ### BSC Chapel (Chain ID: 97) #### `AnchorFactory` ``` 0x0da8f8356ae2e97a5a776749e76c37f47057fcc0 ``` #### `Messenger` ``` 0xf68f872f0dde0ec1ba8c28eed9d0674760aa8eb1 ``` ### zkSync Goerli (Chain ID: 280) #### `AnchorFactory` ``` 0x6eb40f2258ed4d7063523d5ddf57f0b5e217926e ``` #### `Messenger` ``` 0x9ee1a06e57b074bab0ce239738b7131f7ca158c0 ``` ### Optimism Goerli (Chain ID: 420) #### `AnchorFactory` ``` 0x0da8f8356ae2e97a5a776749e76c37f47057fcc0 ``` #### `Messenger` ``` 0xf68f872f0dde0ec1ba8c28eed9d0674760aa8eb1 ``` ### Polygon Mumbai (Chain ID: 80001) #### `AnchorFactory` ``` 0x0da8f8356ae2e97a5a776749e76c37f47057fcc0 ``` #### `Messenger` ``` 0xf68f872f0dde0ec1ba8c28eed9d0674760aa8eb1 ``` ### Arbitrum Goerli (Chain ID: 421613) #### `AnchorFactory` ``` 0x0da8f8356ae2e97a5a776749e76c37f47057fcc0 ``` #### `Messenger` ``` 0xf68f872f0dde0ec1ba8c28eed9d0674760aa8eb1 ``` ### Ethereum Sepolia (Chain ID: 11155111) #### `AnchorFactory` ``` 0x0da8f8356ae2e97a5a776749e76c37f47057fcc0 ``` #### `Messenger` ``` 0xf68f872f0dde0ec1ba8c28eed9d0674760aa8eb1 ``` # Alpha Mainnet ### Ethereum (Chain ID: 1) #### [`AnchorFactory`](https://etherscan.io/address/0xfc1475e9e16c88adc3309335e00de841c176994c) ``` 0xfc1475e9e16c88adc3309335e00de841c176994c ``` #### [`Messenger`](https://etherscan.io/address/0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce) ``` 0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce ``` ### Optimism (Chain ID: 10) #### [`AnchorFactory`](https://optimistic.etherscan.io/address/0xfc1475e9e16c88adc3309335e00de841c176994c) ``` 0xfc1475e9e16c88adc3309335e00de841c176994c ``` #### [`Messenger`](https://optimistic.etherscan.io/address/0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce) ``` 0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce ``` ### Binance Smart Chain (Chain ID: 56) #### [`AnchorFactory`](https://bscscan.com/address/0xfc1475e9e16c88adc3309335e00de841c176994c) ``` 0xfc1475e9e16c88adc3309335e00de841c176994c ``` #### [`Messenger`](https://bscscan.com/address/0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce) ``` 0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce ``` ### Polygon PoS (Chain ID: 137) #### [`AnchorFactory`](https://polygonscan.com/address/0xfc1475e9e16c88adc3309335e00de841c176994c) ``` 0xfc1475e9e16c88adc3309335e00de841c176994c ``` #### [`Messenger`](https://polygonscan.com/address/0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce) ``` 0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce ``` ### zkSync (Chain ID: 324) #### [`AnchorFactory`](https://explorer.zksync.io/address/0x081380A424F6156e1A99d64f9be250BAC37d9Da5) ``` 0x081380A424F6156e1A99d64f9be250BAC37d9Da5 ``` #### [`Messenger`](https://explorer.zksync.io/address/0x2Ff16760321af33A1D7b8bf7477fad0258eAE819) ``` 0x2Ff16760321af33A1D7b8bf7477fad0258eAE819 ``` ### BEVM (Chain ID: 1501) #### [`AnchorFactory`](https://scan.bevm.io/address/0xfc1475e9e16c88adc3309335e00de841c176994c) ``` 0xfc1475e9e16c88adc3309335e00de841c176994c ``` #### [`Messenger`](https://scan.bevm.io/address/0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce) ``` 0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce ``` ### Base (Chain ID: 8453) #### [`AnchorFactory`](https://basescan.org/address/0xfc1475e9e16c88adc3309335e00de841c176994c) ``` 0xfc1475e9e16c88adc3309335e00de841c176994c ``` #### [`Messenger`](https://basescan.org/address/0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce) ``` 0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce ``` ### Arbitrum One (Chain ID: 42161) #### [`AnchorFactory`](https://arbiscan.io/address/0xfc1475e9e16c88adc3309335e00de841c176994c) ``` 0xfc1475e9e16c88adc3309335e00de841c176994c ``` #### [`Messenger`](https://arbiscan.io/address/0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce) ``` 0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce ``` ### Avalanche C-Chain (Chain ID: 43114) #### [`AnchorFactory`](https://subnets.avax.network/c-chain/address/0xfc1475e9e16c88adc3309335e00de841c176994c) ``` 0xfc1475e9e16c88adc3309335e00de841c176994c ``` #### [`Messenger`](https://subnets.avax.network/c-chain/address/0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce) ``` 0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce ``` ### Linea (Chain ID: 59144) #### [`AnchorFactory`](https://lineascan.build/address/0xfc1475e9e16c88adc3309335e00de841c176994c) ``` 0xfc1475e9e16c88adc3309335e00de841c176994c ``` #### [`Messenger`](https://lineascan.build/address/0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce) ``` 0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce ``` ### Scroll (Chain ID: 534352) #### [`AnchorFactory`](https://scrollscan.com/address/0xfc1475e9e16c88adc3309335e00de841c176994c) ``` 0xfc1475e9e16c88adc3309335e00de841c176994c ``` #### [`Messenger`](https://scrollscan.com/address/0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce) ``` 0x10e82b34e757cf4fdefc0e9fc8cca4e5b9749bce ``` # Faucet #### BOOL Network #### EVM ecosystem [Ethereum Goerli](https://goerlifaucet.com/) [BSC Testnet (Chapel)](https://testnet.bnbchain.org/faucet-smart) [zkSync Goerli](https://goerli.portal.zksync.io/faucet) (bridge from Goerli onto L2) [Optimism Goerli](https://community.optimism.io/docs/useful-tools/faucets/#goerli-faucets) (bridge from Goerli onto L2) [Polygon Mumbai](https://mumbaifaucet.com/) [Arbitrum Goerli](https://developer.arbitrum.io/getting-started-users#2--deposit-your-eth-tokens-l1--l2) (bridge from Goerli onto L2) [Ethereum Sepolia](https://sepoliafaucet.com/) # B² Bool Bridge Supporting Assets: BTC, BRC-20 ### Prerequisites Before starting the bridging process between Bitcoin and B² Mainnet, ensure the following: {% hint style="success" %} The wallet selection for the bridge supports the following two modes: * Connect [UniSat Wallet](https://unisat.io/) and use [Particle Wallet](https://particle.network/) to generate an AA account automatically. * Connect [UniSat Wallet](https://unisat.io/) and [MetaMask Wallet](https://metamask.io/). {% endhint %}

Please choose the appropriate user guide based on your **wallet selection**. {% content-ref url="/pages/8SQ7cnkeQmvzZj8bzlIi" %} [B² Bool Bridge (Particle)](/applications/b-bool-bridge/b-bool-bridge-particle) {% endcontent-ref %} {% content-ref url="/pages/kIjsIKsVd5tOe2RkYvjz" %} [B² Bool Bridge (MetaMask)](/applications/b-bool-bridge/b-bool-bridge-metamask) {% endcontent-ref %} # B² Bool Bridge (Particle) Supporting Assets: BTC, BRC-20 ### Deposit: Bridge Assets to B² Mainnet #### 1. Navigate to B² Bool Bridge Access [B² Bool Bridge](https://bsquared.boolbridge.com/). This is where you initiate the deposit transaction regarding BTC or BRC-20 from Bitcoin to B² Mainnet.

#### 2. Connect Wallets On the Bridge interface, connect your UniSat wallet and use Particle to generate an AA account. Follow the prompts and confirm the wallet connections. {% hint style="info" %} Through the wallet connection, assets will be bridged to the Layer 2 **Particle Wallet address** (the default destination address). {% endhint %}

#### 3. Deposit on Bitcoin Initiate the deposit transaction by specifying the amount of BTC or BRC-20 you intend to bridge from the Bitcoin to the B² Mainnet. Review and confirm the transaction details. **3.1 Specify the amount of BTC or BRC-20 to deposit**

**3.2 Confirm the deposit transaction in UniSat**

#### 4. Monitor the bridging progress on the History page Once the deposit is initiated, monitor the progress of your transaction on the History page of the B² Bool Bridge. This section provides real-time tracks on the status of your cross-chain transactions.

#### 5. Check destination address balance via B² Mainnet Explorer When the deposit is completed, check the balance of the destination address on [B² Mainnet Explorer](https://explorer.bsquared.network/). Confirm that the bridged BTC or BRC-20 is reflected in your B² Mainnet address. ### Withdraw: Bridge Assets from B² Mainnet to Bitcoin #### 1. Navigate to the B² Bool Bridge Access [B² Bool Bridge](https://bsquared.boolbridge.com/). This is where you'll initiate the withdrawal transaction regarding BTC or BRC-20 from B² Mainnet to Bitcoin.

#### 2. Connect Wallets On the Bridge interface, connect your UniSat wallet. Follow the prompts and confirm the wallet connections. {% hint style="info" %} Through the wallet connection, assets will be bridged from the Layer 2 **Particle address** (the source address) to your Unisat address on Bitcoin. {% endhint %}

#### 3. Withdraw from B² {% hint style="warning" %} Only BRC-20 withdrawals are available at the moment. {% endhint %} Initiate the withdrawal transaction by specifying the amount of BTC or BRC-20 you intend to bridge from B² Mainnet to Bitcoin. Review and confirm the transaction details. **3.1 Specify the amount of BRC-20 to withdraw**

**3.2 Confirm the withdraw transaction in Unisat**

#### 2. Connect Wallets On the Bridge interface, connect both your MetaMask and UniSat wallets. Follow the prompts and confirm the wallet connections. {% hint style="info" %} Through the wallet connection, assets will be bridged to your Layer 2 **Metamask Wallet address** (the default destination address). {% endhint %}

**3.2 Confirm the deposit transaction in UniSat**

#### 4. Monitor the bridging progress on the History page Once the deposit is initiated, monitor the progress of your transaction on the History page of B² Bool Bridge. This section provides real-time tracks on the status of your cross-chain transactions.

#### 2. Connect Wallets On the Bridge interface, connect both your MetaMask and UniSat wallets. Follow the prompts and confirm the wallet connections. {% hint style="info" %} Through the wallet connection, assets will be bridged from the Layer 2 **Metamask address** (the source address) to your Unisat address on Bitcoin. {% endhint %}

**3.2 Confirm the withdrawal transaction in Metamask**

#### 4. Monitor progress on the History page Once the withdrawal is initiated, monitor the progress of your transactions on the History page of B² Bool Bridge. This section provides real-time tracks on the status of your cross-chain transactions. #### 5. Check assets balance in Unisat Wallet When the deposit is completed, check the balance of the assets in Unisat Wallet. # Bool Swap The official native asset bridge for Bool Network **Website:** [boolswap](https://boolswap.com/bridge/) **Introduction:** BoolSwap is the official native asset cross-chain bridge for Bool Network. It serves as a vital link for seamless asset transfer between different networks. With BoolSwap's intuitive and secure mechanism, users can efficiently move their native assets across the networks supported by Bool Network. **Key data:** * Supported chains: over 10 chains, including Ethereum, Optimism, BSC, Polygon PoS, zkSync, BEVM, Base, Arbitrum One, Avalanche C, Linea, and Scroll * Clients: 5+ wallets and 3+ aggregators * Distinctive addresses: over 8,000 * Total transactions: over 14,000 * Trading volume: over $8,000,000 **Features:** * **Native Asset Bridge:** BoolSwap allows you to transfer native assets from one blockchain to another within the Bool Network ecosystem. * **Seamless Interoperability:** Easily bridge your assets without cumbersome processes, enabling fluid movement across different blockchain networks. * **Security and Reliability:** BoolSwap ensures the security and integrity of your assets during the cross-chain transfer process. * **User-Friendly Interface:** The user interface is designed to simplify the bridging process, making it accessible to both beginners and experienced users. * **Real-Time Monitoring:** Keep track of your asset transfers with real-time monitoring to stay updated on transaction progress. {% hint style="warning" %} *Disclaimer: Always exercise caution and verify details before conducting any asset transfers or transactions.* {% endhint %} # Pool Configuration ### Alpha Mainnet #### **Ethereum** ```json { "ethereum_mainnet": { "chainId": "1", "contracts": { "Router": "0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d", "PoolFactory": "0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924" }, "tokens": { "ETH": { "decimals": "18", "poolId": "4", "officialERC20": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", "poolAddress": "0xbc428bade5483db3815cafc2966ef0da8a57b120" }, "USDT": { "decimals": "6", "poolId": "2", "officialERC20": "0xdac17f958d2ee523a2206206994597c13d831ec7", "poolAddress": "0x09135a91f6cb6ed6dbdd947fc09a533b4f7ab84d" }, "USDC": { "decimals": "6", "poolId": "3", "officialERC20": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", "poolAddress": "0xaff2aa237a3d9cac177ec4202bf9700c3430000c" } } } } ``` #### **Optimism** ```json { "optimism_mainnet": { "chainId": "10", "contracts": { "Router": "0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d", "PoolFactory": "0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924" }, "tokens": { "ETH": { "decimals": "18", "poolId": "8", "officialERC20": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", "poolAddress": "0x0571edf989d899851b441546b266f7b632c8ec3f" }, "USDT": { "decimals": "6", "poolId": "6", "officialERC20": "0x94b008aa00579c1307b0ef2c499ad98a8ce58e58", "poolAddress": "0x2a6e088056e94badd431640aa254cb74ad7c23a3" }, "USDC": { "decimals": "6", "poolId": "7", "officialERC20": "0x7f5c764cbc14f9669b88837ca1490cca17c31607", "poolAddress": "0xfcd68ec4c59747abcb7faf705873856676d57e47" } } } } ``` #### Binance Smart Chain ```json { "bsc_mainnet": { "chainId": "56", "contracts": { "Router": "0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d", "PoolFactory": "0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924" }, "tokens": { "USDT": { "decimals": "18", "poolId": "3", "officialERC20": "0x55d398326f99059fF775485246999027B3197955", "poolAddress": "0xAff2Aa237A3d9cAc177eC4202bF9700C3430000C" }, "BUSD": { "decimals": "18", "poolId": "2", "officialERC20": "0xe9e7CEA3DedcA5984780Bafc599bD69ADd087D56", "poolAddress": "0x09135a91f6cb6ed6dbdd947fc09a533b4f7ab84d" } } } } ``` #### Polygon PoS ```json { "polygon_mainnet": { "chainId": "137", "contracts": { "Router": "0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d", "PoolFactory": "0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924" }, "tokens": { "USDT": { "decimals": "6", "poolId": "1", "officialERC20": "0xc2132d05d31c914a87c6611c10748aeb04b58e8f", "poolAddress": "0x2D958BF57b35fbE5AE865C7956338d02e0B30562" }, "USDC": { "decimals": "6", "poolId": "2", "officialERC20": "0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174", "poolAddress": "0x09135a91F6cB6ED6DBdd947FC09a533B4F7AB84D" } } } } ``` #### zkSync Era ```json { "zksync_era": { "chainId": "324", "contracts": { "Router": "0x62e78B9C9A6d55C0B9dB554097DB4B9bd4dE6f4d", "PoolFactory": "0xEAef1354819Fe385937f83a7a7eD017f36Ef6f56" }, "tokens": { "ETH": { "decimals": "18", "poolId": "1", "officialERC20": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", "poolAddress": "0x4Ee556c8076985F111F56e54B254fd045BB52848" }, "USDT": { "decimals": "6", "poolId": "3", "officialERC20": "0x493257fd37edb34451f62edf8d2a0c418852ba4c", "poolAddress": "0xCfB8DFBdc45A26F9E0d928C233AC812EEF2D844D" }, "USDC": { "decimals": "6", "poolId": "2", "officialERC20": "0x3355df6D4c9C3035724Fd0e3914dE96A5a83aaf4", "poolAddress": "0x45310aDb1688a31F8e690dc4D56E0408214580C0" } } } } ``` #### BEVM ```json { "bevm_mainnet": { "chainId": "1501", "contracts": { "Router": "0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d", "PoolFactory": "0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924" }, "tokens": { "WBTC": { "decimals": "18", "poolId": "1", "officialERC20": "0x09ff8e49d0ea411a3422ed95e8f5497d4241f532", "poolAddress": "0x2d958bf57b35fbe5ae865c7956338d02e0b30562" } } } } ``` #### Base ```json { "base_mainnet": { "chainId": "8453", "contracts": { "Router": "0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d", "PoolFactory": "0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924" }, "tokens": { "ETH": { "decimals": "18", "poolId": "1", "officialERC20": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", "poolAddress": "0x2d958bf57b35fbe5ae865c7956338d02e0b30562" } } } } ``` #### Arbitrum One ```json { "arbitrum_one": { "chainId": "42161", "contracts": { "Router": "0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d", "PoolFactory": "0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924" }, "tokens": { "ETH": { "decimals": "18", "poolId": "6", "officialERC20": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", "poolAddress": "0x2a6e088056e94badd431640aa254cb74ad7c23a3" }, "USDT": { "decimals": "6", "poolId": "4", "officialERC20": "0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9", "poolAddress": "0xbc428bade5483db3815cafc2966ef0da8a57b120" }, "USDC": { "decimals": "6", "poolId": "5", "officialERC20": "0xff970a61a04b1ca14834a43f5de4533ebddb5cc8", "poolAddress": "0x3c18d6bf6c0aab40a977d29e4b235f23f5441b7b" }, "WBTC": { "decimals": "8", "poolId": "7", "officialERC20": "0x2f2a2543b76a4166549f7aab2e75bef0aefc5b0f", "poolAddress": "0xfcd68ec4c59747abcb7faf705873856676d57e47" } } } } ``` #### Avalanche C-Chain ```json { "avalanche_mainnet": { "chainId": "43114", "contracts": { "Router": "0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d", "PoolFactory": "0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924" }, "tokens": { "USDT": { "decimals": "6", "poolId": "1", "officialERC20": "0x9702230A8Ea53601f5cD2dc00fDBc13d4dF4A8c7", "poolAddress": "0x2D958BF57b35fbE5AE865C7956338d02e0B30562" }, "USDC": { "decimals": "6", "poolId": "2", "officialERC20": "0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E", "poolAddress": "0x09135a91F6cB6ED6DBdd947FC09a533B4F7AB84D" } } } } ``` #### Linea ```json { "linea_mainnet": { "chainId": "59144", "contracts": { "Router": "0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d", "PoolFactory": "0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924" }, "tokens": { "ETH": { "decimals": "18", "poolId": "1", "officialERC20": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", "poolAddress": "0x2d958bf57b35fbe5ae865c7956338d02e0b30562" } } } } ``` #### Scroll ```json { "scroll_mainnet": { "chainId": "534352", "contracts": { "Router": "0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d", "PoolFactory": "0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924" }, "tokens": { "ETH": { "decimals": "18", "poolId": "1", "officialERC20": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", "poolAddress": "0x2D958BF57b35fbE5AE865C7956338d02e0B30562" } } } } ``` # Deployment Addresses The deployment address of the BoolSwap-related smart contracts. ## [Alpha Mainnet](/evm-ecosystem/technical-reference/deployment-addresses/alpha-mainnet) # Alpha Mainnet ### Ethereum (Chain ID: 1) #### [`Router`](https://etherscan.io/address/0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d) ``` 0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d ``` #### [`PoolFactory`](https://etherscan.io/address/0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924) ``` 0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924 ``` ### Optimism (Chain ID: 10) #### [`Router`](https://optimistic.etherscan.io/address/0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d) ``` 0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d ``` #### [`PoolFactory`](https://optimistic.etherscan.io/address/0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924) ``` 0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924 ``` ### Binance Smart Chain (Chain ID: 56) #### [`Router`](https://bscscan.com/address/0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d) ``` 0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d ``` #### [`PoolFactory`](https://bscscan.com/address/0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924) ``` 0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924 ``` ### Polygon PoS (Chain ID: 137) #### [`Router`](https://polygonscan.com/address/0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d) ``` 0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d ``` #### [`PoolFactory`](https://polygonscan.com/address/0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924) ``` 0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924 ``` ### zkSync Era (Chain ID: 324) #### [`Router`](https://explorer.zksync.io/address/0x62e78B9C9A6d55C0B9dB554097DB4B9bd4dE6f4d) ``` 0x62e78B9C9A6d55C0B9dB554097DB4B9bd4dE6f4d ``` #### [`PoolFactory`](https://explorer.zksync.io/address/0xEAef1354819Fe385937f83a7a7eD017f36Ef6f56) ``` 0xEAef1354819Fe385937f83a7a7eD017f36Ef6f56 ``` ### BEVM (Chain ID: 1501) #### [`Router`](https://scan.bevm.io/address/0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d) ``` 0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d ``` #### [`PoolFactory`](https://scan.bevm.io/address/0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924) ``` 0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924 ``` ### Base (Chain ID: 8453) #### [`Router`](https://basescan.org/address/0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d) ``` 0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d ``` #### [`PoolFactory`](https://basescan.org/address/0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924) ``` 0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924 ``` ### Arbitrum One (Chain ID: 42161) #### [`Router`](https://arbiscan.io/address/0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d) ``` 0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d ``` #### [`PoolFactory`](https://arbiscan.io/address/0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924) ``` 0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924 ``` ### Avalanche C-Chain (Chain ID: 43114) #### [`Router`](https://subnets.avax.network/c-chain/address/0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d) ``` 0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d ``` #### [`PoolFactory`](https://subnets.avax.network/c-chain/address/0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924) ``` 0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924 ``` ### Linea (Chain ID: 59144) #### [`Router`](https://lineascan.build/address/0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d) ``` 0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d ``` #### [`PoolFactory`](https://lineascan.build/address/0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924) ``` 0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924 ``` ### Scroll (Chain ID: 534352) #### [`Router`](https://scrollscan.com/address/0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d) ``` 0x54162F457d1d5C4d07f067d6B8DB510586AeEE1d ``` #### [`PoolFactory`](https://scrollscan.com/address/0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924) ``` 0x9F7eEf04bf6f7d573829DbC97122ee4Ca9ab3924 ``` # Network Configuration To start building on Bool Network, you need to add the corresponding network's configurations to your development environment, e.g. MetaMask, Hardhat configuration files, etc. In the following, we provide the default configurations for interacting with different environments regarding the Bool chain. ## Testnet #### Bool Beta Testnet: | Variable | Value | | ----------------------------- | --------------------------------------------- | | Network name | Bool Beta Testnet | | RPC URL (http) | | | RPC URL (wss) | wss\://betatest-rpc-node-ws.bool.network | | Chain ID | `481` | | Currency symbol | `tBOL` | | Block explorer URL (optional) | | #### Bool Alpha Testnet: | Variable | Value | | --------------- | ----------------------------------------- | | Network name | Bool Alpha Testnet | | RPC URL (http) | | | RPC URL (wss) | wss\://test-rpc-node-ws.bool.network | | Chain ID | `47` | | Currency symbol | `tBOL` | ## Mainnet #### Bool Alpha Mainnet: | Variable | Value | | --------------- | ------------------------------------------ | | Network name | Bool Alpha Mainnet | | RPC URL (http) | | | RPC URL (wss) | wss\://alpha-rpc-node-ws.bool.network | | Chain ID | `479` | | Currency symbol | `tBOL` | # System Configuration chapter introduces the Bool Network chain parameters to facilitate developers or users to better understand the system. ### Basic Chain Variable Parameters

Variable	Beta Mainnet Value	Beta Testnet Value
Block Time	6 s	3 s
Chain Name	BoolNetwork Beta Mainnet	BoolNetwork Beta Testnet
Token Symbol	BOL	tBOL
Token Decimals	18	18
Total Issuance	1 billion	1 billion
Protocol ID	boolnetwork_beta_mainnet	boolnetwork_beta_testnet
Maximum Block Weight	2000000000000	2000000000000
Block Gas Limit	60000000	60000000
Weight Per Gas	25000	25000
EVM Chain ID	11100	481
Gas fee ratio	50%-miner 20%-burn 30%-treasure	50%-miner 20%-burn 30%-treasure
Existential Deposit	0	0.0000000000000005

### Staking Variable Parameters

Variable	Beta Mainnet Value	Beta Testnet Value
Epoch Duration	100 block	200 block
Sessions Per Era	24	3
Epoch	10 min	10 min
Era	4 h	30 min
Bonding Duration	1 era	1 era
Maximum Nominations	16	16
Maximum Validators	100	100
Maximum Nominators	1000	1000
Minimum Validator Bond	100000 BOL	100000 tBOL
Minimum Validator Bond	100 BOL	200 tBOL

### DHC Variable Parameters

Variable	Beta Mainnet Value	Beta Testnet Value
Incentive Epoch Duration	300 block	600 block
Committee Epoch Blocks	200 block	800 block
Committee Apply Blocks	60 block	300 block
Committee Rvrf Blocks	60 block	100 block
Committee Change Blocks	60 block	300 block
Committee Slot Number	10	10
Committee Maximum Duplicate	3	3
Committee Maximum Members	15	15
Committee Minimum Members	5	5
Committee T,N ratio	gt 1 / 2	ge 2/3
Committee Service Fee	0.1 BOL	1 tBOL
Device Heartbeat Session	10 min	10 min
Device Reward Session	8 h	60 min
Device Minimum Mint Pledge	100000 BOL	20000 tBOL
Device Offline Punish	10 BOL	10 tBOL
Device Maximum Voter	200	3000
Device Force Exit Punish	1000 BOL	1000 tBOL
Device Force Exit Waiting	100 min	100 min
Device Maximum Exit Waiting	1 day	1 day
Device Maximum No Heartbeat	20 min	20 min
Device Minimum Commission	15%	15%
Device Minimum Vote Bond	100 BOL	200 tBOL
Device Owner Minimum Bond	50000 BOL	10000 tBOL
Device Base Reward Rate	10%	10%
Device Minimum Exit Bond Rate	95%	80%
Device Unlock Time	1 day	1 day
Device Base Score	1000000000000	1000
Device Advanced Score	2000000000000	2000

### Govern Variable Parameters

Variable	Beta Mainnet Value	Beta Testnet Value
Govern Preimage Base Deposit	10000 BOL	10000 tBOL
Govern Preimage Byte Deposit	0.001 BOL	0.001 tBOL
Govern Proposal Bond	5 Permill	5 Permill
Govern Proposal Bond Minimum	1 BOL	1 tBOL
Govern Spend Period	1 day	1 day
Govern Maximum Approvals	100	100
Govern Spend Payout Period	30 days	30 days
Referenda Submission Deposit	100 BOL	100 tBOL
Referenda Alarm Interval	1 block	1 block
Referenda Undeciding Timeout	28 days	28 days
Referenda Maximum Queued	100	100
Conviction Vote Locking Period	30 days	30 days
Conviction Maximum Votes	512	512
Treasury Motion Duration	3 days	3 days
Treasury Maximum Proposals	20	20
Treasury Maximum Members	9	9
Treasury Motion Duration	14 days	14 days
Treasury Maximum Proposals	100	100
Treasury Maximum Members	100	100

*** # Testnet {% hint style="info" %} The testnet is for developers' use only. {% endhint %} {% content-ref url="/pages/w4V3AQ9YrJVGxYYdk8c3" %} [Bool Chain](/develop-guide/testnet/bool-chain) {% endcontent-ref %} {% content-ref url="/pages/tYgZIKK6XoLfKNqlt5sI" %} [DHC Nodes](/develop-guide/testnet/dhc-nodes) {% endcontent-ref %} # Bool Chain Bool Chain is developed based on Polkdot Substrate framwork and implements **Nominated Proof-of-Stake (NPoS)** consensus algorithm to improve the overall security of the network. Nominators and Validators are two vital roles in a NPoS network. Nominators are responsible to nominate the most reliable nodes to validate new blocks within the network. Validators refer to nodes that have been nominated by nominators and are allowed to verify new transactions and earn rewards for their contributions to the network security. Developers can follow guides provided in [Node operators](/develop-guide/testnet/bool-chain/node-operators) to run their individual nodes within the Bool Chain, and further become [Validators ](/develop-guide/testnet/bool-chain/validators)to maintain the network consensus. # Node operators ## Node configuration ### Prerequisites Below is a list of standard requirements for running nodes on the Bool chain: 1. **Operating system:** \ Ubuntu 18.04 or Linux Kernel 5.16. 2. **Hardware:** * CPU: 4 Cores * Memory: 16GB RAM * Storage: 1TB SSD/HHD * Network: At least 20Mb bandwidth with an independent IP address ## Node initialization ### Download binaries {% hint style="warning" %} Compiling from binaries is temporarily unsupported since the network is not open-source at the Testnet stage. {% endhint %} ### Using Docker **Docker** is the only avaliable way to operate nodes on Bool chain at the alpha testnet stage. Developers can quickly run nodes through the images posted by Bool team via the following command: ```shell docker run -p 30333:30333 boolnetwork/bnk-node:alpha-testnet --validator --chain=alpha_testnet --name ``` If you prefer to run in the backstage, please add `-d` on docker command. If you prefer to persist the node's data on the host machine, please add`-v ./data:/data` on docker command. If you intend to run an RPC service that is exteranlly accessibe for applications or third-party applicaitions, such as Polkadot.js, please add following flags to run a full node: * `--unsafe-rpc-external`: Listen to all RPC interfaces. * `--unsafe-ws-external`: Listen to all Websocket interfaces. More details can be found be executing the following command: ```shell docker run --rm boolnetwork/bnk-node:alpha-testnet --help ``` ## Examples ### Node initialization ``` 2024-01-30 08:08:26 BoolNetwork Node 2024-01-30 08:08:26 ✌️ version 0.10.0-f53ea677650 2024-01-30 08:08:26 ❤️ by BoolNetwork, 2022-2024 2024-01-30 08:08:26 📋 Chain specification: BoolNetwork Alpha Testnet 2024-01-30 08:08:26 🏷 Node name: grandiose-voyage-2878 2024-01-30 08:08:26 👤 Role: AUTHORITY 2024-01-30 08:08:26 💾 Database: RocksDb at /bool/.local/share/bnk-node/chains/boolnetwork_alpha_testnet/db/full 2024-01-30 08:08:26 ⛓ Native runtime: moonbase-194 (moonbase-2.tx1.au2) 2024-01-30 08:08:31 🔨 Initializing Genesis block/state (state: 0x5e9c…3f30, header-hash: 0x1808…0b78) 2024-01-30 08:08:31 👴 Loading GRANDPA authority set from genesis on what appears to be first startup. 2024-01-30 08:08:36 👶 Creating empty BABE epoch changes on what appears to be first startup. 2024-01-30 08:08:36 🏷 Local node identity is: 12D3KooWFBrtXis73pD5aVbmyRNAGzCKaZ3q9VZFHgPmL3RNDEyH ``` ### Node sync ``` 2024-01-30 08:09:06 No device mining and no deposit 2024-01-30 08:09:06 ⚙️ Syncing 262.4 bps, target=#146111 (3 peers), best: #8016 (0x6811…5d1c), finalized #7788 (0x883a…fe33), ⬇ 82.6kiB/s ⬆ 0.9kiB/s 2024-01-30 08:09:06 [8188] 💸 generated 3 npos voters, 3 from validators and 0 nominators 2024-01-30 08:09:06 [8188] 💸 generated 3 npos targets 2024-01-30 08:09:06 [8188] 💸 new validator set of size 3 has been processed for era 14 2024-01-30 08:09:09 [8788] 💸 generated 3 npos voters, 3 from validators and 0 nominators 2024-01-30 08:09:09 [8788] 💸 generated 3 npos targets 2024-01-30 08:09:09 [8788] 💸 new validator set of size 3 has been processed for era 15 2024-01-30 08:09:10 No device mining and no deposit 2024-01-30 08:09:11 ⚙️ Syncing 233.9 bps, target=#146112 (3 peers), best: #9186 (0x5d6c…2de1), finalized #8988 (0xa05e…64df), ⬇ 71.5kiB/s ⬆ 1.2kiB/s 2024-01-30 08:09:11 [9388] 💸 generated 3 npos voters, 3 from validators and 0 nominators 2024-01-30 08:09:11 [9388] 💸 generated 3 npos targets 2024-01-30 08:09:11 [9388] 💸 new validator set of size 3 has been processed for era 16 2024-01-30 08:09:14 [9988] 💸 generated 3 npos voters, 3 from validators and 0 nominators 2024-01-30 08:09:14 [9988] 💸 generated 3 npos targets 2024-01-30 08:09:14 [9988] 💸 new validator set of size 3 has been processed for era 17 2024-01-30 08:09:14 No device mining and no deposit 2024-01-30 08:09:16 ⚙️ Syncing 268.2 bps, target=#146114 (3 peers), best: #10527 (0x31ca…9b7d), finalized #10240 (0xf654…d810), ⬇ 82.8kiB/s ⬆ 1.1kiB/s 2024-01-30 08:09:16 [10588] 💸 generated 3 npos voters, 3 from validators and 0 nominators ``` ## FAQ #### Why are nodes out of sync? If the number of peers on your node is unstable and occasionally reaches 0, causing normal synchronization, try adding port mapping on your router to your public IP: 30333-> node's internal IP: 30333, and Set the firewall to allow port 30333 to connect.
--- [Next Page](/llms-full.txt/1)