# Quick Start Quick start guide for developing on GEB ## Quick Overview GEB is a theoretical paradigm that aims to address core issues in current blockchain technology by combining Bitcoin's fundamental design principles with new technological innovations, providing a fresh perspective for the development of intelligent cryptocurrencies. ### Here are some problems of the current blockchain technology: * **Energy-Secure Commercial Closed Loop Disruption**: Bitcoin's PoW created a computational power-based value response system forming a complete energy-secure commercial loop. Newer projects switching to PoS disrupt this relationship. * **Consensus Quantification Without True Decentralization**: Bitcoin's PoW is a computing-based, non-sequential filtering process that achieves true decentralization, while newer blockchains using predetermined voting rules lose this self-organizing feature. * **Violation of Individual Decentralization Principles**: Bitcoin's UTXO model ensures each transaction unit's independence, while newer blockchains use centralized account models with global state tree structures, abandoning individual decentralization foundations. ### GEB has some key aspects to solve the problems: #### Four Core Components: * Individual Model: Based on Bitcoin's UTXO model, where each transaction unit maintains independence and sovereignty without relying on global state * λ Calculus: A stateless functional transaction model ensuring distributed computation * Consensus Algorithm: Uses Bitcoin-style Proof of Work for emergent distributed consensus * Consensus Perception Algorithm: Maps external energy input to value output, maintaining energy conservation #### Dual-layer Consensus Architecture: * Mother Consensus: Inherits Bitcoin network's core design for security and stability * Sub Consensus (Agere Consensus): Path for future intelligent development #### Innovative Value: * Strict adherence to conservation of energy principles * Maintains emergent properties of decentralization * Achieves true distributed autonomy * Establishes complete business closed loop **The GEB paradigm advocates for system designs that maintain energy conservation and decentralization properties while enabling advanced functionality through its dual-layer architecture.** ## Network Configurations {% tabs %} {% tab title="GEB Mainnet" %}
ParameterValue
Network nameGEB Mainnet
TypeMainnet
Native Asset SymbolBTC
Decimal18
Chain-ID11501
Explorerhttps://scan.geb.network
https://web3.okx.com/explorer/geb
RPC Endpointhttps://rpc-mainnet-1.geb.network
https://rpc-mainnet-2.geb.network
WebSocket

wss://rpc-mainnet-1.geb.network

wss://rpc-mainnet-2.geb.network

Quick Addhttps://chainlist.org/?search=geb
{% endtab %} {% tab title="GEB Signet" %}
ParameterValue
Network nameGEB Signet
TypeTestnet
Native Asset SymbolBTC
Decimal18
Chain-ID11504
Explorerhttps://scan-signet.geb.network
RPC Endpointhttps://signet.geb.network
WebSocketwss://signet.geb.network
Quick Addhttps://chainlist.org/?search=geb+signet&testnets=true
Faucethttp://faucet-signet.geb.network/
{% endtab %} {% tab title="BEVM Canary Network" %}
ParameterValue
Network nameBEVM Canary
TypePreliminary Mainnet
Native Asset SymbolBTC
Decimal18
Chain-ID1501
Explorerhttps://scan-canary.bevm.io/
RPC Endpointhttps://rpc-canary-1.bevm.io/
https://rpc-canary-2.bevm.io/
WebSocketwss://rpc-canary-1.bevm.io/ws
Quick Addhttps://chainlist.org/?search=1501
Special ReminderThe highest supported Solidity version is 0.8.13.
{% endtab %} {% endtabs %} ## Development Tools You can engage in comprehensive interactions with GEB using the ***Ethereum API*** and ***Substrate API***. We have listed some partnership dev tools [here](/evm-development/integrations) for your quick check. GEB employs **the same account system as Ethereum**, and your mnemonic phrase and private key are interchangeable with your Ethereum account. Consequently, you can use **Metamask** or other wallets fully compatible with Ethereum to interact with GEB. # GEB Consensus The establishment of GEB's Dual Consensus Framework emerged from extensive technological development and careful reflection across multiple stages, resulting in a sophisticated two-layer consensus architecture. **Detailed Analysis:** 1. Mother Consensus - Bridging with Tradition * Incorporates the fundamental design principles of the Bitcoin network * Preserves Bitcoin's highly decentralized consensus mechanism * Maintains the original energy conservation model * Provides a robust and reliable foundation for the GEB ecosystem 2. Sub Consensus - Embracing Innovation * Built around the Agere consensus mechanism * Explores new distributed economic models * Strictly follows the GEB paradigm * Places special emphasis on energy conservation and emergent properties * Establishes theoretical groundwork for sustainable intelligent cryptocurrency development **Through this innovative dual-layer consensus architecture, GEB successfully maintains strong ties with Bitcoin's established framework while forging ahead with intelligent development through the Agere consensus mechanism. This design actively addresses current challenges while remaining adaptable to future developments in the blockchain space.** # Mother Consensus GEB's Mother Consensus implements a sophisticated dual-token consensus model built on Bitcoin, featuring a unique BFT PoS mechanism that combines Aura and GRANDPA consensus algorithms through the Substrate framework. ### Detailed Analysis: 1. BFT PoS Consensus Architecture * Aura for efficient block production * GRANDPA for rapid finality * Integration through Substrate framework * Focus on throughput, security, and consistency * Decentralization through randomized validator selection 2. Bitcoin Staking Dual-Token Model(L-BTC) * Non-custodial Bitcoin staking through Lightning Network Layer 2 * Energy conservation principle in GEB token generation * Dual-token coordination between BTC and GEB tokens * Random validator selection with minimum staking thresholds * Secure non-custodial staking mechanism * Time-based pledge system aligned with energy conservation ### Equity Distribution： Two deployment mechanisms for the consensus of mothers have the following revenue distribution methods: Participants in PoS Stake, whether validators or nominators (ordinary users staking), can only receive BTC Gas rewards The validators in PoS Stake are the same as the validators of L-BTC (validators need to bind their EVM address). These validators can accept both user stakes from L-BTC and their own stakes, enabling them to earn GEB rewards in L-BTC Stake. **The Mother Consensus architecture successfully integrates Bitcoin's proven security model with modern PoS mechanisms, creating a robust and efficient system. Through its dual-token model and sophisticated consensus mechanisms, it achieves a balance between security, decentralization, and performance while maintaining strong economic incentives for participants.** ### Practice: {% content-ref url="/pages/kARRHA8MZ0mtK4ZFVvuB" %} [Validator](/build/validator) {% endcontent-ref %} {% content-ref url="/pages/8I2bI7Imdzgwch1qXYcq" %} [L-BTC Validator Operation](/build/validator/l-btc-validator-operation) {% endcontent-ref %} {% content-ref url="/pages/nwpuAPO983iH9hFOiX66" %} [Stake L-BTC](/use/earn-usdgeb/stake-l-btc) {% endcontent-ref %} # Sub Consensus(Agere) The Agere consensus mechanism focuses on solving the quantification of contributions and incentive distribution in intelligent multi-agent systems, establishing a hierarchical resource allocation mechanism while strictly adhering to the principle of energy conservation. ## **Detailed Analysis:** 1. Basic Architecture Design * GEB production mechanism based on agent workload * Task contribution measurement system * Balance between subjective scoring and objective constraints * Direct mapping between equity tokens (GEB) and contributions 2. Key Evaluation Elements * Scoring (w): Capturing non-explicit factors in complex scenarios * Equity staking (s): Introducing credibility screening through economic constraints * Consensus mapping function: Converting subjective scores into allocation results 3. Hierarchical Allocation Mechanism * Cross-system resource allocation: System-level scoring based on multi-dimensional indicators * Internal resource allocation: Agent-level scoring based on performance metrics * Three-step mapping mechanism: * Consensus score generation * Score correction * Emission allocation calculation **Through this carefully designed hierarchical allocation mechanism, the Agere consensus successfully achieves rational resource distribution both between and within systems, ensuring overall system fairness and consistency while maintaining individual autonomy. This mechanism combines staking weights with scoring matrices to ultimately achieve precise equity token allocation for each agent.** ## **Practice:** {% content-ref url="/pages/sJaW7D3GJpv9TI8EukPx" %} [BitAgere](/build/bitagere) {% endcontent-ref %} # Learn This module mainly explains to users the conceptual issues that may be encountered during the use of GEB and provides a navigation collection of other relevant content. # BitAgere Guide ## Auditor: {% content-ref url="/pages/gX2wxQ0QAFGBMADoVcQK" %} [RelayAgere](/build/bitagere/relayagere) {% endcontent-ref %} {% content-ref url="/pages/WvMol2ypIKniGmj2wKfk" %} [Agere Auditor](/build/bitagere/agere-auditor) {% endcontent-ref %} {% content-ref url="/pages/r6YlaG2RytjmnKPFEZnb" %} [Auditor Reference Concepts](/learn/bitagere-guide/auditor-reference-concepts) {% endcontent-ref %} ## Executor: {% content-ref url="/pages/gX2wxQ0QAFGBMADoVcQK" %} [RelayAgere](/build/bitagere/relayagere) {% endcontent-ref %} {% content-ref url="/pages/S99JhxqYVSb3JefrGB9T" %} [Agere Executor](/build/bitagere/agere-executor) {% endcontent-ref %} {% content-ref url="/pages/rPy1kvS3QjoT0V3GRuRw" %} [Executor Reference Concepts](/learn/bitagere-guide/executor-reference-concepts) {% endcontent-ref %} # Auditor Reference Concepts ### **Auditor Basic Concepts:** Auditors are responsible for evaluating the quality of GEB-related transactions submitted by executors by analyzing on-chain transaction records. Only transactions that comply with GEB specifications and execute successfully are deemed valid. #### **Incentive Mechanism** * Rewards correlate with evaluation fairness: higher authenticity in evaluation leads to higher incentives, while malicious/arbitrary scoring significantly reduces earnings * Fairness is guaranteed by the agere consensus mechanism, with final determinations made through collaborative evaluation by multiple auditors * Stake amount determines competition priority, with the network continuously rewarding the top 64 auditors by stake amount * Auditors enjoy higher fixed incentives than executors; dropping below the top 64 positions results in loss of eligibility (can continue participating as executors) ### Auditor Performance Concepts: **aTrust (Auditor Trust):** * **Meaning:** aTrust represents a score reflecting the confidence in an auditor's behavior. Its full name is Auditor Trust. * **Calculation:** It's calculated by directly applying consensus-based trimming and summing the results. For example, if a validator assigns normalized scores of 0.7 and 0.3 to two executors, and the consensus on those executors is 0.5 and 0.5, respectively, then the validator's trust is the sum of `min(weight, consensus)` for each executor. In this case, it's 0.5 + 0.3 = 0.8. A value closer to 1 is better, with 1 being the ideal state. * **Troubleshooting:** If this value deviates significantly from 1, observation is needed. If it consistently decreases, check for updates in the corresponding `agere` codebase, and verify the health of your VPS network and scripts. **Dividend:** * **Meaning:** Represents the proportion of earnings an auditor receives. The sum of all auditor dividends equals 1. * **Calculation:** It's calculated by combining the difference between the auditor's scores for Executors and the consensus-trimmed values, along with cumulative factors like staking and updation time. Think of it as dividends being earned from the Executors being scored. The key factors to focus on during online periods are `aTrust` and `Total Stake`, or you can customize your scoring script. # Executor Reference Concepts ### **Executor Basic Concepts:** #### **Core Responsibilities** * Identify and submit GEB-related Bitcoin transactions to the network * Increase transaction processing priority by paying gas fees * Bear the risk of transaction failure (gas fees must still be paid for unsuccessful transactions) **Incentive Mechanism** * **Revenue Source:** Number of successfully submitted and verified valid transactions × reward coefficient per transaction * **Gas Strategy:** Paying higher gas can increase transaction ordering priority, but costs and benefits must be balanced * **Zero-sum Competition:** For identical transactions within the same block, only the first high-gas transaction receives rewards, other executors' gas payments are non-refundable ### Executor performance concepts: **Trust:** * **Meaning:** Trust represents a score reflecting the confidence in an executor's behavior audited by auditors. Its full name is Executor Trust. * **Calculation:** Weighted average according to the stake value of the auditor. * **Troubleshooting:** If this value deviates significantly from 1, observation is needed. If it decreases, check for updates in the corresponding `agere` codebase, run with more tips and remove `time.sleep` in miner.py, and verify the health of your VPS network and scripts. **Incentives:** * **Meaning:** Represents the proportion of earnings an executor receives. The sum of all executor incentives equals 1. * **Calculation:** It's calculated by the difference of Trust. # Build # Validator In the GEB framework, validators are the core participants of the blockchain network, primarily responsible for the following tasks: 1. **Block Production**: Generating new blocks through consensus algorithms (such as Aura, Babe) to maintain the continuity of the chain. 2. **Transaction Validation**: Checking the legitimacy of transactions to prevent double-spending or invalid transactions from being included in the chain. 3. **Network Security**: Participating in network consensus by staking tokens (Staking) to ensure the irreversibility and attack resistance of the chain. 4. **Finality Confirmation**: In the GRANDPA consensus, validators vote to confirm the final state of blocks, ensuring the consistency of the chain. Meanwhile, GEB has pioneered a dual-token staking model, using both L-BTC and GEB tokens for validator staking. This allows users to contribute to chain security while simultaneously increasing their returns. # Wasm Operation ## 1. Prerequisite ### 1.1 VPS Requirements The simplest way is to use a cloud server. You can freely choose any hosting provider. #### 1.1.1 Mainnet Hardware Configuration Taking AWS as an example, GEB mainnet recommended configuration should not be lower than: * CPU: 4 cores * Memory: 16GB * Bandwidth: 50Mbps * Disk: SSD 300GB+ * Operating System: Ubuntu 22.04+ **Cloud servers need to open p2p port (default port=30333) to increase connectivity** ``` To open ports on AWS, you typically configure rules in the Security Group. Follow these steps: 1. Log in to AWS Management Console and go to EC2 service 2. In the navigation pane, select "Security Groups" 3. Select the security group you want to modify 4. Select the "Inbound Rules" tab, then click "Edit inbound rules" 5. Click "Add rule" 6. In the "Type" dropdown, select the protocol type (e.g., TCP) 7. In "Port range", enter 30333 8. For "Source", you can choose: - Allow any IP access (0.0.0.0/0) - Allow only specific IP ranges (enter IP/mask format) 9. Click "Save rules" For example, to allow all IPs through TCP port 30333: Type: TCP Port range: 30333 Source: 0.0.0.0/0 ``` ``` To open port 30333 on Alibaba Cloud, configure the security group's inbound rules as follows: 1. Log in to Alibaba Cloud Console and go to "ECS" 2. Find the ECS instance that needs port opening, click the instance ID 3. In the left menu, select "Security Groups" 4. In "Security Group Rules" tab, find "Inbound" rules, click "Quick Add" 5. In the "Security Group Inbound" window: - Rule Direction: "Inbound" - Authorization Policy: "Allow" - Protocol Type: "Custom TCP" - Port Range: "30333/30333" - Authorization Object: "0.0.0.0/0" (allow all IPs) or specify IP range 6. Click "OK" to complete After adding the inbound rule, the service can be accessed through the instance's public IP and port 30333. ``` ### 1.2 Installing GEB Using Docker #### 1.2.1 Configuration File For validator nodes, we recommend the following configuration: Replace "Your-Node-Name" with your node name ```json { "chain": "mainnet", "log-dir": "./log", "enable-console-log": false, "no-mdns": true, "validator": true, "unsafe-rpc-external": true, "offchain-worker": "when-authority", "rpc-methods": "unsafe", "log": "info,runtime=info", "port": 30333, "rpc-port": 8087, "pruning": "archive", "db-cache": 2048, "name": "Your-Node-Name", "base-path": "data", "keystore-path": "keystore", "bootnodes": [], "telemetry-url": "wss://telemetry.geb.network/submit 1" } ``` After the node starts successfully, you can see your node on [GEB Telemetry](https://telemetry-mainnet.geb.network), subsequent service will be terminated. For Docker installation, refer [here](https://blog.csdn.net/qq_38156743/article/details/130401015). #### 1.2.2 Using Docker Image Place the above configuration file in the current directory, named `config.json`. Run the following command: ```json { "chain": "mainnet", "log-dir": "/log", "enable-console-log": false, "no-mdns": true, "validator": true, "unsafe-rpc-external": true, "offchain-worker": "when-authority", "rpc-methods": "unsafe", "log": "info,runtime=info", "port": 30333, "rpc-port": 8087, "pruning": "archive", "db-cache": 2048, "name": "Your-Node-Name", "base-path": "/data", "keystore-path": "/keystore", "bootnodes": [] } ``` Chain options: * chain=mainnet: GEB mainnet * chain=signet: GEB signet (new test network started with BEVM v0.3.0) Run the following command to start the node in the background: ```bash sudo docker pull btclayer2/bevm:v0.3.0 sudo docker run -d --restart always --name bevm-node \ -p 8087:8087 -p 30333:30333 \ -v $PWD/config.json:/config.json -v $PWD/data:/data \ -v $PWD/log:/log -v $PWD/keystore:/keystore \ btclayer2/bevm:v0.3.0 /usr/local/bin/bevm \ --config /config.json ``` Enter the container: ```bash docker exec -it bevm-node /bin/bash ``` The parameters correspond to those in the configuration file. For background running Docker, you can check logs with: ```bash tail -f log/bevm.log # View all logs ``` When the logs show block synchronization starting, it indicates the node has started successfully: ``` 2024-01-30 06:42:24 ✨ Imported #2229 (0x835e…88ea) 2024-01-30 06:42:27 💤 Idle (4 peers), best: #2229 (0x2823…340a), finalized #2227 (0xabfa…613d), ⬇ 16.5kiB/s ⬆ 17.9kiB/s 2024-01-30 06:42:30 ✨ Imported #2230 (0x1dde…0ce9) 2024-01-30 06:42:30 ♻️ Reorg on #2230,0x1dde…0ce9 to #2230,0x937b…545e, common ancestor #2228,0xf384…0db5 2024-01-30 06:42:30 ✨ Imported #2230 (0x937b…545e) 2024-01-30 06:42:32 💤 Idle (4 peers), best: #2230 (0x937b…545e), finalized #2228 (0xf384…0db5), ⬇ 17.8kiB/s ⬆ 18.8kiB/s ``` If you need to use RPC service externally, add `rpc-external: true` to the configuration file. When configuring, it's recommended to change the `name` item in the configuration file. Port mapping must be consistent with `config.json`, otherwise RPC will not work normally. ### 1.3 Direct Binary Download(Skip if you use Docker) Download the compiled binary from [GitHub releases](https://github.com/btclayer2/BEVM/releases). #### Sync to Latest Chain State Start syncing the blockchain with this command: ```bash $ ./bevm-v0.3.0 --chain=mainnet --pruning=archive --name="Your Node Name" # After syncing completes, restart in validator mode: $ ./bevm-v0.3.0 --chain=mainnet --validator ``` Or start directly in validator mode for syncing: ```bash # Using --validator will automatically enable archive mode (--pruning=archive) $ ./bevm-v0.3.0 --chain=mainnet --validator ``` Note: Make sure to wait for synchronization to complete and set up Session Keys before letting the node participate in election. > **If synchronization is abnormal, ensure system time matches network time, delete the database, and resync.** ### 1.4 Creating GEB Account You can create a GEB account on [GEB Wallet](https://wallet.geb.network) and transfer GEB to this account for transaction fees and future staking costs. ### 1.5 S**et up on-chain identity(Important)** The on-chain identity must be set to match your node name.
## 2. Registering Validator Node After creating a GEB account, you can register as a validator node on [GEB Wallet](https://wallet.geb.network/) **Note:** (1) Validator node names only support numbers and letters (case-sensitive) (2) Register transaction will charge 100 GEB whether successful or not Route: Network>Staking>Accounts>Validtors
(3) Each GEB account can only register once. (4) Before registering, ensure you have sufficient balance for transaction fees and self-voting amount (1000 GEB in the example). (5) Newly registered nodes are automatically nominated for election, no additional operation needed. (6) Besides initial staking during registration, you can stake more through **voting**.The maximum stake you can receive is **10 times** your self-staked amount. Once the total stake reaches this limit, you will no longer be eligible to receive votes. (7) After the election period ends, the top 40 nodes *(17 limits now)* (parameter set through governance) by total stake will become validators participating in consensus. ## 3. Setting Session Keys You can generate Session Keys by executing this command on your node machine: Install curl: apt install curl ```bash $ curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:$YOUR_RPC_PORT ``` Where `YOUR_RPC_PORT` is the port specified by `rpc-port` when starting the node, default is 8087. Example response: ```json { "jsonrpc":"2.0", "result":"0xcf888ade403573be237e2af023c5b5ff1e4fd24cb96893b034ca8d616fe551c96cccd879274db47800e2a035adef9d7657ee2579ceaf25a3bc507931e5e5241558764dd425290713cb62101ca62edf2bcfbeedc38b3ed36db080d0bb9561ba507a14389a5dbd1b5708314fb1bc204c384c41b4389e7add1b6bec10490ff52b7b", "id":1 } ``` The `result` field is your Session Keys. Set them through `setKeys` in **Developer>Extrinsic**: * Currently, `proof` can be set to `0x`.
## 4. Binding EVM Address (Optional) Binding an EVM address is prerequisite for becoming an L-BTC staking mining validator node (can accept LBTC token staking, participate in GEB mining). Validator nodes not participating in L-BTC staking mining (i.e., without bound EVM address) can still receive BTC gas rewards and GEB transaction fee rewards(**Different from the GEB assigned with the Mother Consensus**).
## 5. Checking Validator Node Setup ```bash curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "xstaking_checkCandidate", "params":["5Uix8A8MpxJK8q2GMbSkENL9obg6gd4S6eJD9H5DErtA94i8"]}' http://localhost:8087 ``` Four "true" values in response indicate complete setup: ```json {"jsonrpc":"2.0","result":[true,true,true,true],"id":1} ``` These four values represent: 1. Whether nominated (validator.isChilled is false) 2. Whether meeting minimum voting amount (self-vote at least 100 GEB and total votes at least 1000 GEB) 3. Whether Session Keys are set 4. Whether participating in LBTC staking mining ## 5. Backup Node Since improper node deployment causing block anomalies will be penalized, you can deploy backup nodes. Copy the same config.json configuration and keys, just change **"validator=false"**. Start backup node in "pruning=archive" mode. This way, when the main node has issues, the backup can take over to avoid penalties. ## 6. Verifying Block Production Validator rotation period: Era = 4 Session = 4 \* 1 hour = 4 hours After setup, it takes up to 4 hours for new validators to produce blocks. After being elected validator, seeing `Prepared block for proposing at ...` in logs indicates successful block production: ``` 2024-01-30 17:39:42:008 INFO tokio-runtime-worker sc_basic_authorship::basic_authorship 🙌 Starting consensus session on top of parent 0xe05e784c7198ff0719411ed75fe3a207f7fdc89b0ed5e3fbae75a3f2a7bf5504 2024-01-30 17:39:42:021 INFO tokio-runtime-worker sc_basic_authorship::basic_authorship 🎁 Prepared block for proposing at 4002 (13 ms) [hash: 0x236a33a2f071abb9f0f4ee31a367b509c560018807bf21b454ea0d368cd8812a; parent_hash: 0xe05e…5504; extrinsics (4): [0x8d22…b8ad, 0x9b60…0aa1, 0xccdc…3742, 0x56df…c0a3] 2024-01-30 17:39:42:027 INFO tokio-runtime-worker babe 🔖 Pre-sealed block for proposal at 4002. Hash now 0x4c4eec78a6f480a337f2ddd79c5f839959d8e082e3ec9f4adc7f640f70d66024, previously 0x236a33a2f071abb9f0f4ee31a367b509c560018807bf21b454ea0d368cd8812a. ``` ## 7. Validator Withdrawal ### 7.1 Forced Withdrawal When a validator's reward pool is penalized to 0 or other penalties occur, the validator is kicked out of the current validator set and becomes withdrawn. To rejoin staking, manual nomination is required. ### 7.2 Voluntary Withdrawal
### 7.3 Manual Nomination
## 8. Important Notes * Validator election occurs every 1 era(4 hours). * If node self-stake is less than 100 GEB or total votes less than 1000 GEB, will be forced to withdraw during validator election. * Candidate status validators neither receive rewards nor penalties. * The additional fee for rebond and validate (i.e., candidacy) is 1 GEB, while the additional fee for registration is 100 GEB. * To limit the frequency of rebonding, it is stipulated that only one rebond operation is allowed every 3 days (i.e., 43200 blocks). * Validators who wish to unstake their tokens are subject to a 30-day (432,000 blocks) freezing period, while nominators have a 3-day (43,200 blocks) freezing period. After the freezing period has elapsed, a thawing transaction must be sent to reclaim the staked voting amount. ## 9. Node Penalties GEB issues rewards each session while penalizing potentially malicious nodes. Penalty types generally include double-signing and node offline. Once malicious behavior is detected, the BTC gas rewards in the offending node's reward pool will be penalized to the Treasury according to the reported malicious coefficient: `penalty = max(reward_pot_balance * F, minimum_penalty)` Where: * `penalty`: BTC gas amount to be penalized * `reward_pot_balance`: Node's BE reward pool amount * `F`: Penalty coefficient, calculated by babe and im-online modules: * babe: [Node double-signing penalty details](https://wiki.polkadot.network/docs/en/learn-staking/#babe-equivocation) * im-online: [Node offline penalty details](https://wiki.polkadot.network/docs/en/learn-staking/#unresponsiveness) * `minimum_penalty`: Minimum penalty value, meaning each penalty is at least `minimum_penalty`. **GEB validator node misconduct does not penalize GEB principal and GEB transaction fees, only penalizes BTC gas in the reward pool.** When a node's reward pool is completely penalized, the node will be forced to withdraw. ```typescript if penalty > reward_pot_balance { // force the validator(offender) to be chilled } ``` ## 10. Validator Rewards Withdrawal (BTC and GEB) ### 10.1 Wallets For wasm account: (need to install ) For evm account: Metamask Quick Add: [https://chainlist.org](https://chainlist.org/?search=geb\&testnets=false) ### 10.2 Check BTC and GEB Balance To Check BTC balance and GEB balance, use the respective interfaces in the wallet. Router：Accounts>My accounts>Find ⬇️ in your account component
### 10.3 Claim BTC and GEB from Validator Spot to Wasm Account Use the claim function in the wallet interface to transfer rewards from validator spot to your wasm account.
### 10.4 Deposit BTC from Wasm to EVM Operation path: **Developer → Extrinsics → Submission ,** the specific operation is as shown in the screenshot. Make sure to select the designated pallet and the method to invoke. {% stepper %} {% step %} **balanceOnGEB** Enter the amount you want to transfer, paying attention to the precision value. For example, if you want to transfer **10,000 sats**, you should enter **100000000000000**. {% endstep %} {% step %} **evmAccount** Enter the **EVM address** where you want to receive BTC. {% endstep %} {% step %} **Submit** **Transaction**
{% endstep %} {% endstepper %} ### 10.5 Deposit GEB from Wasm to EVM {% content-ref url="/pages/lYZeHK0f9MR2xR52clfC" %} [Transfer(EVM<-->Wasm)](/use/bridge/transfer-evm-less-than-greater-than-wasm) {% endcontent-ref %} ## 11. Multi-signature Account as Validator Node The validator node operations for multi-signature accounts are the same as for regular accounts, with the difference being in multi-signature account interactions. ### Multi-signature Account Reference Documents * * * Creating a multi-signature account: (need to install ) # L-BTC Validator Operation {% hint style="success" %} **Prerequisites**: You have run a [PoS(Wasm) Validator](/build/validator/wasm-operation) Before. {% endhint %} ## Method one: Running an LND node and generating an address with GEB Hub. {% stepper %} {% step %} ### Complete the related steps for User Operation In the mother consensus mechanism, the staking for validators is divided into two parts: L-BTC staking and Wasm's GEB staking. Therefore, you need to set up an L-BTC node. We provide a quick [guide](/use/earn-usdgeb/stake-l-btc) to help you quickly set up this part. You need to obtain the EVM address mapped by the AA wallet for binding in the third step. {% endstep %} {% step %} ### Complete the preparation and deployment of the PoS Validator This [step](/build/validator/wasm-operation) is essential to becoming a consensus validator. Please follow it strictly. {% endstep %} {% step %} ### Complete the wallet's EVM address to the Wasm wallet Binding an EVM address is a prerequisite for becoming an L-BTC staking mining validator node (can accept LBTC token staking, and participate in GEB mining). Validator nodes not participating in L-BTC staking mining (i.e., without bound EVM address) can still receive BTC gas rewards and GEB transaction fee rewards(**Different from the GEB assigned with the Mother Consensus**). {% hint style="success" %} It is recommended that validators bind the EVM address generated within the GEB Hub to facilitate the claiming process. {% endhint %}
{% endstep %} {% step %} ### Set Commission on the GEB Hub {% hint style="info" %} Recommend commission value > 10% {% endhint %}
{% endstep %} {% endstepper %} ## Method two: Directly using a personal EVM address without involving LND-related content. {% stepper %} {% step %} ### Complete the wallet's EVM address to the Wasm wallet Binding an EVM address is prerequisite for becoming an L-BTC staking mining validator node (can accept LBTC token staking, participate in GEB mining). Validator nodes not participating in L-BTC staking mining (i.e., without bound EVM address) can still receive BTC gas rewards and GEB transaction fee rewards(**Different from the GEB assigned with the Mother Consensus**).
{% endstep %} {% step %} ### Set Commission on the GEB Explorer On the [explorer](https://scan-mainnet.bevm.io/address/0x4f76Ba62c9Ca96bFCEc94DD29FEaEcBCFeB26ECe?tab=write_proxy), call `setAllocRatio` parameter: **(100 means 1%, 10000 means 100% )**
{% endstep %} {% endstepper %} # BitAgere The BitAgere network introduces an innovative agere governance system that balances decentralization with efficient management through clearly defined roles, rules, and reward mechanisms. Let's examine how this system operates in detail. ### Creation and Basic Rules * **Creator Role**: The agere creator (Owner) is responsible for setting objectives, establishing governance rules, and providing necessary technical resources (such as running programs, code repositories, and technical documentation). * **Immunity Period**: Newly registered ageres enjoy a 7-day protection period during which they are immune from elimination. * **Elimination Rules**: * Agere total is limited to 64, when a new agere registers, the lowest-scoring agere will be deregistered. * If multiple ageres tie for the lowest score, the earliest registered agere will be deregistered. ### Role Division Within Agere Particpants * **Auditors**: * Auditors are responsible for scoring agere operations, with a maximum capacity of 64. * Auditors are selected through stake-based ranking; * **Auditors falling out of the top 64 in stake will be eliminated.** * Eliminated auditors can continue participating as executors. * Auditors must register as delegate representatives to accept user stakes. * **Executors**: * Executors provide computational resources and other contributions, serving as the agere's execution entities. * New executors enjoy a 7-day protection period, ensuring they won't be immediately eliminated. ### Internal Elimination Rules Agere participants are eliminated through pruning scores, which are positively correlated with received incentives - lower incentives result in lower scores. The process identifies participants with the lowest pruning scores outside the protection period for elimination. In case of tied lowest scores, the earliest registered participant is eliminated. If all participants are in the immunity period, the immune participant with the lowest pruning score is eliminated. In case of tied lowest scores among immune participants, the earliest registered immune participant is eliminated. If registration times are also tied, the immune participant with the lower ID is eliminated. ### Agere Registration Restrictions **Agere Quantity Limits**: * BitAgere network supports a maximum of 64 ageres. * When the agere limit is reached, newly registered ageres will replace the lowest-scoring agere. **Participant Limits**: * Each agere allows a maximum of 256 participants. **Registration Requirements**: * Agere registrants must provide detailed operational objectives, rule explanations, and necessary technical resources. * Auditors must complete required staking. ### Incentive Mechanism #### Reward Model * **Agere Creator Rewards:** Directly receives a fixed proportion of agere rewards * **Auditor Rewards**: Auditors receive rewards based on how closely their scoring aligns with network consensus. * **Executors Rewards**: Executors' rewards are directly affected by their task completion quality and auditor scoring. ### Reward Distribution Process 1. **Weight Upload**: * Each auditor maintains a weight vector representing their evaluation of all operators' performance. * Auditors periodically upload weight vectors to the chain (every 100 blocks). 2. **Weight Matrix Formation**: * System integrates all auditor scoring vectors to generate a network-wide weight matrix used for reward calculations. 3. **Reward Calculation**: * System calculates each participant's reward proportion by combining weight matrix and stake amounts. * Reward distribution cycle (Tempo) completes every 360 blocks. 4. **Reward Distribution**: * Rewards are automatically distributed on-chain, directly injected into participants' stakes, requiring manual collection via wallet. * If there are regular stakers, remaining rewards after auditor portions are redistributed based on stake ratios. # RelayAgere ## Agere 1 - RelayAgere RelayAgere is an agere in Alpha stage, with the primary goal of building an Oracle network to provide Oracle services for any blockchain. Currently, this agere has implemented the Relay functionality for the GEB network, assisting GEB in implementing Bitcoin light node functionality. This article uses Relayagere as a case study to provide a detailed explanation of agere characteristics. ### Auditor #### **Core Responsibilities** Auditors are responsible for evaluating the quality of GEB-related transactions submitted by executors by analyzing on-chain transaction records. Only transactions that comply with GEB specifications and execute successfully are deemed valid. #### **Incentive Mechanism** * Rewards correlate with evaluation fairness: higher authenticity in evaluation leads to higher incentives, while malicious/arbitrary scoring significantly reduces earnings * Fairness is guaranteed by the agere consensus mechanism, with final determinations made through collaborative evaluation by multiple auditors * Stake amount determines competition priority, with the network continuously rewarding the top 64 auditors by stake amount * Auditors enjoy higher fixed incentives than executors; dropping below the top 64 positions results in loss of eligibility (can continue participating as executors) ### **Executor** #### **Core Responsibilities** * Identify and submit GEB-related Bitcoin transactions to the network * Increase transaction processing priority by paying gas fees * Bear the risk of transaction failure (gas fees must still be paid for unsuccessful transactions) **Incentive Mechanism** * **Revenue Source:** Number of successfully submitted and verified valid transactions × reward coefficient per transaction * **Gas Strategy:** Paying higher gas can increase transaction ordering priority, but costs and benefits must be balanced * **Zero-sum Competition:** For identical transactions within the same block, only the first high-gas transaction receives rewards, other executors' gas payments are non-refundable ### **Competition Mechanism** * **Gas Bidding Principle:** Transactions are ordered by descending gas fees, with high gas prioritized * **Hardware Performance Impact:** Executors with lower network latency can broadcast high-gas transactions faster * **Risk Hedging:** Need to predict transaction repetition probability to avoid excessive gas payments leading to losses Key Process Example When executors A, B, and C simultaneously submit **identical transactions** to the current block: 1. Executor A pays **0.01 GEB gas** 2. Executor B pays **0.02 GEB gas** 3. Executor C pays **0.015 GEB gas** → System prioritizes Executor B's transaction, A and C's gas fees are deducted with no reward ### Role Compare | | **Auditor** | **Executor** | | -------------------- | ----------------------------------------------------- | ----------------------------------------------------------------- | | **Central Task** | adjudication of transaction validity | transaction identification and submission | | **Revenue model** | stable staking rewards + evaluation incentives | high-risk trade success reward | | **Cost Type** | opportunity cost (staking capital lock-up) | sunk cost (failed gas loss) | | **Key Competencies** | depth of protocol understanding + evaluation accuracy | off-chain transaction detection speed + gas strategy optimization | # Agere Auditor ### Transfer GEB from EVM to Wasm {% content-ref url="/pages/lYZeHK0f9MR2xR52clfC" %} [Transfer(EVM<-->Wasm)](/use/bridge/transfer-evm-less-than-greater-than-wasm) {% endcontent-ref %} ## Auditor Overview {% content-ref url="/pages/gX2wxQ0QAFGBMADoVcQK" %} [RelayAgere](/build/bitagere/relayagere) {% endcontent-ref %} ## Quick Join RelayAgere {% hint style="success" %} Recommended System: Ubuntu 22.04 LTS + {% endhint %} ### **Preparation Work** {% stepper %} {% step %} **Clone the repository** ```bash git clone https://github.com/GEBcore/RelayAgere.git && cd RelayAgere ``` {% endstep %} {% step %} **Install the dependencies** ```bash bash install.sh ``` {% endstep %} {% step %} **Activate the virtual environment** ```bash source .venv/bin/activate ``` {% endstep %} {% step %} **Create Wallet** ``` ./wallet.sh ``` {% hint style="info" %} The process will generate two wallets: **a cold wallet** and **a hot wallet**. \ If you choose to create wallets, there will generate two wallets: **a cold wallet** and **a hot wallet**. \ In the current script, the cold wallet is associated with the hot wallet automatically. The following operations will require using **the name of the cold wallet**. Both the **cold and hot wallets** are very important, and you need to securely save the wallet's mnemonic phrase to prevent loss. {% endhint %} {% hint style="success" %} You need to import both your **cold wallet** and **hot wallet** into the [BEVM Wallet](https://wallet.bevm.io/) for easier subsequent operations. {% endhint %} {% endstep %} {% step %} **Register to the agere** {% hint style="success" %} Please [deposit](https://wallet.bevm.io/) GEB token larger than register fee (at least 10 tokens ) to your cold wallet to register and join the agere. {% endhint %} {% hint style="info" %} Your stake amount must rank in the top 64 in the agere to be eligible to run as an auditor. {% endhint %} {% hint style="success" %} **After registration, you need to wait for the `auditor permit` parameter to become `yes`. *****The waiting time is one epoch, approximately 10 minutes.*** {% endhint %} ```bash ./register.sh ``` {% endstep %} {% step %} **Register as a delegate** After your registration, if you want to work as an auditor, you need to register as a delegate on GEB Wallet. {% hint style="success" %} If you want to become an auditor, you'll also need to stake sufficient tokens in your hot address. {% endhint %} *Router: Agere->User->Agere Participants->Delegate*
The first option selects the cold address, and the second option selects the corresponding hot address.
{% endstep %} {% step %} ### Check your auditor permit Open GEB Wallet, ensure that the **auditor permit** is set to **yes**, and then proceed with the following operations. Router：Agere*->User->*Agere *Participants->Your* Agere *Pariticipants status->auditor permit*
{% endstep %} {% endstepper %} ### Run an Auditor Progarm {% hint style="info" %} **Before running the program, you need to deposit some tokens to your hot address as transaction fees so the program can send transactions normally.** {% endhint %} **Query your wallet balance** ```bash ./get_balance.sh ``` #### **Running as an Auditor** {% stepper %} {% step %} **Stake your tokens to become an auditor** ```bash ./stake.sh add ``` {% endstep %} {% step %} **Run the auditor program** ```bash ./auditor.sh -d ``` {% endstep %} {% step %} ### Check Auditor run status ``` tail auditor.log ``` The above code allows you to view the most recent auditor logs, but to ensure that the auditor program is truly running successfully on the agere, you need to wait until the **auditor status** parameter changes to **active**. **This will probably take about 10-60 minutes.**
{% endstep %} {% endstepper %} ### **Set Commission** Maximum value is 11796, calculate "commission = take/65535\*100%" **Increase(required to be greater than previous)**
**Decrease(required to be less than previous)**
### **Claiming Rewards** Except for agere creators, other users' BitAgere incentives are stored in stakes and need to be unstaked to receive actual tokens. **Using scripts to unstake** ```bash ./stake.sh remove ``` **Unstaking via BEVM Wallet** *Router: Agere->User Dashboard->Agere Participants->Unstake*
# Agere Executor ### Transfer GEB from EVM to Wasm {% content-ref url="/pages/lYZeHK0f9MR2xR52clfC" %} [Transfer(EVM<-->Wasm)](/use/bridge/transfer-evm-less-than-greater-than-wasm) {% endcontent-ref %} ## Executor Overview {% content-ref url="/pages/gX2wxQ0QAFGBMADoVcQK" %} [RelayAgere](/build/bitagere/relayagere) {% endcontent-ref %} ## Quick Join RelayAgere {% hint style="success" %} Recommended System: Ubuntu 22.04 LTS + {% endhint %} ### **Preparation Work** {% stepper %} {% step %} **Clone the repository** ```bash git clone https://github.com/GEBcore/RelayAgere.git && cd RelayAgere ``` {% endstep %} {% step %} **Install the dependencies** ```bash bash install.sh ``` {% endstep %} {% step %} **Activate the virtual environment** ```bash source .venv/bin/activate ``` {% endstep %} {% step %} **Create Wallet** ```bash ./wallet.sh ``` {% hint style="info" %} If you choose to create wallets, there will generate two wallets: **a cold wallet** and **a hot wallet**. \ In the current script, the cold wallet is associated with the hot wallet automatically. The following operations will require using **the name of the cold wallet**. Both the **cold and hot wallets** are very important, and you need to securely save the wallet's mnemonic phrase to prevent loss. {% endhint %} {% hint style="success" %} You need to import both your **cold wallet** and **hot wallet** into the GEB Wallet for easier subsequent operations. {% endhint %} {% endstep %} {% step %} **Register to the agere** {% hint style="success" %} Please [deposit](https://wallet.bevm.io/) GEB token larger than register fee (at least 10 tokens ) to your cold wallet to register and join the agere. {% endhint %} ```bash ./register.sh ``` {% endstep %} {% endstepper %} ### Run an Executor Progarm {% hint style="warning" %} **Before running the program, you need to deposit some tokens to your hot address as transaction fees so the program can send transactions normally.** {% endhint %} **Query your wallet balance** ```bash ./get_balance.sh ``` #### **Running as an Executor** {% stepper %} {% step %} **Edit the .env file according to your RPC type** {% hint style="success" %} For Node RPC: * Set BTC\_RPC\_USER * Set BTC\_RPC\_PASSWORD * Set BTC\_RPC\_ENDPOINT (IP:Port ) For ANKR RPC: * Set ANKR\_API\_KEY For Mempool RPC: * No configuration needed {% endhint %} **Method 1:** Copy the .env file, and enter the .env file to modify the corresponding parameters. ```bash cp .env.example .env ``` **Method 2:** Directly export the corresponding parameters to the environment variables (Note: Re-running the program requires re-importing). For Node RPC: ```bash export BTC_RPC_USER="" export BTC_RPC_PASSWORD="" export BTC_RPC_ENDPOINT="" ``` {% hint style="success" %} The endpoint does not need to include the HTTP or HTTPS protocol. {% endhint %} For ANKR RPC: ```bash export ANKR_API_KEY="" ``` {% endstep %} {% step %} **Run the executor program** ```bash ./executor.sh [-d] [-t tip_value] [-r rpc_type] ``` *Here are some options for more funtions:* ```bash Options: -d Run in daemon mode (background) -t value Specify tip value (default: 0) (may increase the chance of executing a transaction) -r type Bitcoin RPC type (node/mempool/ankr, default: mempool) ``` {% endstep %} {% step %} ### Check executor status ***Once you have submitted a transaction successfully***, your executor status will become "active".
{% endstep %} {% endstepper %} ### Close Program ```bash ./close.sh ``` ### **Claiming Rewards** Except for agere creators, other users' BitAgere incentives are stored in stakes and need to be unstaked to receive actual tokens. **Using scripts to unstake** ```bash ./stake.sh remove ``` **Unstaking via BEVM Wallet** *Router: Agere->User Dashboard->Agere Participants->Unstake*
# Bitcoin DID # Introduction # API # DID Node API ## Health Check > Health check endpoint ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"paths":{"/health":{"get":{"summary":"Health Check","description":"Health check endpoint","operationId":"health_check_health_get","responses":{"200":{"description":"Successful Response","content":{"application/json":{"schema":{}}}}}}}}} ``` ## Api Resolve > Resolve DID document ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"paths":{"/did/resolve":{"get":{"summary":"Api Resolve","description":"Resolve DID document","operationId":"api_resolve_did_resolve_get","parameters":[{"name":"did","in":"query","required":true,"schema":{"type":"string","title":"Did"}}],"responses":{"200":{"description":"Successful Response","content":{"application/json":{"schema":{}}}},"422":{"description":"Validation Error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/HTTPValidationError"}}}}}}}},"components":{"schemas":{"HTTPValidationError":{"properties":{"detail":{"items":{"$ref":"#/components/schemas/ValidationError"},"type":"array","title":"Detail"}},"type":"object","title":"HTTPValidationError"},"ValidationError":{"properties":{"loc":{"items":{"anyOf":[{"type":"string"},{"type":"integer"}]},"type":"array","title":"Location"},"msg":{"type":"string","title":"Message"},"type":{"type":"string","title":"Error Type"}},"type":"object","required":["loc","msg","type"],"title":"ValidationError"}}}} ``` ## Api List Dids > List DIDs with optional filtering by controller or public\_key\_multibase, and pagination ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"paths":{"/did/list":{"get":{"summary":"Api List Dids","description":"List DIDs with optional filtering by controller or public_key_multibase, and pagination","operationId":"api_list_dids_did_list_get","parameters":[{"name":"page","in":"query","required":false,"schema":{"type":"integer","minimum":1,"default":1,"title":"Page"}},{"name":"page_size","in":"query","required":false,"schema":{"type":"integer","maximum":100,"minimum":1,"default":20,"title":"Page Size"}},{"name":"controller","in":"query","required":false,"schema":{"anyOf":[{"type":"string"},{"type":"null"}],"title":"Controller"}},{"name":"public_key","in":"query","required":false,"schema":{"anyOf":[{"type":"string"},{"type":"null"}],"title":"Public Key"}},{"name":"key_type","in":"query","required":false,"schema":{"anyOf":[{"type":"string"},{"type":"null"}],"title":"Key Type"}}],"responses":{"200":{"description":"Successful Response","content":{"application/json":{"schema":{}}}},"422":{"description":"Validation Error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/HTTPValidationError"}}}}}}}},"components":{"schemas":{"HTTPValidationError":{"properties":{"detail":{"items":{"$ref":"#/components/schemas/ValidationError"},"type":"array","title":"Detail"}},"type":"object","title":"HTTPValidationError"},"ValidationError":{"properties":{"loc":{"items":{"anyOf":[{"type":"string"},{"type":"integer"}]},"type":"array","title":"Location"},"msg":{"type":"string","title":"Message"},"type":{"type":"string","title":"Error Type"}},"type":"object","required":["loc","msg","type"],"title":"ValidationError"}}}} ``` ## Did History > Get the complete history of DID operations ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"paths":{"/did/history":{"get":{"summary":"Did History","description":"Get the complete history of DID operations","operationId":"did_history_did_history_get","parameters":[{"name":"did","in":"query","required":true,"schema":{"type":"string","title":"Did"}}],"responses":{"200":{"description":"Successful Response","content":{"application/json":{"schema":{}}}},"422":{"description":"Validation Error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/HTTPValidationError"}}}}}}}},"components":{"schemas":{"HTTPValidationError":{"properties":{"detail":{"items":{"$ref":"#/components/schemas/ValidationError"},"type":"array","title":"Detail"}},"type":"object","title":"HTTPValidationError"},"ValidationError":{"properties":{"loc":{"items":{"anyOf":[{"type":"string"},{"type":"integer"}]},"type":"array","title":"Location"},"msg":{"type":"string","title":"Message"},"type":{"type":"string","title":"Error Type"}},"type":"object","required":["loc","msg","type"],"title":"ValidationError"}}}} ``` ## Did At Height > Get DID document state at specific block height ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"paths":{"/did/at_height":{"get":{"summary":"Did At Height","description":"Get DID document state at specific block height","operationId":"did_at_height_did_at_height_get","parameters":[{"name":"did","in":"query","required":true,"schema":{"type":"string","title":"Did"}},{"name":"height","in":"query","required":true,"schema":{"type":"integer","minimum":0,"title":"Height"}}],"responses":{"200":{"description":"Successful Response","content":{"application/json":{"schema":{}}}},"422":{"description":"Validation Error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/HTTPValidationError"}}}}}}}},"components":{"schemas":{"HTTPValidationError":{"properties":{"detail":{"items":{"$ref":"#/components/schemas/ValidationError"},"type":"array","title":"Detail"}},"type":"object","title":"HTTPValidationError"},"ValidationError":{"properties":{"loc":{"items":{"anyOf":[{"type":"string"},{"type":"integer"}]},"type":"array","title":"Location"},"msg":{"type":"string","title":"Message"},"type":{"type":"string","title":"Error Type"}},"type":"object","required":["loc","msg","type"],"title":"ValidationError"}}}} ``` ## Api Create > Create a new DID and return PSBT ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"paths":{"/did/create":{"post":{"summary":"Api Create","description":"Create a new DID and return PSBT","operationId":"api_create_did_create_post","requestBody":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/DIDCreateRequest"}}},"required":true},"responses":{"200":{"description":"Successful Response","content":{"application/json":{"schema":{}}}},"422":{"description":"Validation Error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/HTTPValidationError"}}}}}}}},"components":{"schemas":{"DIDCreateRequest":{"properties":{"spend_addr":{"type":"string","title":"Spend Addr"},"verification_capabilities":{"type":"integer","title":"Verification Capabilities"},"control_address":{"type":"string","title":"Control Address"},"subject_public_key":{"type":"string","title":"Subject Public Key"},"key_type":{"type":"string","title":"Key Type"}},"type":"object","required":["spend_addr","verification_capabilities","control_address","subject_public_key","key_type"],"title":"DIDCreateRequest"},"HTTPValidationError":{"properties":{"detail":{"items":{"$ref":"#/components/schemas/ValidationError"},"type":"array","title":"Detail"}},"type":"object","title":"HTTPValidationError"},"ValidationError":{"properties":{"loc":{"items":{"anyOf":[{"type":"string"},{"type":"integer"}]},"type":"array","title":"Location"},"msg":{"type":"string","title":"Message"},"type":{"type":"string","title":"Error Type"}},"type":"object","required":["loc","msg","type"],"title":"ValidationError"}}}} ``` ## Api Update > Update DID and return PSBTs ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"paths":{"/did/update":{"post":{"summary":"Api Update","description":"Update DID and return PSBTs","operationId":"api_update_did_update_post","requestBody":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/DIDUpdateRequest"}}},"required":true},"responses":{"200":{"description":"Successful Response","content":{"application/json":{"schema":{}}}},"422":{"description":"Validation Error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/HTTPValidationError"}}}}}}}},"components":{"schemas":{"DIDUpdateRequest":{"properties":{"original_utxo":{"additionalProperties":true,"type":"object","title":"Original Utxo"},"spend_addr":{"type":"string","title":"Spend Addr"},"vm_updates":{"items":{"additionalProperties":true,"type":"object"},"type":"array","title":"Vm Updates"},"control_address":{"type":"string","title":"Control Address"}},"type":"object","required":["original_utxo","spend_addr","vm_updates","control_address"],"title":"DIDUpdateRequest"},"HTTPValidationError":{"properties":{"detail":{"items":{"$ref":"#/components/schemas/ValidationError"},"type":"array","title":"Detail"}},"type":"object","title":"HTTPValidationError"},"ValidationError":{"properties":{"loc":{"items":{"anyOf":[{"type":"string"},{"type":"integer"}]},"type":"array","title":"Location"},"msg":{"type":"string","title":"Message"},"type":{"type":"string","title":"Error Type"}},"type":"object","required":["loc","msg","type"],"title":"ValidationError"}}}} ``` ## Api Deactivate > Deactivate DID and return PSBT ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"paths":{"/did/deactivate":{"post":{"summary":"Api Deactivate","description":"Deactivate DID and return PSBT","operationId":"api_deactivate_did_deactivate_post","requestBody":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/DIDDeactivateRequest"}}},"required":true},"responses":{"200":{"description":"Successful Response","content":{"application/json":{"schema":{}}}},"422":{"description":"Validation Error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/HTTPValidationError"}}}}}}}},"components":{"schemas":{"DIDDeactivateRequest":{"properties":{"original_utxo":{"additionalProperties":true,"type":"object","title":"Original Utxo"},"spend_addr":{"type":"string","title":"Spend Addr"}},"type":"object","required":["original_utxo","spend_addr"],"title":"DIDDeactivateRequest"},"HTTPValidationError":{"properties":{"detail":{"items":{"$ref":"#/components/schemas/ValidationError"},"type":"array","title":"Detail"}},"type":"object","title":"HTTPValidationError"},"ValidationError":{"properties":{"loc":{"items":{"anyOf":[{"type":"string"},{"type":"integer"}]},"type":"array","title":"Location"},"msg":{"type":"string","title":"Message"},"type":{"type":"string","title":"Error Type"}},"type":"object","required":["loc","msg","type"],"title":"ValidationError"}}}} ``` ## Batch Get Dids > Batch query DID documents by DID list (limit: max 100) ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"paths":{"/did/batch_get":{"post":{"summary":"Batch Get Dids","description":"Batch query DID documents by DID list (limit: max 100)","operationId":"batch_get_dids_did_batch_get_post","requestBody":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/DIDBatchRequest"}}},"required":true},"responses":{"200":{"description":"Successful Response","content":{"application/json":{"schema":{}}}},"422":{"description":"Validation Error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/HTTPValidationError"}}}}}}}},"components":{"schemas":{"DIDBatchRequest":{"properties":{"dids":{"items":{"type":"string"},"type":"array","title":"Dids"}},"type":"object","required":["dids"],"title":"DIDBatchRequest"},"HTTPValidationError":{"properties":{"detail":{"items":{"$ref":"#/components/schemas/ValidationError"},"type":"array","title":"Detail"}},"type":"object","title":"HTTPValidationError"},"ValidationError":{"properties":{"loc":{"items":{"anyOf":[{"type":"string"},{"type":"integer"}]},"type":"array","title":"Location"},"msg":{"type":"string","title":"Message"},"type":{"type":"string","title":"Error Type"}},"type":"object","required":["loc","msg","type"],"title":"ValidationError"}}}} ``` ## Did Verify > Verify DID signature ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"paths":{"/did/verify":{"post":{"summary":"Did Verify","description":"Verify DID signature","operationId":"did_verify_did_verify_post","parameters":[{"name":"did","in":"query","required":true,"schema":{"type":"string","title":"Did"}},{"name":"signature","in":"query","required":true,"schema":{"type":"string","title":"Signature"}},{"name":"data","in":"query","required":true,"schema":{"type":"string","title":"Data"}},{"name":"sign_type","in":"query","required":false,"schema":{"anyOf":[{"type":"string"},{"type":"null"}],"description":"Signature type: standard, unisat, bitcoin_message","default":"standard","title":"Sign Type"},"description":"Signature type: standard, unisat, bitcoin_message"}],"responses":{"200":{"description":"Successful Response","content":{"application/json":{"schema":{}}}},"422":{"description":"Validation Error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/HTTPValidationError"}}}}}}}},"components":{"schemas":{"HTTPValidationError":{"properties":{"detail":{"items":{"$ref":"#/components/schemas/ValidationError"},"type":"array","title":"Detail"}},"type":"object","title":"HTTPValidationError"},"ValidationError":{"properties":{"loc":{"items":{"anyOf":[{"type":"string"},{"type":"integer"}]},"type":"array","title":"Location"},"msg":{"type":"string","title":"Message"},"type":{"type":"string","title":"Error Type"}},"type":"object","required":["loc","msg","type"],"title":"ValidationError"}}}} ``` # Models ## The DIDBatchRequest object ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"components":{"schemas":{"DIDBatchRequest":{"properties":{"dids":{"items":{"type":"string"},"type":"array","title":"Dids"}},"type":"object","required":["dids"],"title":"DIDBatchRequest"}}}} ``` ## The DIDCreateRequest object ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"components":{"schemas":{"DIDCreateRequest":{"properties":{"spend_addr":{"type":"string","title":"Spend Addr"},"verification_capabilities":{"type":"integer","title":"Verification Capabilities"},"control_address":{"type":"string","title":"Control Address"},"subject_public_key":{"type":"string","title":"Subject Public Key"},"key_type":{"type":"string","title":"Key Type"}},"type":"object","required":["spend_addr","verification_capabilities","control_address","subject_public_key","key_type"],"title":"DIDCreateRequest"}}}} ``` ## The DIDDeactivateRequest object ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"components":{"schemas":{"DIDDeactivateRequest":{"properties":{"original_utxo":{"additionalProperties":true,"type":"object","title":"Original Utxo"},"spend_addr":{"type":"string","title":"Spend Addr"}},"type":"object","required":["original_utxo","spend_addr"],"title":"DIDDeactivateRequest"}}}} ``` ## The DIDUpdateRequest object ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"components":{"schemas":{"DIDUpdateRequest":{"properties":{"original_utxo":{"additionalProperties":true,"type":"object","title":"Original Utxo"},"spend_addr":{"type":"string","title":"Spend Addr"},"vm_updates":{"items":{"additionalProperties":true,"type":"object"},"type":"array","title":"Vm Updates"},"control_address":{"type":"string","title":"Control Address"}},"type":"object","required":["original_utxo","spend_addr","vm_updates","control_address"],"title":"DIDUpdateRequest"}}}} ``` ## The HTTPValidationError object ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"components":{"schemas":{"HTTPValidationError":{"properties":{"detail":{"items":{"$ref":"#/components/schemas/ValidationError"},"type":"array","title":"Detail"}},"type":"object","title":"HTTPValidationError"},"ValidationError":{"properties":{"loc":{"items":{"anyOf":[{"type":"string"},{"type":"integer"}]},"type":"array","title":"Location"},"msg":{"type":"string","title":"Message"},"type":{"type":"string","title":"Error Type"}},"type":"object","required":["loc","msg","type"],"title":"ValidationError"}}}} ``` ## The ValidationError object ```json {"openapi":"3.1.0","info":{"title":"DID Node API","version":"1.0.0"},"components":{"schemas":{"ValidationError":{"properties":{"loc":{"items":{"anyOf":[{"type":"string"},{"type":"integer"}]},"type":"array","title":"Location"},"msg":{"type":"string","title":"Message"},"type":{"type":"string","title":"Error Type"}},"type":"object","required":["loc","msg","type"],"title":"ValidationError"}}}} ``` # Use # Wasm Wallet Wasm(Substrate) wallet is a little different from EVM wallet, so we list a tutorial about two more comprehensive wasm wallet extensions---polkadot{.js} and SubWallet ## Polkadot{.js} ### 1 Download you can download [polkadot{.js}](https://chromewebstore.google.com/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd) through this link on chrome browser. ### 2 Use Generate a new mnemonic and set the password for your account, however, you need to back up your mnemonics at once because you can't back up your mnemonics once you skip the process. ### 3 Back up You can export an encrypted .json file and import into other substrate(Wasm) wallets. ## SubWallet ### 1 Download you can download [SubWallet](https://chromewebstore.google.com/detail/subwallet-polkadot-wallet/onhogfjeacnfoofkfgppdlbmlmnplgbn) through this link on chrome browser. ### 2 Use SubWallet offers a beginner-friendly UX, similar to Metamask and other EVM wallets, also, you need to back up your mnemonics at once because you can't back up your mnemonics once you skip the process. ### 3 Network Importation Paste `wss://rpc-mainnet-1.bevm.io/ws` in Provider URL.
### 4 Back up You can export an encrypted ".json" file and import other substrate(Wasm) wallets. # Earn $GEB ## Mother Consensus: ### Validator {% content-ref url="/pages/8I2bI7Imdzgwch1qXYcq" %} [L-BTC Validator Operation](/build/validator/l-btc-validator-operation) {% endcontent-ref %} ### Stake L-BTC {% content-ref url="/pages/1pFn2GWutXvjbrStaPKH" %} [Stake L-BTC Earn $GEB](/use/earn-usdgeb/stake-l-btc/stake-l-btc-earn-usdgeb) {% endcontent-ref %} ## BitAgere ### Run as a Participant {% content-ref url="/pages/WvMol2ypIKniGmj2wKfk" %} [Agere Auditor](/build/bitagere/agere-auditor) {% endcontent-ref %} {% content-ref url="/pages/S99JhxqYVSb3JefrGB9T" %} [Agere Executor](/build/bitagere/agere-executor) {% endcontent-ref %} ### User Stake on the Agere {% content-ref url="/pages/XZq04Aa1f5CVTHtw3muw" %} [Stake GEB on Agere](/use/earn-usdgeb/stake-geb-on-agere) {% endcontent-ref %} # Stake L-BTC [GEB HUB](https://gebhub.geb.network/) is a portal for interaction between the Lightning Network and the GEB network, enabling users to manage their BTC Lightning Network and GEB network assets, as well as their own Lightning Network nodes. [LND DESK](https://github.com/btclayer2/LND-Desk/releases) is a lightweight client that makes it easy for users to run their own Lightning Network nodes. {% hint style="info" %} **The prerequisite for using GEB HUB is successfully running LND Desk and connecting the two.** {% endhint %} # What is L-BTC? L-BTC is a token created through the mutual mapping between Bitcoin and the BEVM(λ) ecosystem. In BEVM, users establish channels between their Lightning Network nodes and BEVM's Lightning Network nodes. Whenever a channel is established, users receive an equivalent amount of L-BTC on BEVM, maintaining a 1:1 mapping ratio. L-BTC is fully self-custodial and does not support direct transfers, being exclusively used for staking. This makes L-BTC a self-custodial asset for interaction between the Lightning Network and BEVM(λ) system. ## **Role of L-BTC** One of L-BTC's design purposes is to serve as part of the dual-token Proof of Stake (PoS) mechanism. In the dual-token PoS model, L-BTC primarily functions as an additional form of BEVM token, allowing users to participate in BEVM network's consensus mechanism by staking L-BTC. L-BTC represents both users' contributions to the Bitcoin network and increases their consensus participation weight through BEVM(λ) network's proof-of-stake mechanism. Specifically, L-BTC acts as a bridge token, ensuring asset liquidity between the Bitcoin network and BEVM network, allowing users to influence their stake and participation in the BEVM network through their activity level in the Lightning Network. This design effectively enhances network decentralization and avoids the risk of single capital concentration. L-BTC as Part of Dual-Token PoS In the dual-token PoS mechanism, L-BTC is part of achieving network consensus by combining Bitcoin's computing power and BEVM's proof of stake. Specifically, L-BTC plays key roles in: 1. **Stake Pledging**: L-BTC can be staked to participate in the PoS consensus mechanism. Nodes staking L-BTC can obtain consensus participation opportunities based on their L-BTC weight, determining whether they become network validators. 2. **Reward Distribution**: Through a probabilistic reward distribution mechanism, L-BTC holders participate in generating new blocks and receive BEVM rewards based on their stake amount and network activity. 3. **Decentralization and Security**: L-BTC usage in the Lightning Network strengthens network decentralization, combining BTC's computational contribution and L-BTC's stake contribution to avoid wealth concentration issues common in traditional PoS. ## Mechanism L-BTC Interaction Mechanism As a self-custodial asset, users can perform the following operations with L-BTC through the Lightning Network: 1. **L-BTC Generation**: Users establish channels between their Lightning Network nodes and BEVM's Lightning Network nodes to receive an equivalent amount of L-BTC. L-BTC is fully user-controlled, cannot be directly transferred, and can only participate in network consensus through staking. 2. **L-BTC to BTC Conversion**: Users initiate Send operations within Lightning Network channels to convert L-BTC to BTC. This process occurs through the Lightning Network, ensuring asset liquidity. 3. **BTC to L-BTC Conversion**: Users call contracts on BEVM to initiate L-BTC withdrawal operations, converting BTC to L-BTC for staking and proof of stake in the BEVM network. 4. **L-BTC Redemption**: When users close Lightning Network channels, staked L-BTC automatically burns while exchanging for corresponding BTC in the Bitcoin network. L-BTC's not just a bridge tool between Bitcoin and BEVM networks but also an essential component of the dual-token PoS mechanism, helping achieve decentralization, security, and reward fairness. Through L-BTC, users can flow assets between Bitcoin and BEVM networks and participate in consensus mechanisms, promoting healthy development of the entire ecosystem. # Download and Run LND Desk You can choose to download LND Desk directly or run it yourself using Docker. {% hint style="warning" %} Please download the release of LND Desk without beta. {% endhint %} **LND Desk**: [**https://github.com/GEBcore/LND-Desk/releases**](https://github.com/GEBcore/LND-Desk/releases) {% hint style="info" %} **The data storage files of LND Desk are extremely important and must not be lost. Otherwise, the assets in your Lightning Network channels could be lost.** {% endhint %} ### Initial Configuration Items
{% stepper %} {% step %} ### **Data Storage Directory** Select a folder to run the node. Make sure not to lose this file, as it is crucial to your assets. {% endstep %} {% step %} ### **Your LND Alias** Enter an alias (this is not very important). {% endstep %} {% step %} ### **Special Node Configuration** Configure it as shown in the screenshot. {% endstep %} {% step %} ### **Click Confirm to Run** {% endstep %} {% step %} ### **Set Your Wallet Password and Generate a new wallet** The mnemonic phrase and password are extremely important. If lost, they cannot be recovered. {% endstep %} {% step %} ### **Run Successfully**
{% endstep %} {% endstepper %} {% hint style="info" %} **The program can be closed. When you need to operate it again, simply reopen and run it.** {% endhint %} {% hint style="success" %} Docker tutorial is provided for platforms that do not have pre-packaged solutions, such as ARM-based Windows and ARM-based Linux systems. {% endhint %} **Docker:** [**https://github.com/btclayer2/lnd-hub/blob/main/docs/node-runner.docker.en.md**](https://github.com/btclayer2/lnd-hub/blob/main/docs/node-runner.docker.en.md) # Config LND Here LND refers to your lightning network node **Open the node configuration** [**page**](https://bevmhub.bevm.io/node)**.**
{% stepper %} {% step %} ### **Lnd Host** Copy the LND REST from the successfully running LND Desk and enter it. {% endstep %} {% step %} ### **Lnd Admin Macaroon** Locate the `admin.macaroon` file in the successfully running LND Desk and upload it. {% endstep %} {% step %} ### Click Connect As shown in the screenshot, this indicates a successful connection.
{% endstep %} {% endstepper %} # Node Asset Management If you have successfully run your own LND node, the next step is to fund it with BTC. Then, open a Lightning Network channel with BEVM’s root node to obtain L-BTC. Open the [BEVM Hub](https://bevmhub.bevm.io/node) , then go to the "Node ⭢ Advanced" options list to find the corresponding action button. "On-Chain" in BEVM Hub refers to your assets on the Bitcoin Lightning Network.
{% hint style="info" %} **Deposit and withdrawal transactions require confirmation of one Bitcoin network block before they are credited.** {% endhint %} ### **BEVM Network Assets** Once your node is successfully running and connected to BEVM Hub, a EVM address will be automatically generated. This address serves as your gateway to managing assets on the BEVM network. Rest assured, it is completely secure and solely under your control.
# Open Channel(Get L-BTC) Please confirm that your node has been funded with BTC; otherwise, refer to this [section](/use/earn-usdgeb/stake-l-btc/node-asset-management). You only need to open a Lightning Network channel with BEVM’s root node to obtain L-BTC, and the amount depends on the "Local Balance" in the channel. **Open the Node** [**page**](https://bevmhub.bevm.io/node)**.** {% stepper %} {% step %} ### **Click "Open Channel" in the top right corner.** {% endstep %} {% step %} ### **Enter the channel capacity and click "Next."** Ensure that your "on-chain balance" is sufficient.
{% endstep %} {% step %} ### **Wait for the channel to open.** As shown in the screenshot, when a channel in your list appears with the "online" status, it means the channel has been successfully opened. The transaction for opening the channel requires three confirmations on the Bitcoin network.
{% endstep %} {% step %} ### **Click on "Node" in the sidebar to view your L-BTC balance.**
{% endstep %} {% endstepper %} # L-BTC ⇌ BTC (on GEB chain) L-BTC is a non-transferable token on the GEB chain, convertible 1:1 with BTC(on GEB chain)
# Stake L-BTC Earn $GEB You need to obtain L-BTC before you can stake. If your LND node has no BTC balance, please refer to this [section](/use/earn-usdgeb/stake-l-btc/node-asset-management/open-channel-get-l-btc). ### **Open the Earn** [**page**](https://bevmhub.bevm.io/earn)**.**
{% stepper %} {% step %} ### **Select a validator from the list and click "Stake"** {% endstep %} {% step %} ### **Enter the stake amount and click "Confirm"** This step requires your [EVM address](/use/earn-usdgeb/stake-l-btc/node-asset-management#bevm-network-assets) to have sufficient BTC for gas fees.
{% endstep %} {% step %} ### **Stake Successful** After a successful stake, you will see a screen similar to the one below\.You can also unstake in the "My Stake" section.
{% endstep %} {% endstepper %} **When claiming rewards, you need to pay the geb network's BTC as gas fee, which can be obtained in the following ways** {% content-ref url="/pages/CXaLeF2j2rSVClQ5eMzt" %} [L-BTC ⇌ BTC (on GEB chain)](/use/earn-usdgeb/stake-l-btc/node-asset-management/l-btc-btc-on-geb-chain) {% endcontent-ref %} {% content-ref url="/pages/O4j12IUtV6La2Nn4G0Rm" %} [Bridge](/use/bridge) {% endcontent-ref %} {% hint style="info" %} **Staking L-BTC does not transfer it from your address. However, if your address balance decreases or the channel is closed, the system will automatically unstake it.** {% endhint %} # Stake GEB on Agere Users can earn GEB rewards by staking to auditors on agere. ### Transfer GEB from EVM to Wasm {% content-ref url="/pages/lYZeHK0f9MR2xR52clfC" %} [Transfer(EVM<-->Wasm)](/use/bridge/transfer-evm-less-than-greater-than-wasm) {% endcontent-ref %} ### Delegate GEB to the Auditor/Executor Use[ GEB Wallet](https://wallet.bevm.io/?rpc=wss%3A%2F%2Frpc-mainnet-1.bevm.io%2Fws#/agere) to delegate GEB *Router: Agere->Auditor*
# Earn $BTC User can stake for the Validator to Earn BTC on BEVM(λ) now. ### How to get BEVM on Wasm? {% content-ref url="/pages/lYZeHK0f9MR2xR52clfC" %} [Transfer(EVM<-->Wasm)](/use/bridge/transfer-evm-less-than-greater-than-wasm) {% endcontent-ref %} ### Vote in the [BEVM Wallet](https://wallet.bevm.io/#/staking) You must select an **active** validator; otherwise, you won't receive any rewards. It is advisable to regularly monitor the validator list to stay informed. Each validator's voting limit is capped at **10 times** their own staked amount. Once a validator reaches this maximum stake, it will no longer be eligible to receive votes. {% hint style="warning" %} It is recommended to keep a small amount of $BEVM in your address to facilitate future operations. {% endhint %}
{% hint style="info" %} If the validator you voted for becomes inactive, you can choose to rebind to another one. {% endhint %} # Claim and Other Operations ### Check your BTC balance You can check the BTC balance under your address in **Accounts → My Accounts**, with the unit in satoshi.
### Claim Reward Rewards need to be actively claimed before they can be credited to your balance.
### Unbind After unbinding, your $BEVM will enter a frozen state. For regular users, the freezing period lasts **43,200 blocks** (approximately **3 days**), while for validators, it lasts **432,000 blocks**. After the freezing period ends, you will need to manually click **Unfreeze** to release the funds.
### Rebind Rebinding allows you to stake your currently staked BEVM to another validator. This process takes effect immediately upon successful execution. ### Reminder * The additional fee for rebond and validate (i.e., candidacy) is 1 BEVM. * To limit the frequency of rebonding, it is stipulated that only one rebond operation is allowed every 3 days (i.e., 43200 blocks). * Validators who wish to unstake their tokens are subject to a 30-day (432,000 blocks) freezing period, while nominators have a 3-day (43,200 blocks) freezing period. After the freezing period has elapsed, a thawing transaction must be sent to reclaim the staked voting amount. # Transfer BTC to EVM Operation path: **Developer → Extrinsics → Submission ,** the specific operation is as shown in the screenshot. Make sure to select the designated pallet and the method to invoke. {% stepper %} {% step %} **"balanceOnBevm"** Enter the amount you want to transfer, paying attention to the precision value. For example, if you want to transfer **10,000 sats**, you should enter **100000000000000**. {% endstep %} {% step %} **"evmAccount"** Enter the **EVM address** where you want to receive BTC. {% endstep %} {% step %} **Submit** **Transaction** {% endstep %} {% endstepper %}
# Bridge The Bridge system implements a comprehensive multi-bridge architecture that consists of an Official Bridge for core functionality, a Third-Party Bridge enabling ecosystem expansion through external developer contributions, and a Wasm Bridge for WebAssembly\&EVM integration. This design approach offers users multiple bridging options while maintaining system flexibility and extensibility, enhancing cross-platform compatibility and overall performance. # Official Bridge # GEB Mainnet #### 1 Cross-chain using the official bridge
ParameterLink
Official cross-chain bridgehttps://www.geb.network/bridge-mainnet
#### 2 Connect both Bitcoin\&EVM wallet.
#### 3 Make sure your destination chain is GEB Mainnet, input the amount and click transfer button. (The minimum amount is 0.0001 BTC)
#### 4 Sign in your wallet and confirm the transaction. Your transaction history can be found in here.
**5 You can check the GEB Mainnet transaction now.**
# BEVM Canary #### 1 Cross-chain using the official bridge
ParameterLink
Official cross-chain bridgehttps://www.bevm.io/bridge
#### 2 Connect both Bitcoin\&EVM wallet.

https://www.bevm.io/bridge

#### 3 Make sure your destination chain is BEVM, input the amount and click transfer button. (The minimum amount is 0.0001 BTC)
#### 4 Sign in your wallet and confirm the transaction. Your transaction history can be found in here.

https://www.bevm.io/bridge/history

# Transfer(EVM<-->Wasm) {% hint style="warning" %} $GEB and $BEVM are the governance tokens on EVM and WASM chains, respectively. Essentially, they are the same coin and can be exchanged at a 1:1 ratio.When you complete a transfer between EVM and WASM, the conversion happens automatically. {% endhint %} ## [Transfer from EVM to Wasm](https://wallet.bevm.io/?rpc=wss%3A%2F%2Frpc-mainnet-1.bevm.io%2Fws#/bridge/EVMToWasm) Connect your EVM account that you want to transfer to your WASM address as "EVM address," and choose your WASM account as "to account."
## [Transfer from Wasm to EVM](https://wallet.bevm.io/?rpc=wss%3A%2F%2Frpc-mainnet-1.bevm.io%2Fws#/bridge) Choose your WASM account that you want to transfer to your EVM address as "using the selected account," and input your EVM address into "to EVM address."
## How to use BEVM on Wasm? {% content-ref url="/pages/j8loy5JFKzeapin5A5zm" %} [Earn $BTC](/use/earn-usdbtc) {% endcontent-ref %} {% content-ref url="/pages/XZq04Aa1f5CVTHtw3muw" %} [Stake GEB on Agere](/use/earn-usdgeb/stake-geb-on-agere) {% endcontent-ref %} # EVM Development Build # Fee Calculation The mainnet of BEVM and the Canary of BEVM use different gas mechanisms. # GEB Mainnet Mainnet In the GEB network, every transaction requires the consumption of a certain amount of Gas. Gas is the fuel that powers the execution of transactions and smart contract operations on the GEB network. Each operation has a fixed Gas consumption, which is defined by the rules of the Ethereum Virtual Machine (EVM). Understanding the Gas calculation of the GEB is a key part of understanding how the BEVM network operates. ### What is Gas? Gas is the unit of measurement used to quantify the computational work and storage operations in the GEB network. Whenever users want to execute a transaction or smart contract, they must specify a Gas Limit and Gas Price. The Gas Limit is the maximum amount of Gas that the user is willing to pay for the computation, while the Gas Price is the amount of BTC the user is willing to pay for each unit of Gas. ### Standard Gas Calculations In the GEB network, transaction fees are composed of two parts: the base fee and the priority fee, also known as a tip. The **base fee** is the minimum fee that must be paid for every block and is a dynamic value that adjusts automatically based on network congestion. Each block has a target size, and the base fee increases if the previous block exceeds this target size; it decreases if the block is below the target size. This mechanism is designed to help the network regulate itself and maintain stability in transaction fees. The **priority fee** is an additional fee that users are willing to pay to miners to have their transactions prioritized. When the network is congested, miners may prefer transactions with higher priority fees because it allows them to earn more revenue. Therefore, if users want their transactions to be processed quickly, they can incentivize miners by increasing the priority fee. In Solidity smart contracts, you can access the current block's base fee using `block.basefee`, but there is no direct way to set the priority fee. Instead, when users or applications initiate a transaction, they need to specify `maxPriorityFeePerGas` (the maximum priority fee) and `maxFeePerGas` (the maximum fee, including both the base and priority fees) in the transaction parameters. Miners consider these parameters when selecting transactions to include in a block. ### Gas Limit and Gas Price Users need to set a Gas Limit and Gas Price when sending transactions. * **Gas Limit**: This is the maximum total amount of Gas that the user is willing to pay for executing the transaction or contract operation. If the transaction consumes more Gas than the Gas Limit, the transaction will fail, and the consumed Gas will not be refunded. * **Gas Price**: This is the price that the user is willing to pay per unit of Gas. The higher the Gas Price, the higher the priority miners will give to processing the transaction. ### Estimating Gas Costs Most EVM wallets and clients automatically estimate the Gas required for a transaction. They usually take into account the current network congestion and the complexity of the transaction. #### # BEVM Canary When conducting transactions on the BEVM MainNet, **BTC is required as gas**. The Bitcoin network employs the UTXO model, while the BEVM network utilizes an account model. This implies that the usage paradigms of the two networks are different. However, **we ensure that each BTC on the BEVM network originates from the Bitcoin MainNet**, and there are comprehensive asset proofs available for querying on both the Bitcoin network and the BEVM network. The following describes the calculation method of gas fees on the BEVM Preliminary Network: BEVM transaction fees consist of three components: **initial gas**, **real gas**, and **refund gas**. The following are the calculation methods and their inherent relationships:
initial gas initial = \dfrac{gas\_limit\times max\_gas\_price}{10^{10}}
real gasreal = \dfrac{gas\_used\times50000000}{10^{10}}
refund gasrefund = initial-real
{% hint style="info" %} When considering the gas price on BEVM Canary (Chain ID: 1501), you might consider establishing it as a default configuration at 0.05 GWei. Regarding the gas limit, you can experiment with it on the BEVM TestNet and subsequently set it as the default on the front end. {% endhint %} If you want to view the actual gas situation for each transaction, you can browse: # Smart Contract # Write a Contract ### Welcome to the GEB Development Journey! Greetings, aspiring dApp developers! This tutorial is your gateway to decentralized applications on the GEB Canary TestNet. Tailored for beginners, it offers a step-by-step guide to deploying smart contracts on this cutting-edge platform. Upon completion, you'll officially join the ranks of dApp developers. **Essentials:** * Basic understanding of Solidity. * Comfort with software development tools and CLIs. * Familiarity with MetaMask. * Access to Discord, and Remix. **Estimated Time:** Approximately 10 minutes. #### What's in Store for You: 1. **Discover GEB Signet:** * Get acquainted with GEB Signet, the primary network. * Dive into GEB Signet, GEB Signet's test network playground. 2. [**Set Up MetaMask**](/evm-development/smart-contract/write-a-contract/set-up-the-metamask-configuration)**:** * Configure MetaMask to seamlessly interact with the GEB Signet. 3. **GEB Signet Smart Contract Deployment:** * Leverage Remix, the online Solidity IDE, to craft and deploy a straightforward smart contract on your local Astar network. 4. **GEB Signet Deployment Adventure:** * Elevate your deployment prowess by extending it to GEB Signet. 5. **GEB Mainnet Deployment:** * Cap off your journey by deploying your smart contract on the GEB Mainnet. Gain insights into the deployment process for production-level dApps. #### Prerequisites Check: Before embarking on this tutorial, ensure you've gathered the essential knowledge and tools. Let's venture into the captivating realm of decentralized applications on the GEB Signet! # Set Up the Metamask Configuration ### Add Network to MetaMask[​](https://docs.astar.network/docs/build/EVM/first-contract/metamask#add-network-to-metamask) It's easy to configure MetaMask to interact with the BEVM family. To do so, open MetaMask, click the Network tab, and click Custom RPC. In the screen shown, please enter the information shown below:
ParameterValue
Network nameGEB Mainnet
TypeMainnet
Native Asset SymbolBTC
Decimal18
Chain-ID11501
Explorerhttps://scan.geb.network
RPC Endpointhttps://rpc-mainnet-1.geb.network
https://rpc-mainnet-2.geb.network
WebSocket

wss://rpc-mainnet-1.geb.network

wss://rpc-mainnet-2.geb.network

Quick Add-
# Deploy Smart Contract on GEB Signet Finally, it's time to deploy your first smart contract on GEB Signet! In this tutorial, you will deploy a basic ERC20 token using Remix. ### Preparation of Solidity Smart Contract on Remix[​](https://docs.astar.network/docs/build/EVM/first-contract/deploy-local#preparation-of-solidity-smart-contract-on-remix) Visit [Remix](https://remix.ethereum.org/) and you can choose the ERC20 Template from openZeppelin, and modify MyToken.sol. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol"; contract MyToken is ERC20, ERC20Permit { constructor() ERC20("GEB", "GEB") ERC20Permit("GEB") { _mint(msg.sender, 1000 * 10 ** 18); } } ``` This smart contract is designed to deploy an ERC20 token named 'GEB' with the ticker 'BEVM' and a total supply of 1000, utilizing 18 decimals for precision. To compile this contract, navigate to the Solidity Compiler tab in Remix. Subsequently, proceed to the Deploy and Run Transactions tab, adjusting the environment to Injected Web3. Confirm the presence of the Custom (11504) network in the environment field; if not visible, access and modify your network settings through MetaMask. Your interface should now resemble the illustration below:

Remix

### Deploy Contract on GEB Signet[​](https://docs.astar.network/docs/build/EVM/first-contract/deploy-local#deploy-contract-on-local-network) Proceed by clicking on the 'Deploy' button. A prompt from MetaMask will appear, at which point you should select the 'Confirm' button. You have successfully deployed your inaugural smart contract on the GEB Signet! To confirm this, you will notice the EVM events displayed within the explorer. ### View your New Token within MetaMask[​](https://docs.astar.network/docs/build/EVM/first-contract/deploy-local#view-your-new-token-within-metamask) This token can be added to MetaMask because the contract is fully ERC20 compatible, and you will find the ERC20 contract address on Remix or Explorer. In this case, the contract address is "0x73a2FdC366BC339241d685a8B4A0de09a094706b". With that, you can open MetaMask, click the Add Token button, and input your contract address in the Token Contract Address field. You will see that the Token Symbol and Token Decimal fields are filled in automatically, and at last, click Next, and then Add Tokens buttons. You should now see your newly minted ERC20 tokens that are deployed on GEB Testnet, right within your MetaMask, and be able to transfer them to any other EVM account. # Deploy Smart Contract on BEVM Canary Your journey is almost finished. At last, you will deploy a smart contract on BEVM Canary. ### Deploy Contract on BEVM Canary Now, we shall proceed to deploy a smart contract on BEVM Canary, utilizing the identical process as employed for BEVM Canary TestNet. Initiate Remix, compile your code, and deploy your contract. It is crucial to verify that the Custom (1501) network is visible under the environment field during your deployment. After a brief wait, you will observe that the contract has been successfully deployed on BEVM Canary, and you will also have the ability to import the recently deployed ERC20 token into MetaMask. ### Next Step[​](https://docs.astar.network/docs/build/EVM/first-contract/deploy-shibuya#next-step) Congratulations! You have now ascended to the role of a dApp developer on BEVM Canary. To further enhance and broaden your newly acquired skills as a smart contract developer, we highly recommend immersing yourself in our official documentation and builders' guides. Additionally, consider joining our Discord community to exchange thoughts with fellow developers and receive technical support. # Foundry Foundry is a key part of the EVM development tools, made by Paradigm, to help developers create and test EVM applications efficiently. It features tools for constructing contracts, interacting with the blockchain, and testing on a simulated network. It emphasizes testing to make sure the code is solid before it goes live. Foundry also speeds up the development process with fast feedback and simulates the blockchain to save on costs. In short, it's a valuable tool for developers making smart contracts on EVM. ### Download Rust Toolkit The Foundry toolkit, which is developed using the Rust programming language, necessitates the prior installation of the Rust toolkit in order to be downloaded and used effectively. ``` curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh ``` Choose the default installation, and click "enter", until you can activate your environment at last. ``` source $HOME/.cargo/env ``` Check your Rust version ``` rustc --version ``` ### Download Foundry Toolkit ``` cargo install --git https://github.com/gakonst/foundry --bin forge --locked ``` # Deploy and verify contract by Foundry {% hint style="success" %} To set up a directory for Foundry with Git, ensure the directory is empty and not linked to another Git branch. Use the `git init` command in the directory to create a new Git repository, which allows Foundry to work correctly. This process is crucial for proper version control and integration with Foundry. {% endhint %} ### Initialize the foundry directory ``` forge init ``` ### Install an open-source solidity repo ``` forge install OpenZeppelin/openzeppelin-contracts ``` ### Open the directory by vs-code ``` code . ``` ### Modify "Counter.sol" 1 Rename the file to "TokenTest.sol" 2 Modify the "TokenTest.sol" code as follows: ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.13; import "lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol"; contract TokenTest is ERC20 { constructor() ERC20("BEVM", "BEVM") { _mint(msg.sender, 1000 * 10 ** 18); } } ``` ### Modify "Counter.s.sol" 1 Rename the file to "TokenTest.s.sol" 2 Modify the "TokenTest.s.sol" code as follows: ```solidity // SPDX-License-Identifier: UNLICENSED // scripts/DeployContract.s.sol pragma solidity ^0.8.13; import "forge-std/Script.sol"; import "../src/TokenTest.sol"; contract DeployContract is Script { function run() public returns(TokenTest){ vm.startBroadcast(); TokenTest tokenTest = new TokenTest(/* constructor arguments */); vm.stopBroadcast(); return tokenTest; } } ``` ### Delete "test.sol" It's optional. You may adjust the code accordingly. ### Add a ".env" File ```properties ETH_RPC_URL= PRIVATE_KEY= VERIFIER_URL=https://scan-canary-test-api.bevm.io/api ``` ### Activate ".env" ``` source .env ``` ### Deploy and verify your contract {% hint style="info" %} When utilizing BEVM Canary/BEVM Canary TestNet, to align the Solidity version correctly, you may insert "solc\_version = "0.8.13" " into the "foundry.toml" file within the "\[profile.default]" section. This adjustment may require you to modify certain dependencies. {% endhint %} {% code overflow="wrap" %} ``` forge script script/TokenTest.s.sol --rpc-url $ETH_RPC_URL --private-key $PRIVATE_KEY --broadcast --verify --verifier blockscout --verifier-url $VERIFIER_URL ``` {% endcode %} Afterward, the current status is provided beneath.

Deploy

Verify

# Contract Verification (BlockScout) Partially Forked from BlockScout Docs Verifying your deployed contract using flattened source code, JSON input, Sourcify and more. Once verified, a smart contract or token contract's source code becomes publicly available and verifiable, creating transparency and trust. Verification is available for both Solidity and Vyper contracts. **Currently, there are 7 methods for verification using the Blockscout UI.** To learn more about the smart contract verification Rust microservice and verification algorithm [see this page for developers](https://docs.blockscout.com/for-developers/information-and-settings/smart-contract-verification). {% hint style="success" %} If preferred you can verify directly from your Hardhat dev environment. * ​[Hardhat Verification Plugin](https://docs.blockscout.com/for-users/verifying-a-smart-contract/hardhat-verification-plugin)​ * ​[Sourcify Plugin for Hardhat](https://docs.blockscout.com/for-users/verifying-a-smart-contract/sourcify-plugin-for-hardhat) ​If preferred you can verify directly from your Foundry dev environment. * [Foundry Verification Command](/evm-development/smart-contract/foundry/deploy-and-verify-contract-by-foundry) {% endhint %} ### Command Api for Different Network | Network | Api URL | | ------------------- | ------------------------------------------ | | BEVM Mainnet | | | BEVM Testnet | | | BEVM Canary | | | BEVM Canary Testnet | | ### Smart Contract Verification with Blockscout 1\) Go to the Verify contract page *(Other -> Verify contract)*
2\) Enter the contract address you received during deployment. The dropdown will show you several available verification options. Select the one you would like to use and continue.
* Solidity ([Flattened source code)](https://docs.blockscout.com/for-users/verifying-a-smart-contract#via-flattened-source-code)​ * Solidity ([Standard JSON input](https://docs.blockscout.com/for-users/verifying-a-smart-contract#via-standard-json-input)) * Solidity ([Sourcify](https://docs.blockscout.com/for-users/verifying-a-smart-contract/contracts-verification-via-sourcify)) * Solidity (Multi-part files) * ​[Vyper (Contract](https://docs.blockscout.com/for-users/verifying-a-smart-contract#vyper-contract)) * Vyper (Multi-part files) * Vyper (Standard JSON input) ### Solidity (Flattened source code)
1. **Contract Address:** The `0x` address supplied on contract creation (added above) 2. **Is Yul contract:** Select if the contract is coded in Yul for efficiency. 3. **Include Nightly Builds**: Select if you want to show nightly builds. 4. **Compiler:** derived from the first line in the contract `pragma solidity X.X.X`. Use the corresponding compiler version rather than the nightly build. 5. **EVM Version:** Select the correct[ EVM version ](https://docs.blockscout.com/for-developers/evm-version-information)if known, otherwise use default. {% hint style="info" %} If you use BEVM Canary and BEVM Canary TestNet, **The highest supported Solidity version is 0.8.13.** {% endhint %} 6. **Optimization Enabled:** If you enabled optimization during compilation, select and enter the run value. 200 is the Solidity Compiler default value. Only change if you changed this value while compiling. 7. **Enter the Solidity Contract Code:** You may need to flatten your solidity code if it utilizes a library or inherits dependencies from another contract. We recommend [hardhat ](https://hardhat.org/hardhat-runner/docs/advanced/flattening)or the [POA solidity flattener](https://github.com/poanetwork/solidity-flattener). 8. **Add Contract Libraries:** Enter the name and 0x address for any required libraries called in the .sol file. You can add multiple contracts with the "+" button. 9. Click the `Verify and Publish` button. 10. If all goes well, you will see a checkmark✅next to Code in the code tab, and an additional tab called `Read Contract`. The contract name will now appear in BlockScout with any transactions related to your contract. ### Solidity (Standard JSON input) ​[More information on JSON input is available here](https://docs.soliditylang.org/en/latest/using-the-compiler.html#input-description). 1. **Include nightly builds**. You can choose **Yes** or **No** depending on your compiler. 2. **Compiler.** Choose the compiler version used to compile your smart contract. If you selected yes for nightly builds, use the compiler version rather than the build. 3. **Standard Input JSON.** Upload your Standard Input JSON file. The file should follow solidity [format](https://docs.soliditylang.org/en/latest/using-the-compiler.html#input-description) and all the sources must be in Literal Content format, not a URL. Click the **Verify & publish** button and wait for the response. ### Via Sourcify: Sources and metadata JSON file See the [Contract Verification via Sourcify](https://docs.blockscout.com/for-users/verifying-a-smart-contract/contracts-verification-via-sourcify) page for details. ### Vyper Contract 1. **Contract Name:** Name assigned to the contract. 2. **Compiler**: Select the compiler version used in the source code. 3. **Contract Code:** Copy and paste the contract code 4. Click the `Verify and Publish` button. If all goes well, you will see a checkmark✅next to Code in the code tab, and an additional tab called `Read Contract`. The contract name will now appear in BlockScout with any transactions related to your contract. ### Troubleshooting If you receive the dreaded `There was an error compiling your contract` message this means the bytecode doesn't match the supplied source code. Unfortunately, there are many reasons this may be the case. Here are a few things to try: 1\) Double-check check the compiler version is correct. Check all version digits - for example, 0.5.1 is different from 0.5.10 2\) Check that an extra space has not been added to the end of the contract. When pasting in, an extra space may be added. Delete this and attempt to recompile. 3\) Copy, paste, and verify your source code in Remix. You may find some exceptions here. #### Verification in a dev environment The [Hardhat verification plugin](https://docs.blockscout.com/for-users/verifying-a-smart-contract/hardhat-verification-plugin) supports BlockScout. You can also choose to use the [Sourcify plugin](https://docs.blockscout.com/for-users/verifying-a-smart-contract/sourcify-plugin-for-hardhat) to verify with Sourcify from your hardhat environment. # ThirdWeb ### Introduction[​](https://docs.astar.network/docs/build/EVM/developer-tooling/thirdweb#introduction) Pre-built contracts are proxy contracts created by the thirdweb team to cover most common use cases and patterns for smart contracts. Contracts cover various use cases across NFTs, airdrops, staking, marketplaces, memberships, and more. ### Deploy on Website {% hint style="info" %} Set the max base fee as 0.05 GWei and the max priority fee as 0.05 GWei at Metamask for BEVM Canary (Chain ID: 1501) {% endhint %} ThirdWeb provides a very convenient graphical interface, allowing the deployment of commonly used contracts with just a few clicks and inputs. It offers a user-friendly experience. 1. Go to the thirdweb Explore page:

Explore

2. Choose the type of contract you want to deploy from the available options: NFTs, tokens, and more. 3. Follow the on-screen prompts to configure and deploy your contract. {% hint style="info" %} For more information on different contracts available on Explore, check out [thirdweb’s documentation.](https://portal.thirdweb.com/pre-built-contracts) {% endhint %} ### Deploy by Code #### Prerequisites[​](https://docs.astar.network/docs/build/EVM/developer-tooling/thirdweb#prerequisites) 1. Ensure that you have the latest version of Node.js installed. 2. Sufficient funds in the wallet for contract deployment gas fees. 3. Basic knowledge of Solidity. 4. API Key is required to access the thirdweb infrastracture such as RPC Endpoint #### *Getting started*[*​*](https://docs.astar.network/docs/build/EVM/developer-tooling/thirdweb#getting-started) **Creating contract**[**​**](https://docs.astar.network/docs/build/EVM/developer-tooling/thirdweb#creating-contract) To create a new smart contract using thirdweb CLI, follow these steps: 1. In your CLI run the following command: ``` npx thirdweb create contract ``` 2. Input your preferences for the command line prompts: 1. Give your project a name 2. Choose your preferred framework: Hardhat or Foundry 3. Name your smart contract 4. Choose the type of base contract: Empty, [ERC20](https://portal.thirdweb.com/solidity/base-contracts/erc20base), [ERC721](https://portal.thirdweb.com/solidity/base-contracts/erc721base), or [ERC1155](https://portal.thirdweb.com/solidity/base-contracts/erc1155base) 5. Add any desired [extensions](https://portal.thirdweb.com/solidity/extensions) 3. Once created, navigate to your project’s directory and open in your preferred code editor. 4. If you open the `contracts` folder, you will find your smart contract; this is your smart contract written in Solidity. The following is code for an ERC721Base contract without specified extensions. It implements all of the logic inside the [`ERC721Base.sol`](https://github.com/thirdweb-dev/contracts/blob/main/contracts/base/ERC721Base.sol) contract; which implements the [`ERC721A`](https://github.com/thirdweb-dev/contracts/blob/main/contracts/eip/ERC721A.sol) standard. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import "@thirdweb-dev/contracts/base/ERC721Base.sol"; contract Contract is ERC721Base { constructor( string memory _name, string memory _symbol, address _royaltyRecipient, uint128 _royaltyBps ) ERC721Base(_name, _symbol, _royaltyRecipient, _royaltyBps) {} } ``` This contract inherits the functionality of ERC721Base through the following steps: * Importing the ERC721Base contract * Inheriting the contract by declaring that our contract is an ERC721Base contract * Implementing any required methods, such as the constructor. 5. After modifying your contract with your desired custom logic, you may deploy it to BEVM using [Deploy](https://portal.thirdweb.com/deploy). **Deploying contract**[**​**](https://docs.astar.network/docs/build/EVM/developer-tooling/thirdweb#deploying-contract) {% hint style="info" %} Set the max base fee as 0.05 GWei and the max priority fee as 0.05 GWei at Metamask for BEVM Canary (Chain ID: 1501) {% endhint %} Deploy allows you to deploy a smart contract to any EVM compatible network without configuring RPC URLs, exposing your private keys, writing scripts, and other additional setup such as verifying your contract. 1. To deploy your smart contract using deploy, navigate to the root directory of your project and execute the following command: ``` npx thirdweb deploy ``` Executing this command will trigger the following actions(automatical): * Compiling all the contracts in the current directory. * Providing the option to select which contract(s) you wish to deploy. * Uploading your contract source code (ABI) to IPFS. 2. When it is completed, it will open a dashboard interface to finish filling out the parameters. * `_royaltyRecipient`: wallet address to receive royalties from secondary sales * `_royaltyBps`: basis points (bps) that will be given to the royalty recipient for each secondary sale, e.g. 500 = 5% * `_name`: contract name * `_symbol`: symbol or "ticker" 3. Connect wallet 4. Select BEVM as the network 5. Adjust additional settings on your contract's dashboard as required, including tasks like uploading NFTs, configuring permissions, and more For additional information on Deploy, please reference [thirdweb’s documentation](https://portal.thirdweb.com/deploy). #### Learn more[​](https://docs.astar.network/docs/build/EVM/developer-tooling/thirdweb#learn-more) If you have any additional questions or face any challenges throughout the process, feel free to [reach out to thirdweb support](https://support.thirdweb.com/). # Integrations # Oracle # Supra ## Overview Supra is a novel, high-throughput Oracle & IntraLayer: A vertically integrated toolkit of cross-chain solutions (data oracles, asset bridges, automation network, and more) that interlink all blockchains, public (L1s and L2s) or private (enterprises).\ Supra provides decentralized oracle price feeds that can be used for on-chain and off-chain use-cases such as spot and perpetual DEXes, lending protocols, and payments protocols. Supra’s oracle chain and consensus algorithm makes it the fastest-to-finality oracle provider, with layer-1 security guarantees. The pull oracle has a sub-second response time. Aside from speed and security, Supra’s rotating node architecture gathers data from 40+ data sources and applies a robust calculation methodology to get the most accurate value. The node provenance on the data dashboard also provides a fully transparent historical audit trail. Supra’s Distributed Oracle Agreement (DORA) paper was accepted into ICDCS 2023, the oldest distributed systems conference. ## Contract on BEVM | Network | Pull Contract | Storage Contract | | ------------ | ------------------------------------------ | ------------------------------------------ | | BEVM Mainnet | 0x8B506d2616671b6742b968C18bEFdA1e665A9025 | 0x58e158c74DF7Ad6396C0dcbadc4878faC9e93d57 | | BEVM TestNet | 0x443A0f4Da5d2fdC47de3eeD45Af41d399F0E5702 | 0x5df499C9DB456154F81121282c0cB16b59e74C4b | ## Use Case Supra official docs provide abundant examples of contracts and other codes, you can just view [here](https://supra.com/docs/data-feeds/pull-model/data-pair-conversion/) for more info. # DIA ## Overview DIA is a cross-chain oracle platform for Web3. It serves as an ecosystem for transparent financial data within a smart contract environment dedicated to finance. DIA's mission is to foster a collaborative environment among data analysts, providers, and consumers. Essentially, DIA offers a trustworthy and verifiable conduit linking external data from diverse origins to on-chain smart contracts, facilitating the creation of a myriad of financial decentralized applications. DIA is architected as a hybrid framework, integrating off-chain mechanisms for the storage and manipulation of extensive datasets, with on-chain elements that supply data to financial smart contracts. ### DIA's API Display the most transparent data to your users using DIA's API. Whether you're developing a financial service, a portfolio management tool, a new media platform, or anything else, DIA provides the most advanced and up-to-date data for your product. ### API Access The base URL for DIA is . All API paths are extensions of this base URL. Detailed documentation for our API endpoints can be found on the [API documentation site](https://docs.diadata.org/documentation/api-1/api-endpoints). ### DIA's Oracle Here is an overview of the deployed oracle contracts on each supported chain. DIA Development Oracle contracts are smart contracts that offer a selected range of asset prices for live testing on our Mainnet and Testnet. These contracts are regularly updated and replaced, not maintained indefinitely. DIA Development Oracle contracts are not meant to be integrated into a dApp. DIA creates specific contracts for dApps. To request a dedicated oracle, please contact the team on their website[ Discord ](https://discord.gg/bHKuz3bzaA)or the [DIA DAO Forum](https://dao.diadata.org/). ### Deployed Contracts {% tabs %} {% tab title="BEVM Mainnet" %}
ParameterValue
Smart Contract0x9a9a5113b853b394E9BA5FdB7e72bC5797C85191
Oracle TypeKey/Value Oracle
Seeds

"BTC/USD"
"ORDI/USD"
"ETH/USD"

"SATS/USD"

{% endtab %} {% tab title="BEVM Canary" %} | Parameter | Value | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Smart Contract | 0x719108DC653CC3a9055ab8d9018c5D7924912631 | | Oracle Type | [Key/Value Oracle](https://docs.diadata.org/documentation/oracle-documentation/access-the-oracle#dia-key-value-oracle-contract-v2) | | Seeds |

"BTC/USD"
"ORDI/USD"

| | {% endtab %} | | | {% endtabs %} | | ### Example (Solidity) ```solidity pragma solidity ^0.8.13; interface IDIAOracleV2{ function getValue(string memory) external returns (uint128, uint128); } contract IntegrationSample{ address immutable ORACLE = 0x719108DC653CC3a9055ab8d9018c5D7924912631; uint128 public latestPrice; uint128 public timestampOflatestPrice; function getPriceInfo(string memory key) external { (latestPrice, timestampOflatestPrice) = IDIAOracleV2(ORACLE).getValue(key); } function checkPriceAge(uint128 maxTimePassed) external view returns (bool inTime){ if((block.timestamp - timestampOflatestPrice) < maxTimePassed){ inTime = true; } else { inTime = false; } } } ``` #### Result
# Indexer Indexer # SubQuery SubQuery is a fast, flexible, and reliable open-source data decentralised infrastructure network. The SubQuery Data indexer is a open-source data indexer that provides you with custom APIs for your web3 project across all of our supported chains. ## Preparation ### 1、Nodejs Download from Github ``` curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash ``` {% hint style="info" %} Remember to add nvm to the shell environment. {% endhint %} Select node version ``` nvm use 20 ``` ### 2、Docker Compose Download from Github ``` sudo curl -L https://github.com/docker/compose/releases/download/v2.25.0/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose ``` Execution permission ``` sudo chmod +x /usr/local/bin/docker-compose ``` Check the version ``` docker-compose --version ``` ## About SubQuery ### 1. Install the SubQuery CLI Install SubQuery CLI globally on your terminal by using NPM. We **do not** encourage the use of `yarn global` for installing `@subql/cli` due to its poor dependency management. This may lead to multiple errors. ``` # NPM npm install -g @subql/cli # Test that it was installed correctly subql --help ``` ### 2. Initialise a new SubQuery Project Run the following command inside the directory that you want to create a SubQuery project in: ``` subql init ``` You'll be asked certain questions as you proceed ahead: * **Project name**: A project name for your SubQuery project. * **Network family**: The layer-1 blockchain network family that this SubQuery project will index. Use the arrow keys to select from the available options (scroll down as there are multiple pages). * **Network**: The specific network that this SubQuery project will index. Use the arrow keys to select from the available options (scroll down as there are multiple pages). * **Template project**: Select a SubQuery template project that will provide a starting point in the development. For some networks we provide multiple examples. * **RPC endpoint**: Provide an HTTP or websocket URL to a running RPC endpoint, which will be used by default for this project. You can use public endpoints for different networks, your own private dedicated node, or just use the default endpoint. This RPC node must have the entire state of the data that you wish to index, so we recommend an archive node. * **Git repository**: Provide a Git URL to a repo that this SubQuery project will be hosted in. * **Authors**: Enter the owner of this SubQuery project here (e.g. your name!) or accept the provided default. * **Description**: Provide a short paragraph about your project that describes what data it contains and what users can do with it, or accept the provided default. * **Version**: Enter a custom version number or use the default (`1.0.0`). * **License**: Provide the software license for this project or accept the default (`MIT`). Let’s look at an example:
Ethereum Project Scaffolding You can generate a project from a JSON ABIs to save you time when creating your project in EVM chains. Please see [EVM Project Scaffolding](https://academy.subquery.network/quickstart/quickstart.html#evm-project-scaffolding) After you complete the initialisation process, you will see a folder with your project name created inside the directory. Please note that the contents of this directory should be near identical to what's listed in the [Directory Structure](https://academy.subquery.network/build/introduction.html#directory-structure). Finally, run the following command to install the new project’s dependencies from within the new project's directory. {% tabs %} {% tab title="npm" %} ``` cd PROJECT_NAME npm install ``` {% endtab %} {% tab title="yarn" %} ``` cd PROJECT_NAME yarn install ``` {% endtab %} {% endtabs %} You have now initialised your first SubQuery project with just a few simple steps. Let’s now customise the standard template project for a specific blockchain of interest. You may want to refer to the [command line arguments](https://academy.subquery.network/run_publish/references.html) used in SubQuery. It will help you understand the commands better. ### 3. Run a template We use Ethereum packages, runtimes, and handlers (e.g. `@subql/node-ethereum`, `ethereum/Runtime`, and `ethereum/*Hander`) for BEVM Canary Network. Since BEVM is an EVM-compatible layer-2 scaling solution, we can use the core Ethereum framework to index it. #### Your Project Manifest File The Project Manifest file is an entry point to your project. It defines most of the details on how SubQuery will index and transform the chain data. For EVM chains, there are three types of mapping handlers (and you can have more than one in each project): * [BlockHanders](https://academy.subquery.network/build/manifest/ethereum.html#mapping-handlers-and-filters): On each and every block, run a mapping function * [TransactionHandlers](https://academy.subquery.network/build/manifest/ethereum.html#mapping-handlers-and-filters): On each and every transaction that matches optional filter criteria, run a mapping function * [LogHanders](https://academy.subquery.network/build/manifest/ethereum.html#mapping-handlers-and-filters): On each and every log that matches optional filter criteria, run a mapping function As we are indexing all transfers and approvals from the Wrapped BTC contract on BEVM Canary Network, the first step is to import the contract abi definition which can be obtained from from any standard [ERC-20 contractopen in new window](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/). Copy the entire contract ABI and save it as a file called `erc20.abi.json` in the `/abis` directory. #### Update the `datasources` section as follows: ```javascript { dataSources: [ { kind: EthereumDatasourceKind.Runtime, startBlock: 9680021, options: { // Must be a key of assets abi: "erc20", // This is the contract address for Wrapped BTC https://scan-canary.bevm.io/address/0x09Ff8E49D0EA411A3422ed95E8f5497D4241F532 address: "0x09Ff8E49D0EA411A3422ed95E8f5497D4241F532", }, assets: new Map([["erc20", { file: "./abis/erc20.abi.json" }]]), mapping: { file: "./dist/index.js", handlers: [ { kind: EthereumHandlerKind.Call, handler: "handleTransaction", filter: { /** * The function can either be the function fragment or signature * function: '0x095ea7b3' * function: '0x7ff36ab500000000000000000000000000000000000000000000000000000000' */ function: "approve(address spender, uint256 rawAmount)", }, }, { kind: EthereumHandlerKind.Event, handler: "handleLog", filter: { /** * Follows standard log filters https://docs.ethers.io/v5/concepts/events/ * address: "0x60781C2586D68229fde47564546784ab3fACA982" */ topics: [ "Transfer(address indexed from, address indexed to, uint256 amount)", ], }, }, ], }, }, ], } ``` The above code indicates that you will be running a `handleTransaction` mapping function whenever there is a `approve` method being called on any transaction from the [Wrapped BTC Tokenopen in new window](https://scan-canary.bevm.io/address/0x09Ff8E49D0EA411A3422ed95E8f5497D4241F532) on BEVM's Canary Network. The code also indicates that you will be running a `handleLog` mapping function whenever there is a `Transfer` event being emitted from the [Wrapped BTC Tokenopen in new window](https://scan-canary.bevm.io/address/0x09Ff8E49D0EA411A3422ed95E8f5497D4241F532) on BEVM's Canary Network. {% hint style="success" %} Check out our [Manifest File](https://academy.subquery.network/build/manifest/ethereum.html) documentation to get more information about the Project Manifest (`project.ts`) file. {% endhint %} #### Update Your GraphQL Schema File The `schema.graphql` file determines the shape of your data from SubQuery due to the mechanism of the GraphQL query language. Hence, updating the GraphQL Schema file is the perfect place to start. It allows you to define your end goal right at the start. Remove all existing entities and update the `schema.graphql` file as follows. Here you can see we are indexing block information such as the id, blockHeight, transfer receiver and transfer sender along with an approvals and all of the attributes related to them (such as owner and spender etc.). ``` type Transfer @entity { id: ID! # Transaction hash blockHeight: BigInt to: String! from: String! value: BigInt! contractAddress: String! } type Approval @entity { id: ID! # Transaction hash blockHeight: BigInt owner: String! spender: String! value: BigInt! contractAddress: String! } ``` {% hint style="success" %} Importantly, these relationships can not only establish one-to-many connections but also extend to include many-to-many associations. To delve deeper into entity relationships, you can refer to [this section](https://academy.subquery.network/build/graphql.html#entity-relationships). If you prefer a more example-based approach, our dedicated [Hero Course Module](https://academy.subquery.network/academy/herocourse/module3.html) can provide further insights. {% endhint %} SubQuery simplifies and ensures type-safety when working with GraphQL entities, smart contracts, events, transactions, and logs. The SubQuery CLI will generate types based on your project's GraphQL schema and any contract ABIs included in the data sources. {% tabs %} {% tab title="npm" %} ``` npm run-script codegen ``` {% endtab %} {% tab title="yarn" %} ``` yarn codegen ``` {% endtab %} {% endtabs %} This action will generate a new directory (or update the existing one) named `src/types`. Inside this directory, you will find automatically generated entity classes corresponding to each type defined in your `schema.graphql`. These classes facilitate type-safe operations for loading, reading, and writing entity fields. You can learn more about this process in [the GraphQL Schema section](https://academy.subquery.network/build/graphql.html). It will also generate a class for every contract event, offering convenient access to event parameters, as well as information about the block and transaction from which the event originated. You can find detailed information on how this is achieved in the [EVM Codegen from ABIs](https://academy.subquery.network/build/introduction.html#evm-codegen-from-abis) section. All of these types are stored in the `src/types/abi-interfaces` and `src/types/contracts` directories. You can conveniently import all these types: ```javascript import { Approval, Transfer } from "../types"; import { ApproveTransaction, TransferLog, } from "../types/abi-interfaces/Erc20Abi"; ``` Check out the [GraphQL Schema](https://academy.subquery.network/build/graphql.html) documentation to get in-depth information on `schema.graphql` file. Now that you have made essential changes to the GraphQL Schema file, let’s proceed ahead with the Mapping Function’s configuration. #### Add a Mapping Function Mapping functions define how blockchain data is transformed into the optimised GraphQL entities that we previously defined in the `schema.graphql` file. Navigate to the default mapping function in the `src/mappings` directory. You will be able to see two exported functions `handleLog` and `handleTransaction`: ```javascript import { Approval, Transfer } from "../types"; import { ApproveTransaction, TransferLog, } from "../types/abi-interfaces/Erc20Abi"; import assert from "assert"; export async function handleLog(log: TransferLog): Promise { logger.info(`New transfer transaction log at block ${log.blockNumber}`); assert(log.args, "No log.args"); const transaction = Transfer.create({ id: log.transactionHash, blockHeight: BigInt(log.blockNumber), to: log.args.to, from: log.args.from, value: log.args.value.toBigInt(), contractAddress: log.address, }); await transaction.save(); } export async function handleTransaction(tx: ApproveTransaction): Promise { logger.info(`New Approval transaction at block ${tx.blockNumber}`); assert(tx.args, "No tx.args"); const approval = Approval.create({ id: tx.hash, owner: tx.from, spender: await tx.args[0], value: BigInt(await tx.args[1].toString()), contractAddress: tx.to, }); await approval.save(); } ``` The `handleLog` function receives a `log` parameter of type `TransferLog` which includes log data in the payload. We extract this data and then save this to the store using the `.save()` function (*Note that SubQuery will automatically save this to the database*). The `handleTransaction` function receives a `tx` parameter of type `ApproveTransaction` which includes transaction data in the payload. We extract this data and then save this to the store using the `.save()` function (*Note that SubQuery will automatically save this to the database*). {% hint style="success" %} For more information on mapping functions, please refer to our [Mappings](https://academy.subquery.network/build/mapping/ethereum.html) documentation. {% endhint %} #### Build Your Project Next, build your work to run your new SubQuery project. Run the build command from the project's root directory as given here: {% tabs %} {% tab title="npm" %} ``` npm run-script build ``` {% endtab %} {% tab title="yarn" %} ``` yarn build ``` {% endtab %} {% endtabs %} {% hint style="success" %} Whenever you make changes to your mapping functions, you must rebuild your project. {% endhint %} Now, you are ready to run your first SubQuery project. Let’s check out the process of running your project in detail. Whenever you create a new SubQuery Project, first, you must run it locally on your computer and test it and using Docker is the easiest and quickiest way to do this. #### Run Your Project Locally with Docker The `docker-compose.yml` file defines all the configurations that control how a SubQuery node runs. For a new project, which you have just initialised, you won't need to change anything. However, visit the [Running SubQuery Locally](https://academy.subquery.network/run_publish/run.html) to get more information on the file and the settings. Run the following command under the project directory: {% tabs %} {% tab title="npm" %} ``` npm run-script start:docker ``` {% endtab %} {% tab title="yarn" %} ``` yarn start:docker ``` {% endtab %} {% endtabs %} {% hint style="success" %} It may take a few minutes to download the required images and start the various nodes and Postgres databases. {% endhint %} #### Query your Project Next, let's query our project. Follow these three simple steps to query your SubQuery project: 1. Open your browser and head to `http://localhost:3000`. 2. You will see a GraphQL playground in the browser and the schemas which are ready to query. 3. Find the *Docs* tab on the right side of the playground which should open a documentation drawer. This documentation is automatically generated and it helps you find what entities and methods you can query. Try the following queries to understand how it works for your new SubQuery starter project. Don’t forget to learn more about the [GraphQL Query language](https://academy.subquery.network/run_publish/query/graphql.html). ```graphql # Write your query or mutation here { query { transfers(first: 5, orderBy: VALUE_DESC) { totalCount nodes { id blockHeight from to value contractAddress } } } } ``` You will see the result similar to below: ```json { "data": { "query": { "transfers": { "totalCount": 5, "nodes": [ { "id": "0x625fd9f365a1601486c4176bc34cf0fdf04bf06b2393fd5dd43e8dd7a62d9ec5", "blockHeight": "53", "from": "0x0000000000000000000000000000000000000000", "to": "0xb680c8F33f058163185AB6121F7582BAb57Ef8a7", "value": "1000000000000000000000000", "contractAddress": "0x28687c2A4638149745A0999D523f813f63b4786F" }, { "id": "0x32057c64d795a7f919925082b9cdc885e307e3a4590377154d746beadc557d3e", "blockHeight": "62", "from": "0xb680c8F33f058163185AB6121F7582BAb57Ef8a7", "to": "0xCa8c45FE7FEDc3922266A1964cD8B8D29946A6A7", "value": "300000000000000000000", "contractAddress": "0x28687c2A4638149745A0999D523f813f63b4786F" }, { "id": "0xc591997f3217f6dfb6d4dad244126ad4ce245234fe452339b5ba8ad4d4264bdc", "blockHeight": "66", "from": "0xCa8c45FE7FEDc3922266A1964cD8B8D29946A6A7", "to": "0xb21aBf688A6bE0975134a41e73bf2c8Da111fF0d", "value": "50000000000000000000", "contractAddress": "0x28687c2A4638149745A0999D523f813f63b4786F" }, { "id": "0x1e29daac0434ad4936391e7ba439146ecd9ff9d65869436d466a8e48963e420a", "blockHeight": "67", "from": "0xCa8c45FE7FEDc3922266A1964cD8B8D29946A6A7", "to": "0xe42A2ADF3BEe1c195f4D72410421ad7908388A6a", "value": "50000000000000000000", "contractAddress": "0x28687c2A4638149745A0999D523f813f63b4786F" }, { "id": "0x73e95b32fe50daf7d0480a7dbd3005fcf22007ebff82fc6fa06a0c606783a0e3", "blockHeight": "68", "from": "0xe42A2ADF3BEe1c195f4D72410421ad7908388A6a", "to": "0x6F715c294Dd78BB11aeB0817B44E2a0b06e3A0B4", "value": "1000000000000000000", "contractAddress": "0x28687c2A4638149745A0999D523f813f63b4786F" } ] } } } } ```

Example

{% hint style="success" %} The final code of this project can be found [hereopen in new window](https://github.com/subquery/ethereum-subql-starter/tree/main/BEVM/bevm-canary-starter). {% endhint %} The final code of this project can be found [here](https://github.com/subquery/ethereum-subql-starter/tree/main/BEVM/bevm-canary-starter). ### 5. Make Changes to Your Project There are 3 important files that need to be modified. These are: 1. The GraphQL Schema in `schema.graphql`. 2. The Project Manifest in `project.ts`. 3. The Mapping functions in `src/mappings/` directory. ### 6. EVM Project Scaffolding Scaffolding saves time during SubQuery project creation by automatically generating typescript facades for EVM transactions, logs, and types. When you are initalising a new project using the `subql init` command, SubQuery will give you the option to set up a scaffolded SubQuery project based on your JSON ABI. If you select a compatible network type (EVM), it will prompt: ``` ? Do you want to generate scaffolding with an existing abi contract? ``` For example, to create the [Ethereum Gravatar indexer](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html), download the Gravity ABI contract JSON from [Etherscanopen in new window](https://etherscan.io/address/0x2e645469f354bb4f5c8a05b3b30a929361cf77ec#code), save it as `Gravity.json`, and then run the following: ![Project Scaffolding EVM](https://academy.subquery.network/assets/img/build/project-scaffold-evm.png) Once completed, you will have a scaffold project structure from your chosen ABI `functions`/`events`. You can read more about this feature in [Project Scaffolding](https://academy.subquery.network/build/introduction.html#evm-project-scaffolding) # Account Abstraction Abstract # Particle Network **Particle Network's goal is to abstract away the complexities associated with user onboarding and interactions across the multi-chain ecosystem, paving the way for mass Web3 adoption.** [Here](https://developers.particle.network/docs/getting-started) is the getting-started page of Particle Network. # Libraries Libraries # ethereum-list/chains GEB Mainnet, GEB Signet and BEVM Canary is listed on the official ethereum-lists/chains repository that is pulled by many cross-chain projects like chainlist.org, thirdweb, and Cookbook.dev. You can get access to different key parameters for the GEB Mainnet chains like: 1. chainId 2. RPC Endpoints 3. Native Currency settings 4. Explorer info 5. GEB Mainnet Icon See the official repo [here](https://github.com/ethereum-lists/chains/blob/master/_data/chains/eip155-11501.json)
# Wagmi Wagmi Wagmi is a set of React Hooks that provides all the necessary tools to begin working with GEB Mainnet. Wagmi simplifies tasks such as "Connect Wallet," displaying ENS and balance details, signing messages, interacting with contracts, and more, all while offering caching, request deduplication, and persistence features. Refer to [Wagmi documentation ](https://wagmi.sh/core/why)for additional information. # Multicall3 Multicall consolidates outcomes from various contract constant function calls. This minimizes the quantity of distinct JSON RPC requests required (particularly beneficial when utilizing a third-party RPC server), ensuring that all returned values originate from the same block (similar to an atomic read). Additionally, it includes the block number from which the values are retrieved, offering crucial context to disregard results from outdated blocks if sourced from a node that is not up-to-date. {% tabs %} {% tab title="GEB Mainnet" %} [0xa7487A536968Be0D563901aeb3Fc07B099e2fb04](https://scan-mainnet.bevm.io/address/0xa7487A536968Be0D563901aeb3Fc07B099e2fb04?tab=contract) {% endtab %} {% endtabs %} # Canonical contracts The following contract addresses are canonical on the BEVM Mainnet: ### Common Good Contracts[​](https://docs.astar.network/docs/build/zkEVM/canonical-zkevm-contracts#common-good-contracts)
TokenSourceContract
WBTCOfficial Wrapped BTC0xB5136FEba197f5fF4B765E5b50c74db717796dcD
stBTCBido0x26bda683F874e7AE3e3A5d3fad44Bcb82a7c107C
wstBTCBido0x2967E7Bb9DaA5711Ac332cAF874BD47ef99B3820
USDCOfficial Bridged USDC0x915247bf09471922e2c6da6f69fc9114708e8a26
USDTOfficial Bridged USDT0xa67ed736649f2958a35fd249a584151056b4b745
ETHOfficial Bridged ETH0x948def74953a18ebd854a5b015f63b0910be58cc
# Finality Typically, it takes 3 blocks (\~18 seconds) to be finalized. Considering the potential fluctuations in a PoS network, we provide a more secure method for finality detection. 1. **bevm\_isBlockFinalized**\ Parameter: EVM block hash\ Example: 
curl --location 'https://rpc-mainnet-1.bevm.io' \
   --header 'Content-Type: application/json' \
   --data '{
     "jsonrpc":"2.0",
     "method":"bevm_isBlockFinalized",
     "params":["0x0e5a331fb3cffea6900357a14079eed0e38fbeae633069b831ce124e05b2b0a3"],
     "id":1
   }'
2. **bevm\_isTxFinalized**\ Parameter: EVM transaction hash\ Example: ```bash curl --location 'https://rpc-mainnet-1.bevm.io' \ --header 'Content-Type: application/json' \ --data '{ "jsonrpc":"2.0", "method":"bevm_isTxFinalized", "params":["0xc86fe836e177d05399cb31e7a72a37ca40b287ba4f73ba347fbc8adba7fece62"], "id":1 }' ``` # Tokenomics This Tokenomics structure ensures a fair distribution mechanism with zero pre-mining, incorporating gradual token unlocks through mining while maintaining strategic allocations for Eco. development, community growth, and long-term sustainability. {% hint style="success" %} $GEB and $BEVM are the governance tokens on EVM and WASM chains, respectively. Essentially, they are the same coin and can be exchanged at a 1:1 ratio. When you complete a transfer between EVM and WASM, the conversion happens automatically. {% endhint %} ### Token Details
ParameterValue
Token NameGEB Governance Token
ChainGEB Chain(Wasm)
SymbolGEB
Decimal8
ParameterValue
Token NameBEVM Governance Token
ChainGEB Mainnet(EVM)
SymbolBEVM
Contract Address0xdCa01E9c0f6E7B3a8dF8297176ab4C94be89B6BB
Decimal8
### Total Token Allocation
* **Airdrop**: 10% * **Investors**: 10% * **Team**: 4% * **LBTC Protocol**: 30.4% * **BitAgere Protocol**: 41.225% * **Treasury**: 4.375% ### Mining Mechanism * Zero pre-mining policy - all tokens are unlocked through mining * Initial mining reward: 30,000 BEVM per session (1 hour) * Firstly halving occurs after 35,000 sessions (\~4 years) * Post-halving reward: 15,000 BEVM per session ### Vesting Schedule
#### Airdrop (10%) * First 12 months: 0.33% monthly unlock * Following 48 months: 0.125% monthly unlock * Total vesting period: 60 months #### L-BTC Stake (30.4%) * **First 60 months** * 40% allocation of remaining tokens per session after airdrop/investors/team distribution * **Post 60 months** * 40% allocation of unlocked tokens per session #### Agere Consensus (41.225%) * **First 60 months** * 60% allocation of remaining tokens per session after airdrop/investors/team distribution * **Post 60 months** * 50% allocation of unlocked tokens per session #### Investors (10%) * **Seed Round** * 6-month cliff period * 48-month linear vesting thereafter * **Series A** * 36-month linear vesting from TGE (Token Generation Event) #### Treasury (4.375%) * 60-month cliff period * Post-cliff: 10% allocation of unlocked tokens per session #### Team (4%) * 12-month cliff period * 48-month linear vesting thereafter # The Journy of GEB ## The journey of GEB {% stepper %} {% step %} **BTC Layer2 Exploration** To boost Bitcoin's throughput, Layer2 solutions aimed to enhance off-chain capacity but saw limited adoption, failing to impact broader usage. {% endstep %} {% step %} **Taproot Consensus** Combining Bitcoin SPV state channels with Taproot aimed to enable decentralized custody and expand smart contracts. However, with BTC already mainstream in exchanges and mining pools, improving its consensus mechanism was more crucial than enhancing its currency features. {% endstep %} {% step %} **SuperBitcoin** This stage introduced a crypto system leveraging Bitcoin's security, but it failed to address the "dreamworld disconnection" of Ethereum-like virtual machines, which operate solely within internal liquidity and lack real-world data integration. {% endstep %} {% step %} **BitAgere** BitAgere, drawing parallels between Bitcoin's "mechanical consensus" and AI agents' cognition, aimed to bridge perception gaps by integrating AI sensing on-chain, enhancing real-world awareness and Crypto-AI synergy. {% endstep %} {% step %} **BEVM(λ) Paradigm** BEVM(λ), built on Bitcoin's design, distills four pillars—Individual model, λ-calculus, consensus algorithm, and consensus-aware algorithm—while preserving energy conservation and decentralization. With the Agere subsystem, it boosts autonomy and intelligence via stateless computing and refined consensus. {% endstep %} {% step %} ### GEB {% endstep %} {% endstepper %} **To unlock more about GEB's development journey, please visit the official GEB website.** **To view more whitepapers, you can visit GEB's GitHub repository.** # Audit Reports You can check the audit reports [here](< https://github.com/btclayer2/audit-reports>). # Community Twitter: Discord: Developer TG Group: