# README ## BlockDAG Docs
BlockDAG is a high-performance, decentralized blockchain architecture based on Directed Acyclic Graph (DAG) technology. ### Overview BlockDAG is a next-generation blockchain protocol designed to enhance scalability, security, and transaction throughput using Directed Acyclic Graphs (DAG). Unlike traditional blockchains, BlockDAG allows multiple blocks to be confirmed simultaneously, reducing confirmation times and improving network efficiency. ### Features * **Scalability**: Supports parallel block creation, leading to higher transaction throughput. * **Security**: Uses robust consensus mechanisms to ensure network integrity. * **Decentralization**: Maintains a trustless environment with a distributed ledger. * **Low Latency**: Fast transaction confirmation times compared to traditional blockchains. * **Smart Contracts**: Compatible with Solidity-based contracts. ### Documentation BlockDAG's documentation is hosted on GitBook. Visit our docs for detailed guides, API references, and more: [![Read the Docs](https://img.shields.io/badge/Read%20Docs-GitBook-blue)](https://docs.blockdag.network) ### Contributing We welcome contributions from the community! Follow these steps to contribute: 1. Fork the repository. 2. Create a new branch (`feature-branch` or `fix-issue`). 3. Commit your changes. 4. Push to your fork and submit a Pull Request (PR). ### License This project is licensed under the MIT License. See LICENSE for details. ### Community & Support * Discord: [Join our community](https://discord.gg/VwWP2PZQbv) * Twitter: [@BlockDAGOfficial](https://twitter.com/blockdagnetwork) * Documentation: [GitBook Docs](https://docs.blockdag.network) * GitHub Issues: [Report an issue](https://github.com/BlockdagNetworkLabs/blockdag-scripts/issues) # Introduction to BlockDAG BlockDAG is an advanced Layer 1 blockchain platform inspired by Bitcoin and Kaspa, designed to address the scalability and efficiency limitations inherent in traditional blockchain architectures. By utilizing a Directed Acyclic Graph *(DAG)* structure, BlockDAG enables multiple transactions to be processed simultaneously, enhancing throughput and reducing confirmation times. This innovative approach positions BlockDAG as a scalable and efficient solution for decentralized applications and financial systems. BlockDAG is designed to focus on supporting financial and commercial applications by enabling secure, transparent, and scalable transactions. The protocol’s architecture fosters decentralization, security, and performance, ensuring a high degree of consensus efficiency, particularly in environments with high transaction volumes. In contrast to traditional blockchain architectures, where blocks are linearly connected, BlockDAG structures its blocks in a more complex, graph-like format. This allows multiple blocks to coexist and be processed in parallel, significantly improving network efficiency and throughput. #### Key Features * **High Scalability**: The DAG architecture allows for concurrent transaction processing, significantly increasing the network's capacity to handle a large volume of transactions without compromising performance. * **Enhanced Security**: Incorporating a cutting-edge Proof-of-Work *(PoW)* algorithm, BlockDAG ensures robust security measures, safeguarding the network against potential threats and attacks. * **Decentralization**: BlockDAG maintains a decentralized network structure, promoting trustless interactions and reducing the reliance on central authorities. #### **Differentiators from Other Blockchains** BlockDAG, introduces several enhancements and distinct features: * **DAG Structure:** Unlike traditional blockchain chains, BlockDAG organizes blocks in a DAG format, enabling multiple chains of blocks to coexist. This structure improves transaction speeds and allows for better scalability. * **Proof-of-Work *****(PoW)***** DAG Consensus:** BlockDAG employs a PoW consensus mechanism within a DAG framework. This hybrid model provides the security benefits of PoW while leveraging the scalability of DAG. # What is BDAG? BDAG is the native cryptocurrency of the BlockDAG ecosystem, serving as the foundational asset for transactions, smart contract execution, and network security. It plays a critical role in facilitating decentralized applications *(dApps)*, securing the network through mining incentives, and enabling seamless peer-to-peer value transfers. As a digital asset, BDAG is used to pay for computational resources, ensuring that transactions and smart contracts are executed efficiently within the BlockDAG framework. Unlike traditional **Proof-of-Stake *****(PoS)*** networks, BlockDAG operates on a **Proof-of-Work *****(PoW)*** consensus mechanism, where miners validate transactions and secure the network by solving complex cryptographic puzzles. This ensures decentralization, immutability, and resistance to censorship. BDAG also functions as a store of value and a medium of exchange, allowing users to participate in the ecosystem without relying on intermediaries. Additionally, BDAG fuels the smart contract ecosystem by covering gas fees for contract execution and interactions with decentralized applications. Its integration with the broader blockchain space makes BDAG a crucial asset for enabling scalable, secure, and transparent blockchain solutions within the BlockDAG network. # Introductory Concepts ## **Overview** Blockchain technology operates as a decentralized and secure system where transactions, smart contracts, and computational processes run without a central authority. This ensures privacy, security, and transparency across the network. Understanding the core components of blockchain—including transactions, blocks, the Ethereum Virtual Machine (EVM), and gas fees—is essential for developers, users, and potential investors looking to leverage blockchain technology effectively. ### **1. Decentralized Applications (dApps)** Decentralized Applications (dApps) are software applications that run on blockchain networks rather than centralized servers. They utilize smart contracts to execute logic without relying on intermediaries. #### **Key Characteristics of dApps:** * **Decentralization:** Data and records are stored on a blockchain rather than a centralized server. * **Transparency:** Transactions and smart contract executions are publicly verifiable. * **Censorship Resistance:** No single entity can control or shut down a dApp. * **Trustless Execution:** Smart contracts ensure automated and reliable execution of logic. Examples of dApps include decentralized finance (DeFi) platforms, NFT marketplaces, and blockchain-based games. ### **2. Accounts** Blockchain accounts are used to store and manage assets, execute transactions, and interact with smart contracts. The two main types of blockchain account models are: #### **EVM Account (Ethereum Virtual Machine Account)** EVM accounts are used in Ethereum and EVM-compatible blockchains. They are categorized into: * **Externally Owned Accounts (EOAs):** Controlled by private keys; used by individuals to send transactions and interact with smart contracts. * **Contract Accounts:** Smart contract addresses that execute code when triggered by an EOA or another contract. EVM accounts are identified by a unique 20-bytes address, and transactions require **gas fees** to execute operations on the network. ### **3. Transactions** Transactions are the fundamental operations on a blockchain. They represent value transfers, smart contract interactions, or other blockchain-related activities. #### **Transaction Structure:** A typical blockchain transaction consists of: * **Sender Address:** The account initiating the transaction. * **Receiver Address:** The destination account or contract. * **Amount:** The value transferred (e.g., BDAG, coins). * **Gas Fees:** Computational fees required to execute the transaction. Transactions are verified by miners before being included in a block. ### **4. Blocks** A **block** is a collection of transactions that is cryptographically linked to previous blocks, forming the blockchain. #### **Components of a Block:** * **Block Header:** Includes metadata such as the previous block’s hash, timestamp, and nonce. * **Transactions:** A list of validated transactions. * **Merkle Root:** A cryptographic summary of all transactions in the block. Blocks are added to the blockchain through consensus mechanisms like Proof of Work (PoW) ensuring security and immutability. ### **5. Ethereum Virtual Machine (EVM)** The **Ethereum Virtual Machine (EVM)** is a decentralized computation engine that executes smart contracts. It operates on nodes running Ethereum or EVM-compatible blockchains. #### **Key Features of the EVM:** * **Smart Contract Execution:** Runs code in a deterministic and trustless manner. * **Turing Complete:** Can execute any computational logic. * **State Transition System:** Modifies blockchain state based on transactions. **Opcodes** Opcodes (operation codes) are low-level machine instructions that the EVM understands. Some key opcodes include: * **PUSH, POP:** Stack operations. * **CALL, DELEGATECALL:** Smart contract interactions. * **SSTORE, SLOAD:** Read/write storage operations. EVM opcodes enable complex smart contract logic and decentralized computation. ### **6. Gas Fees** Gas fees are transaction costs required to execute operations on blockchains like Ethereum. #### **How Gas Fees Work:** * **Gas Price:** Measured in Gwei (a fraction of BDAG), set by the user. * **Gas Limit:** The maximum amount of gas a transaction can consume. * **Total Fee = Gas Used × Gas Price.** Gas fees help prioritize transactions and compensate network miners for computational resources. They fluctuate based on network congestion and demand. #### **Conclusion** This section provides an introductory overview of key blockchain concepts. Understanding these fundamentals is essential for developers, users, and businesses building on blockchain technology. Jump to next page to know each section in detail. # Decentralized Application (dApps) A decentralized application *(dApp)* in the BlockDAG ecosystem is a blockchain-powered application that operates without a central authority, ensuring transparency, security, and efficiency. These applications are built using smart contracts that automate transactions and enforce rules, while a frontend interface enables seamless user interaction. Unlike traditional applications that rely on centralized servers, dApps on BlockDAG leverage parallel processing and distributed ledger technology, resulting in faster execution, greater scalability, and reduced transaction costs. The open and permission-less nature of BlockDAG allows developers to deploy custom smart contracts or integrate existing ones, accelerating innovation in DeFi, NFTs, gaming, and enterprise solutions. With high-speed transaction finality, robust security, and a scalable framework, BlockDAG provides an ideal infrastructure for next-generation dApps, offering a decentralized environment where users can interact with blockchain technology more efficiently than ever before. ### Prerequisites Before learning about dApps, you should cover the blockchain basics and read about the BlockDAG network architecture and how it's decentralized. ### Definition of a dApp A decentralized application *(dApp)* in the BlockDAG ecosystem is an application where the backend operates on a decentralized, peer-to-peer network instead of relying on centralized servers. This ensures that no single entity controls the application, making it trustless, secure, and censorship-resistant. The frontend of a dApp can be built using any programming language, just like a traditional application, but it interacts with the blockchain through smart contracts. Additionally, the frontend can be hosted on decentralized storage solutions such as IPFS, further eliminating single points of failure and increasing accessibility. * **Decentralized:** dApps operate on BlockDAG, an open public decentralized platform where no one person or group has control. * **Deterministic:** dApps perform the same function irrespective of the environment in which they get executed. * **Turing complete:** dApps can perform any action given the required resources. * **Isolated:** dApps are executed in a virtual environment known as Ethereum Virtual Machine so that if the smart contract has a bug, it won’t hamper the normal functioning of the blockchain network. ### Benefits of dApp development * **Zero downtime:** Once a smart contract is deployed on BlockDAG, it remains operational without interruptions. The decentralized network ensures that no single point of failure can disrupt the service, making it immune to Denial-of-Service *(DoS)* attacks or network failures. * **Privacy** **Protection:** Users can interact with dApps without revealing personal information or requiring third-party authentication. Transactions and interactions remain pseudonymous, providing a high degree of privacy and security. * **Censorship Resistance:** No central authority can restrict access to dApps, block transactions, or manipulate network data. This permission-less nature ensures that users and developers have unrestricted access to deploy smart contracts, execute transactions, and retrieve blockchain data without interference. * **Immutable and Secure Data:** All information stored on the BlockDAG blockchain is cryptographically secured and tamper-proof. Transactions are permanent, verifiable, and indisputable, ensuring complete data integrity and preventing fraud or manipulation. * **Trustless and Verifiable Computation:** Smart contracts on BlockDAG execute autonomously and predictably, eliminating the need for intermediaries. Unlike traditional financial or cloud-based systems where users must trust institutions, dApps offer transparent, verifiable, and trustless execution, enhancing fairness and security in digital interactions. # Accounts In BlockDAG, accounts are essential for managing transactions, interacting with smart contracts, and maintaining ownership of digital assets. The network supports only Account modal. These models facilitate different transaction mechanisms, enabling seamless execution of transactions and contract interactions within the ecosystem. # EVM Account EVM *(Ethereum Virtual Machine)* accounts in BlockDAG follow the account-based model, similar to Ethereum, where balances and transactions are recorded directly within the blockchain state. These accounts allow users to send transactions, deploy smart contracts, and interact with decentralized applications *(dApps)*. #### **Types of EVM Accounts:** * **Externally Owned Account *****(EOA)*****:** Controlled by private keys held by users. These accounts can initiate transactions, store BDAG coins, and interact with smart contracts. * **Contract Account:** Represents smart contracts deployed on the network. Unlike EOAs, contract accounts cannot initiate transactions on their own; they execute predefined functions when called by EOAs or other contracts. #### **Key Features of EVM-Based Accounts:** * **Direct Balance Management:** Users hold BDAG coins within their accounts and send transactions without requiring input/output models. * **Smart Contract Execution:** Contract accounts store executable code, enabling automated and trustless transaction processing. * **Flexible Transactions:** EOAs can send BDAG, interact with dApps, and deploy smart contracts seamlessly. # Transactions In BlockDAG, transactions are cryptographically signed instructions that allow accounts to interact with the network. When a transaction is initiated, it updates the state of the BlockDAG ledger, ensuring a secure and verifiable exchange of data or assets. The most basic type of transaction is transferring BDAG coins from one account to another. However, transactions in BlockDAG can also trigger smart contracts, deploy decentralized applications *(dApps)*, or execute complex computational tasks. ### Prerequisites To help you better understand this page, we recommend you first read [Accounts](/get-started/introductory-concepts/accounts) and our [introduction to our BlockDAG](/introduction-to-blockdag). ### What's a transaction? In the BlockDAG ecosystem, a transaction refers to an action initiated by an externally owned account *(EOA)*—an account controlled by a user rather than a smart contract. Transactions are essential for updating the state of the network, whether it's transferring BDAG coins, interacting with smart contracts, or deploying decentralized applications *(dApps)*. Once a transaction is submitted, it gets broadcast to the network, where miners execute it and propagate the state changes across all nodes. To ensure security, all transactions must be cryptographically signed by the sender’s private key before they are included in a validated block. ### Key Components of a BlockDAG Transaction * **Sender *****(from)*****:** The account initiating the transaction, which must sign it using its private key. * **Recipient *****(to)*****:** The address receiving the transaction. If it's an externally owned account *(EOA)*, it transfers BDAG coins; if it's a smart contract, it executes the contract code. * **Signature:** A cryptographic identifier confirming the authenticity of the sender and preventing fraud. * **Nonce:** A sequential counter ensuring each transaction is unique and preventing replay attacks. * **Value:** The amount of BDAG coins to be transferred from the sender to the recipient. * **Input Data:** An optional field used when calling smart contracts, containing encoded instructions for execution. * **Gas Limit:** The maximum computational work a transaction can perform, preventing excessive resource consumption. * **Max Fee Per Gas:** The highest amount a sender is willing to pay per unit of gas, ensuring priority in transaction processing. ### Processing Transaction on BlockDAG * **Transaction Creation:** A user initiates a transaction, specifying details such as the recipient, amount, and gas fee. * **Signing & Broadcasting:** The transaction is cryptographically signed using the sender’s private key and broadcasted to the BlockDAG network. * **Validation & Execution:** A miner executes the transaction, checks for correctness, and includes it in a validated block. * **State Update:** The transaction is finalized, updating the network state, and becoming permanently recorded on the blockchain. ### Types of transactions In the BlockDAG ecosystem, transactions serve as the foundation for updating network states, executing smart contracts, and transferring assets. BlockDAG supports multiple types of transactions, each designed to facilitate secure, efficient, and scalable blockchain interactions. 1. **Standard Transactions**\ A regular transaction is the most basic type, involving the transfer of BDAG coins from one externally owned account *(EOA)* to another. These transactions update account balances and are processed quickly due to BlockDAG’s parallel transaction execution model.
2. **Smart Contract Deployment Transactions**\ When a user deploys a new smart contract, a transaction is initiated without a recipient address *(`to` field remains empty)*. Instead, the contract code is included in the transaction’s data field, allowing miners to execute and deploy the contract onto the BlockDAG network. Once confirmed, the contract is assigned a unique contract address that can be interacted with.
3. **Smart Contract Execution Transactions**\ These transactions are used to interact with already deployed smart contracts. Here, the `to` address specifies the contract address, and the transaction includes input data that dictates the operation to be performed. This could involve swapping coins, executing DeFi protocols, minting NFTs, or any other programmable blockchain logic. # Blocks In BlockDAG, blocks serve as batches of transactions that are linked together through cryptographic hashes, forming a secure and immutable ledger. Each block contains a reference to the previous block’s hash, ensuring continuity and integrity across the entire network. Unlike traditional blockchain structures, BlockDAG’s unique Directed Acyclic Graph *(DAG)* architecture enhances transaction processing by allowing multiple blocks to be confirmed in parallel, significantly improving scalability and efficiency. ### Prerequisites Blocks are a very beginner-friendly topic. But to help you better understand this page, we recommend you first read [Accounts](/get-started/introductory-concepts/accounts), [Transactions](/get-started/introductory-concepts/transactions), and our [introduction to BlockDAG](/introduction-to-blockdag). ### Why blocks? In BlockDAG, transaction synchronization and consensus are achieved through an advanced Directed Acyclic Graph *(DAG)*-based structure, optimizing how transactions are processed, validated, and finalized. Instead of traditional linear blocks, multiple transactions can be confirmed in parallel, allowing for higher throughput, faster processing, and improved network scalability. Unlike conventional blockchains, where transactions are batched into a single block and validated sequentially, BlockDAG enables concurrent validation, reducing latency and congestion. This means multiple transactions are grouped, verified, and synchronized simultaneously across the network, ensuring a consistent and immutable ledger. ### How blocks work * In BlockDAG, transaction history is preserved through a strictly ordered structure, where each new block references its parent block via a cryptographic hash. This ensures an immutable and verifiable record of all transactions, reinforcing the integrity of the chain with each new block. Unlike traditional Proof-of-Stake *(PoS)* networks, BlockDAG operates on a Proof-of-Work *(PoW)* consensus mechanism, where miners compete to solve complex cryptographic puzzles to generate the next block. The first miner to successfully solve the puzzle validates the transactions and is rewarded with BDAG coins, incentivizing network participation and enhancing security. * The key steps in BlockDAG block creation and consensus include mining and Proof-of-Work, where transactions are batched into blocks and miners race to solve puzzles. Once a block is mined, it is broadcast to the network for validation, with nodes checking for integrity, preventing double-spending, and ensuring cryptographic correctness. After this, consensus is achieved, and the validated block is appended to the blockchain, ensuring a consistent transaction history. This process continues with a new block being mined every few seconds, maintaining high network security. * What sets BlockDAG’s PoW model apart is its security and immutability—altering historical transactions would require enormous computational resources, making fraud infeasible. The decentralization of the network ensures no central authority controls the system, with miners across the globe securing transactions. Furthermore, BlockDAG’s parallel block confirmations enhance scalability, allowing for increased throughput and reduced congestion. By leveraging PoW in a DAG-based structure, BlockDAG offers a secure, decentralized, and scalable solution, ideal for decentralized finance *(DeFi)*, enterprise applications, and next-generation blockchain technologies. ### Proof-of-Work Protocol * In a Proof-of-Work *(PoW)* system, validation of transactions and the creation of new blocks relies on computational power rather than the staking of assets like in Proof-of-Stake *(PoS)*. In BlockDAG, the PoW consensus mechanism works by having miners solve complex cryptographic puzzles, a process that requires significant computational effort. These miners compete to find a solution to the puzzle, and the first one to succeed is allowed to propose and validate the next block. * Once a miner successfully solves the puzzle, they bundle a set of transactions into a block and broadcast it to the network. Other miners in the network then verify the block's validity by independently executing the transactions, ensuring they match the proposed changes to the global ledger. This decentralized verification process guarantees that the block is added to the blockchain only if it meets all the necessary criteria, preventing fraudulent transactions from being confirmed. * In BlockDAG, unlike in traditional blockchains, blocks are created in parallel rather than sequentially, which significantly enhances scalability and throughput. Once a block is validated and added to the network, miners continue the process by solving additional puzzles for new blocks, creating a continuous, efficient mining cycle. * In case two conflicting blocks are discovered for the same transaction, BlockDAG employs a fork-choice algorithm, where miners use the block that has the most computational work *(i.e., the one supported by the greatest number of PoW efforts)*. This ensures the network's integrity and consistency by aligning all participants on the same valid chain. ### Block Time In BlockDAG, block time refers to the time interval between the creation of consecutive blocks within the network. Unlike traditional blockchain systems, where block time is generally fixed or probabilistic, BlockDAG's block time can vary based on the consensus mechanism and the structure of the network. In BlockDAG systems, blocks are created in parallel rather than in a sequential chain like in traditional blockchains. This architecture eliminates the rigid ***"slot-based"*** block time typically used in Proof-of-Work (PoW) networks. Instead of assigning a fixed block time to a specific miner, multiple blocks can be proposed simultaneously by different miners, increasing throughput and enabling faster transaction processing. Since BlockDAG doesn't rely on a single miner to create each block, transactions are validated and included in the network almost instantaneously with minimal delays. This helps reduce the block time, making the system more efficient and scalable. ### Block Size In BlockDAG, block sizes are carefully regulated to maintain network efficiency, decentralization, and scalability. Each block has a predefined target gas limit, which determines its computational capacity. However, to accommodate fluctuations in transaction demand, block sizes can dynamically increase up to twice the target limit, ensuring smooth processing without causing congestion. Miners play a crucial role in adjusting the block gas limit through consensus, allowing for flexibility based on real-time network conditions. To prevent network centralization and ensure accessibility for all participants, BlockDAG enforces strict limits on block sizes, ensuring that they cannot grow indefinitely. If blocks became arbitrarily large, less powerful nodes might struggle to keep up, leading to a concentration of power among high-resource miners. By capping block sizes, BlockDAG maintains decentralization, allowing a broader range of participants to contribute to network security and transaction validation. # EVM The Ethereum Virtual Machine *(EVM)* is a decentralized virtual environment that executes code consistently and securely across all Ethereum nodes. Nodes run the EVM to execute smart contracts, using ***"gas"*** to measure the computational effort required for operations, ensuring efficient resource allocation and network security. ### Prerequisites Some basic familiarity with common terminology in computer science, such as bytes, memory, and a stack, is necessary to understand the EVM. It would also be helpful to be comfortable with cryptography/blockchain concepts like hash functions and the Merkle tree. ### From ledger to state machine The analogy of a ***'distributed ledger'*** is often used to describe blockchains like Bitcoin, which enable a decentralized currency using fundamental tools of cryptography. The ledger maintains a record of activity, which must adhere to a set of rules that govern what someone can and cannot do to modify the ledger. \ For example, a Bitcoin address cannot spend more Bitcoin than it has previously received. These rules underpin all transactions on Bitcoin and many other blockchains. While Ethereum has its native cryptocurrency *(ETH)* that follows almost the same intuitive rules, it also enables a much more powerful function of smart contracts For this more complex feature, a more sophisticated analogy is required. Instead of a distributed ledger, Ethereum is a distributed state machine. Ethereum's state is a large data structure that holds not only all accounts and balances but also a *machine state*, which can change from block to block according to a pre-defined set of rules and which can execute arbitrary machine code. The specific rules of changing state from block to block are defined by the EVM. # Opcodes This document serves as an updated reference for BlockDAG opcodes, inspired by established opcode references. It provides an accessible yet comprehensive guide to the execution instructions utilized within the BlockDAG ecosystem. These opcodes define how transactions, contract execution, and state changes occur on the network. ### Understanding BlockDAG Opcodes In BlockDAG, opcodes are low-level instructions that the virtual machine executes to process transactions and smart contract operations. Each opcode performs a specific function, such as mathematical computations, data storage, or smart contract execution. ### Key Features of BlockDAG Opcodes * **Transaction Execution:** Opcodes define how transactions are processed and state changes are applied. * **Smart Contract Operations:** Contract interactions rely on opcode execution to enable decentralized applications. * **Gas Consumption:** Each opcode has an associated gas cost, ensuring efficient computation and network security. * **Storage & Memory Management:** Opcodes handle data storage, retrieval, and manipulation within smart contracts. ### Categories of BlockDAG Opcodes * **Arithmetic Operations:** Addition, subtraction, multiplication, and division of integers. * **Logical Operations:** Boolean operations like AND, OR, XOR, and bitwise shifting. * **Memory & Storage:** Reading and writing data from memory or contract storage. * **Execution Control:** Jumps, conditionals, and function calls within contracts. * **Blockchain Interaction:** Fetching block data, account balances, and interacting with contracts. ### Importance of Opcodes Execution in BlockDAG BlockDAG’s opcode architecture ensures efficient transaction processing and smart contract execution. Each opcode is optimized to support high-performance decentralized applications while maintaining security and decentralization. # Gas Fees Gas is essential to the BlockDAG network. It is the fuel that allows it to operate, in the same way that a car needs gasoline to run. ### Prerequisites To better understand this page, we recommend you first read up on transactions and the EVM. ### What is gas? In BlockDAG, gas is the unit that measures the computational effort required to execute transactions and smart contract operations. Every transaction processed on the network consumes a specific amount of gas, which reflects the computational work needed to validate and execute it. This system ensures that network resources are efficiently allocated, preventing spam attacks and protecting the blockchain from unnecessary computational strain. To execute any transaction, users must pay a gas fee, which is calculated based on the amount of gas required for the operation multiplied by the cost per unit of gas. This fee is paid regardless of whether a transaction succeeds or fails, ensuring that miners are compensated for their computational effort. By implementing a structured gas mechanism, BlockDAG maintains a secure, scalable, and economically sustainable network, balancing transaction efficiency with decentralized processing power. ### How are gas fees calculated? In **BlockDAG**, users set the amount of gas they are willing to pay when submitting a transaction, effectively bidding for inclusion in the next block. Higher gas fees increase the likelihood of faster confirmation, while lower fees may result in delays or non-execution. The total gas fee is composed of two main parts: the **base fee**, which is set by the protocol and is required for transaction validity, and the **priority fee *****(tip)***, which incentivizes miners to prioritize a transaction over others. If network demand is high, users may need to increase their priority fee to get their transactions confirmed quickly, while during periods of low congestion, lower fees may still result in timely execution. For instance, if a transaction requires **21,000 gas units** and the base fee is **10 gwei**, adding a **2 gwei** tip results in a total cost of **252,000 gwei *****(0.000252 BDAG)***. When the transaction is processed, the sender pays the total amount, the recipient receives the intended transfer, the miner collects the tip, and the base fee is burned to regulate the network’s economy. This system ensures fair pricing, prevents spam transactions, and maintains network efficiency, making BlockDAG a robust and cost-effective blockchain solution. # Nodes and Mining BlockDAG operates as a distributed network of interconnected nodes, each running specialized software to verify blocks and transaction data. These nodes ensure the security, transparency, and integrity of the BlockDAG ecosystem by continuously validating and propagating transactions across the network. To participate as a node in BlockDAG, users must run the necessary software on their computers, transforming them into active participants in the network. ### Prerequisites You should understand the concept of a peer-to-peer network and the basics of blockDAG before diving deeper and running your own instance of an Ethereum client. Take a look at our introduction to blockDAG. If you're new to the topic of nodes, we recommend first checking out our user-friendly introduction on node setup guide. ### What are nodes and clients? A **node** in BlockDAG refers to any instance of BlockDAG client software that connects with other nodes, collectively forming a decentralized network. A client is an implementation of BlockDAG that verifies data against protocol rules, ensuring network security and integrity. To function effectively, a BlockDAG node must operate two core clients: 1. **Execution Client:** This component listens to incoming transactions broadcast across the network, executes them within the BlockDAG environment, and maintains the latest state and database of all transactions and smart contracts. It serves as the engine that processes and validates transactions within the network. 2. **Consensus Client:** Responsible for implementing the **Proof-of-Work *****(PoW)*** consensus mechanism, this client ensures that the network reaches agreement on transaction history based on validated data from the execution client. Additionally, a node can integrate a ***"mining component"***, which enables it to participate in securing the network by solving cryptographic puzzles and appending new blocks to the ledger. By running a full BlockDAG node, users contribute to the decentralization, security, and efficiency of the ecosystem, ensuring a trustless and scalable blockchain infrastructure. # Node Setup Guide Automation helpers for running and maintaining a BlockDAG mainnet node with Docker. The scripts wrap the provided `docker-compose.yml` so you can bring a node up with a single command, manage restarts, and safely wipe local state when needed. ### Table of Contents * Features * Repository Layout * Requirements * Setup * Running the Node * Maintenance Tasks * Troubleshooting * Data & Security Notes * Reference: Docker Compose Service * Support ### Features * Single-entrypoint script (`blockdag.sh`) that loads your mining address and launches Docker Compose. * Cross-platform Docker Compose detection (`node.sh`) compatible with Compose v1 and v2 syntaxes. * Opinionated directory structure for persisted blockchain data, logs, and binaries under `bin/bdag/`. * Sample environment file (`.env`) for storing wallet configuration. * Optional Linux helper to install Docker & Docker Compose (`install_docker.sh`). ### Repository Layout ``` blockdag.sh # Primary launcher – loads wallet and calls node.sh node.sh # Starts docker compose with the provided mining address restart.sh # Stops current stack, removes image, restarts with existing data restartWithCleanup.sh # Same as above, but wipes ./bin/bdag before restart install_docker.sh # Ubuntu-based helper to install Docker & docker-compose docker-compose.yml # Defines the BlockDAG worker service and persisted volumes bin/bdag/data # Blockchain data volume (created at runtime) bin/bdag/logs # Node log output (created at runtime) .env # Optional environment file (example provided) wallet.txt # Optional file containing wallet info, last line read as mining address ``` > **Note:** `bin/bdag/data` and `bin/bdag/logs` may be empty until the node runs. If they contain testnet data generated by previous runs, they might require elevated permissions to inspect or delete. ### Requirements #### Operating Systems * **Linux (Ubuntu/Debian, Fedora, Arch, etc.)**: fully supported. Scripts assume a POSIX shell and Docker. * **macOS (Ventura 13+ recommended)**: supported as long as Docker Desktop is installed. * **Windows**: run inside [WSL2](https://learn.microsoft.com/windows/wsl/install) or another Linux-like environment. Native PowerShell is not supported by these scripts. #### Software * Docker Engine & Docker Compose v1 or v2. * Git (to clone the repository). * `bash` (all scripts use Bash features). Optional for Linux users: * `curl`, `apt`, etc. – `install_docker.sh` targets Ubuntu 20.04+ and requires root. #### Hardware Guidelines * **CPU**: Minimum 4 cores (4+ cores recommended for mining). * **Memory (RAM)**: At least 8GB (8GB+ recommended). * **Disk Space**: Minimum 20GB of free disk space. More storage is recommended depending on the size of the blockchain and logs. * **Network**: A stable internet connection with sufficient bandwidth. #### Wallet Format Notice * BlockDAG nodes now use **EVM-compatible public addresses (0x…)** for mining rewards. * Legacy **UTXO-based PK addresses are no longer supported**. Update any automation, scripts, or stored credentials to point to an EVM wallet before starting the node.
### Setup 1. **Clone the repository** ```bash git clone https://github.com/BlockdagNetworkLabs/blockdag-scripts.git cd blockdag-scripts ``` 2. **Configure your mining address** * Option A: edit `.env` and set `PUB_ETH_ADDR=`. * Option B: create `wallet.txt` where the last line contains your wallet address (e.g. exported from another tool). If both exist, `.env` takes precedence. > **Network note:** These scripts target the latest EVM-based BlockDAG network only. Do not reuse legacy UTXO addresses; configure a 0x-prefixed EVM wallet for mining rewards. 3. **Verify Docker access** ```bash docker --version docker compose version # or docker-compose --version ``` If Docker is not installed on Ubuntu, you can adapt the provided `install_docker.sh` script (requires `sudo`). 4. **Allow Docker to create local directories** Ensure your user has permissions to write to `bin/bdag/`. The directory is created automatically, but on Linux you may need to `chown` it if Docker runs as root.
### Address Format Update (EVM Only) * BlockDAG mining rewards are now paid to Ethereum-style accounts. Supply an `0x`-prefixed EVM public address wherever the scripts expect `PUB_ETH_ADDR`. * If you are migrating from earlier releases that referenced UTXO/PK addresses, regenerate or import an EVM wallet and update `.env` or `wallet.txt` accordingly. * Remove any legacy environment variables or files that still contain the deprecated address format to avoid accidental misconfiguration.
### Running the Node 1. Launch the node (prompts will depend on your shell configuration): ```bash ./blockdag.sh ``` The script resolves your address, exports it as `PUB_ETH_ADDR`, and calls `node.sh`. 2. `node.sh` selects the correct Docker Compose syntax for your installation and starts the stack with `MINING_ADDRESS` set from your EVM wallet. 3. Once the containers are up: ```bash docker ps # Verify the blockdag-mainnet-network container is running docker logs -f # Replace with actual container ``` To stop the node without cleaning data: ```bash docker compose down # or docker-compose down ``` ### Maintenance Tasks Use the helper scripts at the repository root: * `restart.sh` – shuts down Docker Compose, removes the `blockdagnetwork/awakening` image if present, and relaunches using your configured wallet. * `restartWithCleanup.sh` – same as above but also clears `./bin/bdag/*` (data, logs, any cached binaries). **Back up your wallet before running this.** * `install_docker.sh` – Ubuntu/WSL convenience installer. Review the script before executing (`sudo ./install_docker.sh`). Manual alternatives: ```bash # Pull the latest image MINING_ADDRESS=$PUB_ETH_ADDR docker compose pull # View logs docker compose logs -f # Remove volumes and containers docker compose down --volumes ``` ### Troubleshooting * **"PUB\_ETH\_ADDR not set"**: Confirm `.env` or `wallet.txt` exists and the address is on the last line. Reload your shell if you edited `.env` while a session was running. * **Docker permission denied**: Add your user to the `docker` group (`sudo usermod -aG docker $USER`) and restart your session, or run the scripts with `sudo`. * **Node restarts on launch**: Inspect `bin/bdag/logs` for recent log files. If corruption errors appear, run `./restartWithCleanup.sh` to wipe local state. * **Port conflicts**: Default ports 38131, 18545, 18546, and 18150 must be free. Stop other services using them or edit `docker-compose.yml`. * **Windows path issues**: Ensure the repository lives inside your WSL filesystem (e.g. `/home/`), not the mounted `C:` drive, to avoid Docker volume permission problems.
### Data & Security Notes * The wallet address (`PUB_ETH_ADDR`) is injected into the container as `MINING_ADDRESS`. It must be an EVM address; do not reuse retired UTXO-style identifiers. * Do not commit `.env` or `wallet.txt` with real keys. * Blockchain data persists in `bin/bdag/data/`. Back it up before destructive operations. * Logs populate `bin/bdag/logs/` and may contain sensitive operational details; sanitize before sharing. * Consider rotating Docker logs or mounting external storage if running long-term.
### Reference: Docker Compose Service `docker-compose.yml` launches a single service named `nodeworker` based on `abhishek1857/blockdag:worker-20250923-102625`. Key settings: * **Ports**: `38131` (RPC), `18545` (HTTP), `18546` (WebSocket), `18150` (peer). * **Volumes**: * `bdag_bin` named volume mounted at `/opt/bdag` inside the container. * Local `./bin/bdag/data` → `/bdag/data` for chain data. * Local `./bin/bdag/logs` → `/bdag/logs` for logs. * **Environment**: `NODE_ARGS` assembles mainnet flags, mining options, CORS/websocket settings, and seeds a peer. Customize the image tag or arguments directly in `docker-compose.yml` if the network releases new versions. # BlockDAG Architecture Introduction **1.1 Overview of BlockDAG Blockchain** BlockDAG is a novel blockchain protocol that adopts a Directed Acyclic Graph (DAG) architecture, similar to the Kaspa, Bitcoin and other blockchains. By leveraging a DAG structure, BlockDAG eliminates some of the inherent limitations found in traditional blockchains, such as scalability bottlenecks and confirmation delays. This allows for a more efficient and secure network that supports a higher transaction throughput and faster finality. BlockDAG is designed to focus on supporting financial and commercial applications by enabling secure, transparent, and scalable transactions. The protocol’s architecture fosters decentralization, security, and performance, ensuring a high degree of consensus efficiency, particularly in environments with high transaction volumes. In contrast to traditional blockchain architectures, where blocks are linearly connected, BlockDAG structures its blocks in a more complex, graph-like format. This allows multiple blocks to coexist and be processed in parallel, significantly improving network efficiency and throughput. **1.2 Objectives and Goals** The primary objective of the BlockDAG blockchain is to create a decentralized and scalable network that supports high transaction throughput while maintaining security and integrity. By using a DAG structure, BlockDAG seeks to address several challenges present in conventional blockchain systems, such as: * **Scalability:** Achieving a significantly higher number of transactions per second *(TPS)* compared to traditional blockchains. * **Low Confirmation Times:** Allowing for faster finalization of transactions by processing multiple blocks in parallel. * **Decentralization:** Enabling a broad range of nodes to participate in consensus without sacrificing performance. * **Security:** Mitigating common blockchain vulnerabilities, such as 51% attacks, by leveraging a novel consensus mechanism. Furthermore, BlockDAG aims to facilitate cross-chain compatibility *(Future Goal)* and support for smart contracts, making it a versatile platform for decentralized applications *(dApps)*. **1.3 Key Features & Differentiators from Other Blockchains** BlockDAG, introduces several enhancements and distinct features: * **DAG Structure:** Unlike traditional blockchain chains, BlockDAG organizes blocks in a DAG format, enabling multiple chains of blocks to coexist. This structure improves transaction speeds and allows for better scalability. * **Proof-of-Work *****(PoW)***** DAG Consensus:** BlockDAG employs a PoW consensus mechanism within a DAG framework. This hybrid model provides the security benefits of PoW while leveraging the scalability of DAG. # Architecture Overview **2.1 Technical Architecture:** 1. **User/Client Interface:** 1. Client(s) can communicate with blockchain using JSON-RPC methods using HTTP/HTTPS protocol. 2. **Network Layer:** 1. **P2P Network:** Uses TCP for reliable, connection-oriented communication between nodes. 2. **Peer Discovery:** Likely uses UDP for efficient, connectionless discovery of new peers. 3. **Block Propagation:** Uses TCP to ensure reliable delivery of new blocks. 4. **Transaction Propagation:** Also uses TCP for reliable transaction broadcasting. 3. **Consensus Layer:** 1. Communicates with the Network Layer using TCP/UDP. 2. **BlockDAG Management:** Handles the structure of the Directed Acyclic Graph. 3. **SPECTRE Protocol:** SPECTRE reduces the time it takes to confirm transactions by using recursive voting mechanisms between blocks. 4. **Block Validation:** Verifies the validity of new blocks. 4. **Storage Layer:** 1. Communicates with the Consensus and Execution Layers via Internal APIs. 2. **BlockDAG Store:** Persists the blockchain data using LevelDB. 3. **Transaction Pool:** Manages unconfirmed transactions. 5. **Execution Layer:** 1. Communicates with the Storage Layer and State Management via Internal APIs. 2. **Transaction Execution:** Processes individual transactions. 3. **Smart Contract VM:** Executes smart contract code 4. **State Management:** Receives state updates from the Execution Layer. 6. **Mining Node:** 1. Communicates with the Network Layer using the Stratum Protocol over TCP for mining pools. **2.2 Consensus Mechanism** BlockDAG employs a Directed Acyclic Graph *(DAG)* architecture with a Proof-of-Work *(PoW)* consensus mechanism. This hybrid design combines the security benefits of traditional PoW with the scalability offered by DAG structures. The DAG allows for partial asynchronous block production, where multiple blocks can be added to the DAG in parallel without waiting for sequential confirmations. **2.3 DAG Structure and Model** In BlockDAG, blocks are not only organized in a linear sequence but also as vertices in a DAG. This structure enables multiple chains of blocks to coexist, where each block can reference several previous blocks, creating a web of interconnections. This significantly enhances transaction throughput by allowing simultaneous block validation. **Each block contains:** * A unique block identifier *(hash)* * A reference to multiple previous blocks *(instead of just one parent block as in traditional blockchains)* * Transactions processed in the block * A proof of work for consensus validation The DAG structure helps mitigate common blockchain challenges, such as orphaned blocks, by allowing diverging branches *(or forks)* in the network to eventually merge back into the main graph. Unlike traditional blockchains, where forks can lead to orphaned blocks that do not contribute to the main chain, DAGs ensure that all valid transactions and blocks remain part of the overall network structure. This approach maintains data consistency and enhances transaction finality, reducing wasted computational resources and improving network efficiency. **2.4 Block Structure** The basic components of a BlockDAG block include: * **Header:** Contains block metadata, such as version, timestamp, and block height. * **Transaction Merkle Tree Root Hash:** Represents the transactions included in the block. * **DAG References:** Links to multiple parent blocks. * **Proof-of-Work (PoW) hash:** Used to validate and secure the block in the network. **2.5 Peer-to-Peer (P2P) Network Design** BlockDAG utilizes a decentralized P2P network for node communication and block propagation. Nodes in the network can act as either full nodes or miner nodes. Full nodes participate in block validation and consensus, while miner nodes store a reduced version of the ledger and primarily engage in transaction mining. The P2P network uses a gossip protocol to disseminate transactions and block data efficiently across the network, ensuring that information is shared rapidly among nodes. \ **2.6 Transaction Flow and Management** BlockDAG blocks follow a different flow compared to traditional blockchains due to the DAG structure. Transactions are submitted to the network, validated by nodes, and included in multiple parallel blocks, ensuring rapid finalization. # Core Modules and Components This section outlines the primary modules and components that constitute the BlockDAG blockchain. These components form the backbone of the system, ensuring that the network operates efficiently, securely, and at scale. **3.1 Node Design and Types** BlockDAG supports multiple types of nodes, each playing a vital role in maintaining network security, facilitating consensus, and ensuring efficient transaction processing. The two primary node types in BlockDAG are Full Nodes and Miner Nodes. **3.1.1 Full Nodes** Full nodes are the backbone of the BlockDAG network. They store a complete copy of the blockchain *(DAG)*, validate transactions, and participate actively in the consensus process. Full nodes are critical for maintaining the decentralized integrity of the network and ensuring that all transactions adhere to the consensus rules. **Key Responsibilities of Full Nodes:** * Validate all incoming transactions and blocks. * Store the entire ledger *(DAG)*, including all past transactions and blocks. * Ensure the security of the network by participating in the block validation process. * Communicate with other full nodes to propagate transaction and block information across the network. **3.1.2 Miner Nodes** Miner nodes are specialized nodes that participate in the consensus process by solving complex cryptographic puzzles as part of the Proof-of-Work *(PoW)* algorithm. Miner nodes add new blocks to the DAG, validate transactions, and compete to earn block rewards and transaction fees. **Key Responsibilities of Miner Nodes:** * Solve PoW puzzles to produce new blocks that reference multiple previous blocks in the DAG. * Validate transactions before adding them to a new block. * Propagate newly mined blocks across the network for validation by full nodes. * Secure the network by contributing computational power to prevent attacks *(e.g., 51% attacks)*. **Mining Process:** * Miners collect pending transactions from the transaction pool. * They attempt to solve a PoW puzzle to produce a valid block. * The newly produced block references multiple existing blocks in the DAG, reducing the chance of orphaned blocks. * Once the PoW is solved, the block is propagated to full nodes for validation and eventual inclusion in the ledger. Miner nodes are essential for maintaining the integrity and security of the BlockDAG network, as they ensure that blocks are added to the DAG through a competitive, decentralized process. They also contribute to the network's scalability by enabling parallel block creation in the DAG structure. **3.2 Wallet Integration and Management** BlockDAG supports wallet integration for users to securely store, send, and receive digital assets. Wallets interact with full nodes to broadcast transactions, check balances, and retrieve transaction histories. Wallets are designed with strong cryptographic mechanisms to ensure private key security and transaction integrity. * **Key Management:** BlockDAG uses asymmetric cryptography *(public-private key pairs)* to manage ownership and control of assets. The system supports standard cryptographic algorithms *(e.g., ECDSA or EdDSA)* to sign transactions and ensure data integrity. **3.3 Smart Contracts Support** BlockDAG is Ethereum Virtual Machine (EVM) compatible, allowing for seamless integration and deployment of Ethereum-based smart contracts. This compatibility ensures that developers familiar with Ethereum’s toolset, including Solidity and other Ethereum-compatible programming languages, can easily build and deploy decentralized applications (dApps) on the BlockDag network. * **EVM Compatibility:** The EVM serves as the runtime environment for executing smart contracts. By being EVM-compatible, BlockDAG enables the execution of Ethereum smart contracts without modification, providing the following benefits: * **Cross-Chain Compatibility:** Developers can migrate existing Ethereum dApps and tokens to BlockDAG with minimal changes. * **Developer Tools:** BlockDAG supports popular Ethereum development tools, such as Truffle, Remix, MetaMask, and Hardhat, simplifying the development and deployment processes. * **Interoperability with ERC Standards:** BlockDAG supports Ethereum token standards like ERC-20 *(fungible tokens)* and ERC-721 *(non-fungible tokens)*, facilitating token issuance and smart contract functionalities. * **Smart Contract Execution:** BlockDAG’s EVM ensures deterministic execution of smart contracts. Each contract is executed within the sandboxed EVM environment, ensuring security and isolation from other network operations. * **Gas Mechanism:** Similar to Ethereum, BlockDAG uses a gas mechanism to limit the resources consumed by smart contract execution. This ensures that contracts do not consume excessive computational resources, and it helps protect the network from denial-of-service *(DoS)* attacks. * **Smart Contract State Management:** Smart contracts can maintain and update state variables across transactions. The state is stored in the blockchain, and any changes to it are reflected across the network once the contract is executed and the block is confirmed. * **Key Features of Smart Contract Support:** * **Deterministic Execution:** Ensures that the outcome of smart contract execution is predictable and replicable by all nodes. * **State Persistence:** Contract state is maintained and updated securely in the BlockDag ledger. * **Gas Fees:** Users pay gas fees to miners for the execution of smart contracts, ensuring efficient use of network resources. * **Development Environment:** Developers can use Solidity to write smart contracts, leveraging the existing Ethereum developer ecosystem. Deployment and testing can be done using familiar frameworks, ensuring that developers can transition to BlockDag with minimal friction. **3.4 Cryptography and Security** Security is a cornerstone of the BlockDAG blockchain. The system leverages advanced cryptographic techniques to secure transactions, validate blocks, and protect against malicious activity. * **Asymmetric Encryption:** BlockDAG uses asymmetric encryption for transaction signing and validation. Each participant has a private key for signing transactions and a public key for others to verify those signatures. * **Hashing:** Blocks and transactions are hashed using a secure cryptographic algorithm *(e.g., SHA-256)* to ensure data integrity and prevent tampering. * **Proof of Work *****(PoW)*****:** BlockDAG employs a PoW-based consensus mechanism. Miners solve cryptographic puzzles *(Proof-of-Work)* to validate new blocks and add them to the DAG. This ensures that the network is resistant to attacks like double-spending or 51% attacks. * **Security Enhancements:** * **DDoS Protection:** Mechanisms like rate-limiting and anti-spam filtering are built into the network layer to prevent Distributed Denial-of-Service *(DDoS)* attacks. * **Sybil Attack Resistance:** By requiring proof of computational work, BlockDAG resists Sybil attacks, where an attacker tries to flood the network with fake nodes. **3.5 Consensus Algorithm Implementation** BlockDAG implements a consensus algorithm that combines Proof of Work *(PoW)* with DAG structures, which allows for parallel processing of transactions and blocks. Unlike traditional linear blockchain architectures, DAG-based consensus enables multiple blocks to reference each other and eventually converge into a consistent state. * **DAG-based Consensus:** * DAG consensus allows for multiple block producers *(miners)* to add blocks to the network simultaneously. These blocks are interconnected through directed acyclic references, meaning each block can point to multiple previous blocks. * **PoW Mechanism:** * Miners solve complex cryptographic puzzles to add a block to the DAG, similar to Bitcoin’s PoW. However, due to the DAG architecture, the network can handle multiple blocks being added in parallel, increasing throughput and lowering latency. * **Finalization:** * Blocks are considered final once they are referenced by enough subsequent blocks in the DAG. This process ensures that even though multiple blocks can be produced at the same time, the network eventually reaches consensus on the order and validity of transactions. # Development and Implementation This section outlines the essential technical aspects of how BlockDAG will be developed, including the tools, technology stack, integration strategies, and quality assurance methods. **4.1 Technology Stack** The BlockDAG blockchain leverages a powerful and modern technology stack to ensure compatibility, scalability, and security. Below is a detailed breakdown of the core technologies involved: * **Blockchain Framework:** Custom DAG-based framework. * **Consensus Protocol:** Proof-of-Work *(PoW)* based DAG algorithm, with enhancements to ensure EVM compatibility. * **Smart Contract Platform:** Ethereum Virtual Machine *(EVM)* for smart contract deployment and execution, allowing seamless integration with Ethereum-based dApps. * **Programming Languages:** * **Go (Golang):** Core blockchain development. * **Solidity:** For smart contract development, leveraging existing Ethereum-based libraries and frameworks. * **Storage:** Distributed, decentralized storage system for transaction history, DAG structure, and state databases. * **Database:** LevelDB for local node storage. * **Networking Protocols:** TCP/IP and UDP for peer-to-peer *(P2P)* networking, block propagation, and transaction validation. **4.2 Development Environment Setup** Setting up the development environment for BlockDAG involves installing and configuring the required tools, frameworks, and libraries: * **Local Development Environment**: * **Operating System:** Supports major OS environments like Linux *(preferred)*, macOS. * **Development Tools:** * **Go:** Core language for blockchain development. * **Node.js:** For integrating client-facing applications and smart contract interaction using Web3.js or Ethers.js. * **Solidity Compiler (solc):** For compiling smart contracts. * **Node Setup:** * Developers will be required to run BlockDAG nodes for testing and interaction with the network. Test nodes can be configured locally to simulate the behavior of the mainnet. * **Docker:** For containerized deployment of nodes in different environments. * **Wallet Setup:** * MetaMask and PlusWallet (future scope) can be used to interact with the EVM on BlockDAG for transactions and contract deployment. **4.3 Integration with Existing Systems *****(if any)*** BlockDAG EVM compatibility allows for integration with Ethereum-based projects and tools. This section outlines strategies for integrating BlockDAG with existing decentralized ecosystems: * **Smart Contracts:** BlockDAG can easily integrate Ethereum smart contracts with minimal modification. Solidity-based contracts can be deployed and executed directly on BlockDAG, providing access to a wide array of DeFi applications. * **Bridges for Cross-Chain Transactions:** Future plans for interoperability include building bridges to connect BlockDAG with Ethereum, Binance Smart Chain, and other popular blockchains, enabling seamless asset transfers and interaction between ecosystems. * **dApp Porting:** Existing Ethereum dApps can be ported to BlockDAG with little to no modification, opening up a new user base without requiring significant development efforts. **4.4 Testing and Quality Assurance Strategy** Testing is a critical component to ensure the robustness, security, and functionality of BlockDAG. A multi-layered testing approach will be employed: * **Unit Testing:** Each module of the blockchain, including the networking, consensus, and DAG management, will be tested in isolation to verify correctness. * **Integration Testing:** Testing of how the different modules, networking, consensus, and EVM execution interact with each other to ensure seamless integration. * **Performance Testing:** Load testing will simulate large transaction volumes to ensure that BlockDAG can scale and handle high throughput without compromising performance. * **Security Audits:** External auditing services will review the blockchain for vulnerabilities, especially those related to smart contract execution, transaction validation, and DAG structure manipulation. * **Continuous Testing:** CI/CD pipelines will be set up to automate testing, ensuring that new features or patches do not introduce bugs or regressions.
**4.5 Tools and SDKs** To facilitate smooth development and provide a user-friendly experience for developers working on BlockDAG, the following tools and SDKs will be available: * **BlockDAG CLI:** Command-line interface for interacting with BlockDAG, allowing developers and operators to monitor the network, create transactions, deploy smart contracts, and manage nodes. * **BlockDAG SDKs:** * **Web3.js and Ethers.js Integration:** JavaScript libraries to interact with the EVM layer of BlockDAG for smart contract interactions, dApp development, and wallet operations. * **Go/Node.js SDK (Future Plan):** A Go-based SDK for building custom applications and interacting with BlockDAG at a low level. * **API Gateway SDK (Future Plan):** Tools to interact with the blockchain via API gateways, enabling easier integration for third-party services or centralized applications. * **Wallets and Explorers:** * MetaMask, Trust Wallet & Plus Wallet integrations will allow users to manage their tokens and interact with dApps on BlockDAG. * **BlockDAG Explorer:** A custom block explorer will be developed to track transactions, blocks, and smart contracts on the network. # Blockchain Features This section describes the essential features of the BlockDAG blockchain, focusing on its validation process, performance, security, and governance. **5.1 Block Validation Process** BlockDAG employs a unique block validation process leveraging both the Directed Acyclic Graph *(DAG)* structure and a Proof-of-Work *(PoW)* consensus mechanism. * **Parallel Validation:** Unlike traditional blockchains, where transactions are validated sequentially, BlockDAG allows for parallel validation. Blocks can be added concurrently to the DAG structure, resulting in faster transaction processing times. * **Proof-of-Work *****(PoW)*****:** Miners validate blocks by solving cryptographic puzzles, securing the network, and ensuring decentralization. Once a miner completes the PoW, the blocks are added to the DAG structure. * **Block*****(s)***** Confirmation:** In the DAG, transactions are confirmed by referencing previous transactions, ensuring that every new transaction builds upon and validates earlier ones. This enhances the speed of validation and reduces orphan blocks. **5.2 Transaction Fees and Incentives** BlockDAG ensures low transaction costs while incentivizing participation in the network through a balanced fee structure. * **Transaction Fees:** Due to the efficient DAG structure, BlockDAG significantly reduces transaction fees. By enabling parallel block processing, congestion is minimized, keeping fees affordable for users and developers. * **Mining Rewards:** Miners are rewarded based on the reward set in the network by providing computational power to solve PoW puzzles and securing the network. In addition to block rewards, transaction fees are shared as an incentive for continued participation. * **Incentive Distribution:** A fair reward distribution mechanism is designed to ensure that all miners, regardless of size, have the opportunity to be rewarded for their contributions. But the miner with high power gets maximum rewards. **5.3 Scalability and Performance Considerations** BlockDAG is designed to scale efficiently while maintaining high performance, even under heavy network load. * **DAG Structure for Scalability:** The DAG structure allows BlockDAG to handle a larger number of transactions simultaneously, ensuring that the network can scale with increased usage. * **Throughput and Latency:** Parallel processing of transactions enhances throughput, making BlockDAG capable of processing thousands of transactions per second *(TPS)* with low latency. * **Sharding *****(Future Consideration)*****:** BlockDAG’s architecture is adaptable for future scaling solutions such as sharding, which can further increase performance by dividing the network into smaller, more manageable segments. **5.4 Privacy and Security Features** BlockDAG incorporates several privacy and security features to protect user data and ensure the network remains secure from threats. * **PoW Security:** The PoW consensus mechanism ensures that the network remains secure from attacks such as double-spending or 51% attacks, making it resistant to manipulation. * **Transaction Privacy:** While BlockDAG does not natively include privacy features like zero-knowledge proofs *(ZKPs) (future scope)*, the network is designed to integrate privacy-enhancing technologies in the future, such as confidential transactions. * **Data Encryption:** All block data is encrypted and securely stored in the DAG, ensuring the integrity and confidentiality of the network. * **Security Audits:** The blockchain will undergo regular security audits to identify and mitigate potential vulnerabilities, ensuring a robust security posture. # Consensus Algorithm This section discusses the unique DAG-based consensus mechanism of BlockDAG, comparing it to traditional blockchain consensus models, and analyzing its performance and security characteristics. **6.1 Overview of DAG-based Consensus** BlockDAG uses a Directed Acyclic Graph *(DAG)*-based consensus mechanism, which differs fundamentally from the linear chain structure of traditional blockchains. * **DAG Structure:** Instead of relying on a linear chain of blocks, blocks in BlockDAG are represented as vertices in a DAG. Each block points to multiple previous blocks *(or vertices)*, creating a web of interconnected blocks that grows concurrently. * **Decentralized and Asynchronous Validation:** Nodes can add new blocks in parallel, without waiting for block creation from other nodes, resulting in higher throughput and lower latency. Each new block references and validates previous blocks, achieving consensus incrementally as the network grows. * **Efficiency:** The DAG model allows for more efficient use of resources, as multiple blocks can be processed and confirmed simultaneously, increasing scalability and reducing the bottlenecks seen in traditional blockchains. **6.2 Consensus Algorithm Architecture** Detailed architecture diagram for the BlockdAG consensus mechanism, showing how SPECTRE and PHANTOM protocols work together with the proof-of-work system.
The BlockDAG consensus architecture implements a novel dual-protocol approach combining SPECTRE and PHANTOM protocols to achieve both high throughput and robust transaction ordering. This document outlines the technical implementation details and architectural considerations. Let’s explain each component of this consensus architecture in detail: 1. **Block Reception Layer** * Implements asynchronous block ingestion * Performs preliminary validation checks * Maintains real-time DAG topology updates 2. **PoW Verification Engine** * Validates cryptographic solutions against network difficulty * Implements multi-stage verification: * Hash verification * Difficulty threshold compliance * Mining rules enforcement 3. **SPECTRE Protocol Laye**r * **Voting Procedure:** Implements recursive voting between blocks * **Pairwise Block Voting:** Determines relationships between pairs of blocks * **Vote Weights:** Calculates the influence of each block based on the structure * **Partial Order:** Establishes a partial ordering of blocks 4. **PHANTOM Protocol Layer** * **Block Scoring:** Assigns scores based on block properties * **K-cluster Analysis:** Groups blocks based on propagation time * **Blue Set Selection:** Identifies the main chain blocks * **Order Determination:** Creates a linear order from DAG 5. **Consensus Formation** * **Main Chain Selection:** Determines the primary chain * **Chain/Block Weight Calculation:** Computes cumulative chain/block difficulty * **Finality Determination:** Establishes block confirmation status * **State Update:** Updates the blockchain state 6. **Consensus Parameters:** * **k:** propagation time constant * **λ:** block creation rate * **δ:** network delay parameter **Key Features:** 1. **Dual Protocol System:** 1. SPECTRE for fast transaction confirmation 2. PHANTOM for total ordering and main chain selection 2. **Security Mechanisms:** 1. PoW validation 2. Multiple validation layers 3. Parameter-based security controls 3. **State Management:** 1. EVM state synchronization 2. Global state maintenance **Key Interactions:** 1. **Between Protocols:** * SPECTRE provides input to PHANTOM * PHANTOM refines SPECTRE's partial order 2. **With Network:** * Dynamic difficulty adjustment * Block propagation management * Network parameter updates 3. **State Updates:** * Consensus-driven state changes * Atomic updates to EVM states **6.3 Comparison with Blockchain Consensus *****(PoW/PoS)*** While BlockDAG uses a Proof-of-Work *(PoW)* mechanism in its DAG-based framework, it differs significantly from traditional PoW and Proof-of-Stake *(PoS)* blockchains in terms of structure and operation: * **PoW *****(Blockchain)*****:** In traditional PoW blockchains like Bitcoin, miners compete to solve cryptographic puzzles to mine a block. Only one block is added to the chain at a time, leading to potential delays, especially during times of high network activity. * **PoS *****(Blockchain)*****:** PoS, used in networks like Ethereum 2.0, selects validators based on the amount of stake they hold. Validators are responsible for producing new blocks, offering faster block finality than PoW, but still rely on a linear chain. * **DAG-based Consensus *****(BlockDAG)*****:** * **Parallel Processing:** Unlike the sequential block production in PoW/PoS systems, BlockDAG’s DAG structure allows for parallel block processing. This reduces latency and increases throughput. * **No Block Orphaning:** Traditional PoW blockchains can suffer from orphaned blocks when two miners simultaneously mine different blocks. DAG-based consensus eliminates this problem, as new transactions are integrated into the network without the need to discard any valid transactions. * **Higher Scalability:** The DAG structure offers superior scalability compared to both PoW and PoS, especially in high transaction environments, by removing the need to wait for blocks to be mined or finalized. **6.4 Latency and Finality** The performance characteristics of BlockDAG demonstrate significant advantages in production environments. Traditional blockchain architectures typically require multiple confirmation cycles, often resulting in substantial delays. Bitcoin transactions commonly require 30+ minutes for final confirmation status. BlockDAG's architectural approach delivers enhanced performance through: * Parallel block processing * Implicit validation chains * Reduced confirmation dependencies These characteristics enable near-instant finality, particularly beneficial in high-frequency transaction environments such as micropayment systems and real-time financial applications. **6.5 Attack Resistance and Security Considerations** BlockDAG’s consensus mechanism incorporates several security measures to prevent attacks and ensure the integrity of the network: * **51% Attack Mitigation:** The DAG structure necessitates control over an interconnected transaction web rather than single blocks * **Sybil Attack Protection:** PoW implementation maintains robust network participation verification * **Double-Spending Prevention:** Transaction interdependency creates comprehensive verification chains The parallel validation architecture establishes robust security through mandatory multi-transaction referencing. This creates a dense verification network that provides substantial protection against malicious activities while maintaining system performance. **Technical Implementation Considerations:** * **Transaction Validation:** Multiple reference points are required for each new transaction * **Consensus Verification:** Distributed validation across network participants * **Security Scaling:** Protection mechanisms scale with network growth. # Account Abstraction **Version:** ERC-4337 (EntryPoint v0.6) \ **Required Components:** EntryPoint (BlockDAG-provided), Bundler Service (Third-Party), Paymaster Contract (Developer-Deployed) \ **Network:** BlockDAG Mainnet ### Introduction: Redefining the Web3 Account Account Abstraction (AA) represents a major leap forward for user experience and security in decentralized applications. It replaces the traditional model of Externally Owned Accounts (EOAs), which are tied to a single private key and require native currency for gas, with Smart Contract Accounts (SCAs). These SCAs are programmable wallets that can define their own validation and execution logic. BlockDAG implements AA using ERC-4337, a specification that enables this complex transaction flow without altering the underlying BlockDAG consensus layer. The entire process relies on the core EntryPoint contract and two crucial external components: the Bundler service and optional Paymaster contracts. This integration is key to unlocking: * **Enhanced Security:** Custom signature schemes, multi-factor authentication, and social recovery. * **Gas Flexibility:** Gasless transactions through Paymaster sponsorship, or payment using ERC-20 tokens. * **Smarter UX:** Batching multiple actions into a single transaction and account upgradeability. ### Core Components and Their Roles The ERC-4337 ecosystem involves three primary actors working together to process a UserOperation. #### 1. The Canonical EntryPoint Contract (v0.6) The EntryPoint contract is the single, trusted entry point for all UserOperations and is the only component directly deployed and maintained by BlockDAG. * **Version:** We are using the most current, audited v0.6 implementation of EIP-4337. * **Official Address:** 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 * **Role:** The EntryPoint verifies the UserOp's signature and gas fee payment, executes the requested transaction call, and manages deposits for both Smart Accounts and Paymasters. It is the security anchor of the system. #### 2. The Bundler Service (Third-Party Requirement) The Bundler is a specialized, external node that is essential for the ERC-4337 transaction flow. Developers must connect their applications to a reliable, third-party Bundler RPC endpoint. * **Role:** The Bundler monitors the alternative UserOperation mempool, validates incoming UserOps using simulateValidation against the EntryPoint, and ultimately batches valid UserOps into a single standard BlockDAG transaction for submission. * **Functionality:** It manages a reputation system to prevent denial-of-service attacks and ensures a smooth, reliable path for UserOps to reach the network. #### 3. The Paymaster Contract (Developer-Deployed) The Paymaster is an optional smart contract deployed by developers, dApp teams, or gas sponsors who wish to subsidize or facilitate gas payments for users. * **Function:** When the paymasterAndData field is populated in a UserOp, the Paymaster assumes responsibility for gas costs, enabling gasless or ERC-20-based transactions for the end-user. * **Verifying Paymaster Model:** This common model requires the Paymaster to verify the UserOp and potentially sign a hash of it, confirming its willingness to sponsor the transaction before execution. ### BlockDAG Architectural Advantage: DAG Synchronization The BlockDAG architecture, with its parallel execution capabilities, presents a unique environment for the sequential validation required by ERC-4337. * **Atomic Execution Guarantee:** For the EntryPoint's validation logic to be secure and deterministic, it requires transactions to be processed in a reliable order. BlockDAG guarantees atomic execution by utilizing the hybrid Proof-of-Work (PoW) consensus layer to maintain the necessary transaction ordering and finality. This ensures that the state required for UserOperation execution is finalized and verifiable, preventing conflicts that could otherwise occur in a purely parallel system. ### Security and Development Environment #### 1. Audited Security Layers BlockDAG prioritizes the integrity of the AA stack. Our implementation, based on the eth-infinitism reference, has undergone rigorous, independent audits by leading firms such as CertiK and Halborn. The scope of these audits specifically validated the security and adherence to standards of the EntryPoint, Account Factory, and Paymaster contracts. #### 2. Developer Readiness: Using Third-Party SDKs BlockDAG does not provide a proprietary Account Abstraction SDK. Developers must rely on robust, EIP-4337-compatible tools maintained by the broader community to construct, sign, and submit UserOperations to a third-party Bundler RPC endpoint. * **Tooling Requirement:** Developers should use established, community-maintained SDKs (see Section 7) that are compatible with the EntryPoint v0.6 specification. * **Counterfactual Deployment:** Smart account addresses can be predicted before they are deployed (counterfactual creation) using the initCode and the SenderCreator function, simplifying the user onboarding flow. ### User Operation Structure A UserOperation is a structure that is signed by the Smart Account owner and submitted to the Bundler.
FieldDescription
senderThe address of the Smart Contract Account.
nonceReplay protection to prevent a UserOp from being executed more than once.
initCodeFactory address and call data to deploy the account if it does not yet exist.
callDataThe encoded function calls the account it wants to execute.
paymasterAndDataAddress of the paymaster and any additional data needed for sponsorship.
signatureThe authorization proof from the user.
### System Workflow
### References (Third-Party Toolkits) Developers are advised to use the following EIP-4337-compliant resources and toolkits:
Component/ ResourceDescriptionLink
ERC-4337 SpecificationThe canonical standard for account abstraction.https://eips.ethereum.org/EIPS/eip-4337
EntryPoint Contracts (v0.6)The base reference implementation used by BlockDAG.https://github.com/eth-infinitism/account-abstraction
Pimlico AA ToolkitPopular toolkit for building and sending UserOps.https://docs.pimlico.io/
Stackup AA SDKsGeneral-purpose SDKs for Smart Account development.https://docs.stackup.sh/
Eth Infinitism BundlerReference for the Bundler service, mempool, and reputation system.https://github.com/eth-infinitism/bundler
### Conclusion With the deployment of the canonical EntryPoint v0.6, the essential security and execution layer is established for the account abstraction ecosystem on BlockDAG. By integrating with reliable, community-run Bundler services and deploying custom Paymasters, developers can now build highly intuitive and user-friendly wallets and services using established industry toolkits. # Network Details This page provides essential details for connecting to the BlockDAG network. Whether you're a developer, validator, or community member, you can use these configurations to interact with the network, set up wallets, and deploy smart contracts. #### 1. Network Overview The BlockDAG network is a high-performance, scalable blockchain that utilizes a Directed Acyclic Graph (DAG) structure to process transactions efficiently. The network supports smart contracts, decentralized applications (dApps), and token transfers. | **Network Name** | BlockDAG | | ------------------- | ------------------------------------------------------- | | **Chain ID** | 1404 | | **RPC URL** | [​](http://rpc.bdagscan.com/) | | **Explorer URL** | ​[https://bdagscan.com/](https://bdagsscan.com/) | | **Currency Symbol** | BDAG | | | | # Block Explorer A [**Block Explorer**](https://bdagscan.com/) is a web-based application that enables users to navigate through the BlockDAG blockchain. It offers a transparent view into the network's operations, allowing users to search, track, and analyze transactions, addresses, and blocks. #### **Key Features:** * **Real-Time Data Visualization:** Access up-to-date information on the latest blocks and transactions, providing insights into network activity.​ * **Transaction Details:** Examine comprehensive information about individual transactions, including sender and receiver addresses, transaction amounts, gas fees, and confirmation statuses.​ * **Block Information:** Explore detailed data on specific blocks, such as block hashes, timestamps, transaction counts, gas usage, and base fees.​ * **Smart Contract Interaction:** Access and verify deployed smart contracts, enhancing trust and enabling users to interact directly with contract functions.​ * **Node visualiser:** this page gives you a summary of nodes deployed on the blockDAG network. * **NFT:** This module lets you have a look at the top NFTs transferred and minted, along with their detail page. This module supports the transfer of images, videos, and GIFs as NFTs. * **Graphs & Stats:** This module gives you graphs of the network, such as gas fee paid, total transactions, total contracts, total verified contracts, and much more. The [BlockDAG Explorer](https://bdagscan.com/) provides a comprehensive dashboard displaying metrics like total blocks, total transactions, and the current BlockDAG price. Users can delve into the latest blocks and transactions, gaining valuable insights into the network's status. # Smart Contract IDE A **Smart Contract Integrated Development Environment (IDE)** is a comprehensive platform that provides developers with the necessary tools to write, compile, deploy, and debug smart contracts on the BlockDAG network. #### **Key Features:** * **Syntax Highlighting and Autocompletion:** Enhances coding efficiency by providing visual cues and suggestions.​ * **Integrated Compiler:** Allows for real-time code compilation, highlighting errors and warnings to streamline development.​ * **Debugger:** Facilitates step-by-step execution of smart contracts, helping identify and resolve issues.​ * **Deployment Tools:** Enables seamless deployment of contracts to the mainnet directly from the IDE.​ You can access the BlockDAG platform at # IDE Layout **Icon panel:** It allows users to switch between different plugins displayed. By clicking on the panels, users can change the plugin to the one they want to use.
* **Side Dashboard:** Most plugins will have their GUI displayed here. * **Main Panel:** Earlier, the main panel was used to edit the plugins. However, the new version of the IDE provides the feature to accommodate both plugins and files for the IDE to compile. * **Terminal:** Like all the other CLIs, this terminal also provides the feature to view the outcomes of its interactions with the GUI. It also allows the users to run scripts.
# How to create and deploy This tab is accessible in the main panel. By using the toggle button, a user can switch between different templates or open new files from the files section. ### **FILE EXPLORER:**
Click on the workspace option on the left panel to access the file explorer module. In the file explorer, users can manage their workspace and files, and can also access the context menu by right clicking on the folder. This menu provides options for users to perform various actions on their files and folders such as renaming, copying or deleting files. Workspaces basically allows the user to better manage their files by enabling you to separate projects. You can perform the following functions through this. * Add a workspace * Dropdown menu create, delete, rename or download a particular Workspace. * Choose a Workspace. * Expand button * Create a file * Create a folder * Publish the Workspace to a GIST * Load a file into the current Workspace * By clicking on the drop-down menu,you can access the following options
### **SETTINGS:**
* To access the settings option, click on the ***“settings”*** on the bottom of the left panel. * You can choose the option of resetting to the default setting to get back the settings as they were originally. * The word wrap setting allows for wrapping the text or not * Personal mode, mode can be used while connecting to a local node. ### GITHUB ACCESS TOKEN: To carry out git operations on github and create GISTS, it is necessary to provide the access token. It provides specific permissions to execute git commands. Depending upon the operations entered, the user might need to enter the username and email address. **Please note:** the IDE does not store any password information.
### IPFS SETTING:
The above details are necessary to deploy the contract. If the details are not provided, you’ll be using INFURA mode, which does not persist data.
### Steps to Deploy a Smart Contract through BlockDAG IDE: **Step 1:** **Access the BlockDAG IDE**\ Go to **Step 2:** **Create a New File in the Workspace** * From the left-panel menu, navigate to ***“Workspace”*** and click on the ***“Create New File”*** icon. * Name the new file ***“blockdag.sol”*** under the ***“contracts”*** folder. * A new file will be generated, and the main editor panel will open with a blank file. **Step 3:** **Write or Import a Solidity Contract** * Write or import your Solidity contract into the ***“BlockDAG IDE”***.
**Step 4:** **Compile the Smart Contract** * Configure the Solidity compiler settings within the ***“BlockDAG IDE”***. * Select your Solidity contract file (blockdag.sol) and click on ***“Compile”***. * Upon successful compilation, your contract will be ready for deployment. You should see a confirmation of a successful compile on your screen.
**Step 5:** **Compilation** Configure the Solidity compiler settings within the BlockDAG IDE
* Click on ***'Compile'*** for the 'blockdag.sol' file to compile the contract. * Upon successful compilation, your screen will resemble the following:
**Step 6:** **Deployment** Navigate to the ***'Deploy & Run Transactions'*** sidebar in the left panel. To utilize this module, a compiled contract is necessary. If there is a contract name in the 'CONTRACT' select box (located under the 'VALUE' input field), you can proceed with using this module. * **BlockDAG Provider:** For connecting BlockDAG IDE to an injected web3 provider. The most common injected provider is MetaMask * **Hardhat Provider:** For connecting the BlockDAG IDE to a local Hardhat test chain. * **Ganache Provider:** For connecting the BlockDAG IDE to a local Truffle Ganache test chain. * Click 'Deploy' and confirm the transaction on the metamask.
# Contracts Wizard ### **Introduction** This guide provides step-by-step instructions to deploy any smart contract on the BlockDAG blockchain. You’ll learn how to set up your development environment, write and compile the contract, and deploy it using the BlockDAG IDE Pro. **Wizard Link:** ### Prerequisites Before you start, ensure you have: * Basic knowledge of Solidity and smart contracts. * An EVM-compatible wallet such as MetaMask with the BlockDAG network. ### **Steps to add BlockDAG Network in the MetaMask Wallet** 1. **Open Metamask:** Launch the Metamask extension
2. **Access Network Settings** * Click on the Network Selector dropdown at the top of the MetaMask interface (*usually showing "Ethereum Mainnet" by default).* * Select ***"Add Network"*** or ***"Add a Network Manually"***. ![](/files/gDTAn7P5JPtLekjFBLej)
3. **Add a Custom RPC Network:** In the ***"Add a network"*** screen, click ***"Add a network manually"*** to input the custom details.
4. **Fill in Network Details**\ Enter the required blockchain network information: 1. **Network Name:** BlockDAG. 2. **RPC URL:** The endpoint URL for the blockchain for mainnet: "" 3. **Chain ID:** The unique ID for the BlockDAG blockchain (1404). 4. **Currency Symbol:** The native coin symbol (**BDAG**). 5. **Tools:** BlockDAG IDE Pro. ### **Part 1: Connecting to the BlockDAG Network** To add the BlockDAG network to MetaMask, there are 2 options: **Method 1: To add the network with a single click** 1. **Connect MetaMask to BlockDAG Network** * Open the BlockDAG Explorer. * Click on **"Add BlockDAG Network"** to automatically connect your wallet to the BlockDAG blockchain.\
**Method 2: Manually Adding a Network** 1. Alternatively, if you want to add the network manually, ensure your MetaMask is upgraded to version **12.9.2** or higher. Enter the following details in MetaMask: * **Network Name:** BlockDAG * **Default RPC URL:** * **Chain ID:** 1404 * **Currency Symbol:** BDAG
2. **Confirm Connection:** Once the network is added, your MetaMask wallet will connect to the BlockDAG blockchain. Ensure you can see your wallet address and balance. ### **Part 2: Deploying Contracts Using BlockDAG IDE Pro** 1. **Open BlockDAG IDE Pro** * Visit BlockDAG IDE Pro, link: * To open the File Explorer module, click on the **Workspace** option in the left-side menu. The File Explorer helps you manage your workspaces and files easily. * You can also right-click on any file or folder to see a menu with quick options for different actions. ## Ready to compile ### **Overview of the Ready to Compile Interface**
* **Select Contract Navigation Panel** * Located on the left-hand side, this panel provides quick navigation between the following key actions: * **ERC20**: For creating fungible tokens. * **ERC721**: For creating non-fungible tokens *(NFTs)*. * **ERC1155**: For multi-token standards. * **Stablecoin**: For creating pegged assets. * **Real-World Asset**: For tokenizing tangible assets. * **Governor**: For building governance contracts.
* **Settings Panel** * Located on the left side of the workspace, this section allows you to customize your smart contract with various options: * **Name and Symbol**: Specify the token's name and symbol *(e.g., "My Token," "MTK")*. * **Pre-mint**: Define the initial supply of tokens to be minted upon contract creation. * **Features**: * **Mintable**: Enables token minting after deployment. * **Burnable**: Allows token holders to burn (destroy) tokens. * **Pausable**: Adds the ability to pause contract functionality in certain scenarios. * **Permit**: Enables gasless approvals using EIP-2612. * **Flash Minting**: Supports flash loans with immediate repayment. * **Voting Options**: * **Block Number**: Voting based on blockchain block numbers. * **Timestamp**: Voting based on timestamps. * **Access Control**: * **Ownable**: Grants ownership-based access control. * **Roles**: Enables role-based permissions for contract management. * **Managed**: Allows for advanced management of contract functionalities. * **Upgradeability**: Adds support for upgradable contracts. * **Code Editor** * The central area displays the generated Solidity code based on the selected options in the settings panel. * Users can preview, edit, or copy the code for further modifications. * The editor includes comments and import statements for necessary libraries like `ERC20` and `ERC20Permit`. * **Download Button** * Located in the top-right corner, the ***"Download"*** button lets you export the generated Solidity code file for external use. * **Copy Button** * Located in the top-right corner, the ***"Copy"*** button lets you copy the code easily. ### **Step-by-Step Instructions** 1. **Choose a Contract Type** * Select the desired contract type (e.g., ERC20) from the tabs at the top. 2. **Configure Contract Settings** * Enter the **Name** and **Symbol** for your token. * Adjust additional settings like pre-minting, mintability, burnability, and more, depending on your use case. 3. **Customize Access Control** * Enable access control mechanisms such as ownership or roles. * Configure voting mechanisms based on block numbers or timestamps if applicable. 4. **Preview and Edit the Code** * Review the generated Solidity code in the editor. * Make manual changes if necessary to meet advanced or unique requirements. 5. **Download the Code** * Once satisfied with the contract, click the ***"Download"*** button to save the Solidity file for further compilation or deployment. ## Compile The Compile Tab is designed to simplify the compilation process for smart contracts. It ensures compatibility with different Solidity versions and EVM configurations, giving developers flexibility and control.
### **Step-by-Step Instructions** 1. **Select Contract Type** * At the top, you will find options for different contract types such as **ERC20**, **ERC721**, **ERC1155**, **Stablecoin**, **Real-World Asset**, **Governor**, and **Custom**. * Click on the desired contract type to load the associated code template. 2. **Configure Solidity Compiler** * **Compiler Dropdown**: * Choose the Solidity compiler version compatible with your contract requirements (e.g., `0.8.22` or `0.8.19`). * The dropdown allows you to select the compiler version for compatibility with various blockchain networks. * **EVM Version Dropdown**: * Select the EVM version (e.g., **London**, **Istanbul**) to ensure the contract complies with the target blockchain specifications. 3. **View and Edit Code** * The main editor displays the Solidity code for your selected contract template. * You can modify the code directly in the editor to customize parameters such as: * **Token Name** * **Symbol** * **Premint Amount** 4. **Compile the Contract** * **Once you have configured the settings and edited the code:** * Click the **Compile** button to generate the bytecode and ABI (Application Binary Interface). Comment * A progress indicator will show the compilation status. * **Successful Compilation**: * If the contract compiles successfully, the interface will display the output. Comment * Errors or warnings will be highlighted in the editor for easy debugging. ## Deploy The **Deploy Tab** simplifies the deployment process for smart contracts, making it user-friendly and efficient. Here's how to navigate and use this section:
### **Step-by-Step Instructions** **Step 1: Connect MetaMask** \ Establishes a secure connection between your MetaMask wallet and BlockDAG IDE Pro for seamless deployment. Click the ***"Connect With MetaMask*****"** button to link your wallet. Ensure that MetaMask is installed in your browser and you are logged in. **Step 2: Compile Your Contract** Ensure your contract is error-free and compiled successfully in the ***Compile Tab*** before proceeding to deployment. **Step 3: Deploy the Contract** * Once connected to MetaMask, click the *"**Deploy"*** button. Confirm the transaction in MetaMask to initiate deployment. * Wait for the deployment process to complete. A transaction hash will be generated, and the ***Contract Address*** field will populate with the address. ***Note: Ensure that your MetaMask wallet has sufficient funds for gas fees.*** {% hint style="info" %} **Tips for Using the Deploying Contract:** * **Check Gas Fees**: Always ensure your wallet has enough funds to cover gas fees for deployment. Comment * **Network Selection**: Double-check that the selected network in MetaMask matches the intended deployment network. Comment * **Save the Address**: After deployment, save your contract address for future reference or integration. {% endhint %} ## **Deployed** The **"Deployed" screen** confirms that the contract has been **successfully deployed**. Once deployment is complete, the **contract address** will appear in the **left-side contract address field**, where you can easily **copy it for future use**.
**Step 1: Verify & Publish** Click the **Verify & Publish** button after deployment. This action validates your contract’s source code and publishes it within BlockDAG IDE Pro, and users don't need to verify the contract on BlockDAG Explorer, allowing users to interact with and review the contract within BlockDAG IDE Pro. **Step 2: Verified** Once the contract is successfully verified and published, the status will update to **"Verified"**. Users can then copy the contract address and search for it on BDAG Scan to check its status in the Contract List screen.
Additionally, users can verify the contract directly on BDAG Scan by clicking the block icon next to the copy button. This will take them to a page where they can generate a flattened file, copy the contract code, and proceed with verification on the BDAG Scan Contract Verification screen. {% hint style="info" %} You can also watch our tutorial video to learn how to deploy any smart contract using the Contract Wizard. {% endhint %} {% embed url="" %} # EVM RPC For a software application to interact with the Ethereum blockchain - either by reading blockchain data or sending transactions to the network - it must connect to an Ethereum node. For this purpose, every Ethereum client implements a JSON-RPC specification, so there is a uniform set of methods that applications can rely on regardless of the specific node or client implementation. JSON-RPC is a stateless, lightweight remote procedure call ***(RPC)*** protocol. It defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over HTTP, or in many various message-passing environments. It uses JSON ***(RFC 4627)*** as data format. ### Client implementations Ethereum clients may utilize different programming languages when implementing the JSON-RPC specification. See individual client documentation for further details related to specific programming languages. We recommend checking the documentation of each client for the latest API support information. ### Convenience Libraries While you may choose to interact directly with Ethereum clients via the JSON-RPC API, there are often easier options for dApp developers. Many JavaScript and backend API libraries exist to provide wrappers on top of the JSON-RPC API. With these libraries, developers can write intuitive, one-line methods in the programming language of their choice to initialize JSON-RPC requests (under the hood) that interact with Ethereum. ### Consensus client APIs This page deals mainly with the JSON-RPC API used by Ethereum execution clients. However, consensus clients also have an RPC API that allows users to query information about the node, and request Beacon blocks, Beacon state, and other consensus-related information directly from a node. This API is documented on the Beacon API webpage. An internal API is also used for inter-client communication within a node - that is, it enables the consensus client and execution client to swap data. This is called the ***'Engine API'*** and the specs are available on GitHub. ### Execution client spec Read the full JSON-RPC API spec on GitHub. This API is documented on the Execution API webpage and includes an Inspector to try out all the available methods. ### Conventions #### Hex value encoding **Two key data types get passed over JSON:** unformatted byte arrays and quantities. Both are passed with a hex encoding but with different requirements for formatting. **Quantities** When encoding quantities *(integers, numbers)*: encode as hex, prefix with ***"0x"***, the most compact representation *(slight exception: zero should be represented as "0x0")*. Here are some examples: * 0x41 *(65 in decimal)* * 0x400 *(1024 in decimal)* * **WRONG:** 0x *(should always have at least one digit - zero is "0x0")* * **WRONG:** 0x0400 *(no leading zeroes allowed)* * **WRONG:** ff *(must be prefixed 0x)* #### Unformatted data When encoding unformatted data *(byte arrays, account addresses, hashes, bytecode arrays)*: encode as hex, prefix with ***"0x"***, two hex digits per byte. Here are some examples: * 0x41 *(size 1, "A")* * 0x004200 *(size 3, "0B0")* * 0x *(size 0, "")* * **WRONG:** 0xf0f0f *(must be even number of digits)* * **WRONG:** 004200 *(must be prefixed 0x)* #### The default block parameter The following methods have an extra default block parameter: * `eth_getBalance` * `eth_getCode` * `eth_getTransactionCount` * `eth_getStorageAt` * `eth_call` When requests are made that act on the state of Ethereum, the last default block parameter determines the height of the block. The following options are possible for the defaultBlock parameter: * `HEX String` - an integer block number * `String "earliest"` for the earliest/genesis block * `String "latest"` - for the latest proposed block * `String "safe"` - for the latest safe head block * `String "finalized"` - for the latest finalized block * `String "pending"` - for the pending state/transactions ### Examples On this page, we provide examples of how to use individual JSON\_RPC API endpoints using the command line tool, curl. These individual endpoint examples are found below in the Curl examples section. Further down the page, we also provide an end-to-end example for compiling and deploying a smart contract using a Geth node, the JSON\_RPC API, and curl. ### Curl examples Examples of using the JSON\_RPC API by making curl requests to an Ethereum node are provided below. Each example includes a description of the specific endpoint, its parameters, return type, and a worked example of how it should be used. The curl requests might return an error message relating to the content type. This is because the `--data` option sets the content type to `application/x-www-form-urlencoded`. If your node does complain about this, manually set the header by placing `-H "Content-Type: application/json"` it at the start of the call. The examples also do not include the URL/IP & port combination which must be the last argument given to curl (e.g. `127.0.0.1:18545`). A complete curl request including these additional data takes the following form: ``` curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:18545 ``` ### Gossip, State, History A handful of core JSON-RPC methods require data from the Ethereum network and fall neatly into three main categories: *Gossip, State, and History*. Use the links in these sections to jump to each method, or use the table of contents to explore the whole list of methods. #### Gossip Methods > These methods track the head of the chain. This is how transactions make their way around the network, find their way into blocks, and how clients find out about new blocks. * `eth_blockNumber` * `eth_sendRawTransaction` #### State Methods > Methods that report the current state of all the data stored. The "state" is like one big shared piece of RAM, and includes account balances, contract data, and gas estimations. * `eth_getBalance` * `eth_getStorageAt` * `eth_getTransactionCount` * `eth_getCode` * `eth_call` * `eth_estimateGas` #### History Methods > Fetches historical records of every block back to genesis. This is like one large append-only file, and includes all block headers, block bodies, uncle blocks, and transaction receipts. * `eth_getBlockTransactionCountByHash` * `eth_getBlockTransactionCountByNumber` * `eth_getUncleCountByBlockHash` * `eth_getUncleCountByBlockNumber` * `eth_getBlockByHash` * `eth_getBlockByNumber` * `eth_getTransactionByHash` * `eth_getTransactionByBlockHashAndIndex` * `eth_getTransactionByBlockNumberAndIndex` * `eth_getTransactionReceipt` * `eth_getUncleByBlockHashAndIndex` * `eth_getUncleByBlockNumberAndIndex` ### JSON-RPC API Playground You can use the playground tool to discover and try out the API methods. It also shows you which methods and networks are supported by various node providers. ### JSON-RPC API Methods #### web3\_clientVersion Returns the current client version. **Parameters** None **Returns** `String` - The current client version **Example** ``` // // Request curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' // Result { "id":67, "jsonrpc":"2.0", "result": "Geth/v1.12.1-stable/linux-amd64/go1.19.1" } ``` Returns Keccak-256 (*not* the standardized SHA3-256) of the given data. **Parameters** 1. `DATA` - The data to convert into a SHA3 hash ``` // params: ["0x68656c6c6f20776f726c64"] ``` **Returns** `DATA` - The SHA3 result of the given string. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}' // Result { "id":64, "jsonrpc": "2.0", "result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad" } ``` #### net\_version Returns the current network id. **Parameters** None **Returns** `String` - The current network id. The full list of current network IDs is available at [chainlist.org](https://chainlist.org/). Some common ones are: * `1404` : Mainnet Network **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}' // Result { "id":67, "jsonrpc": "2.0", "result": "3" } ``` #### net\_listening Returns `true` if client is actively listening for network connections. **Parameters** None **Returns** `Boolean` - `true` when listening, otherwise `false`. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}' // Result { "id":67, "jsonrpc":"2.0", "result":true } ``` #### net\_peerCount Returns number of peers currently connected to the client. **Parameters** None **Returns** `QUANTITY` - integer of the number of connected peers. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}' // Result { "id":74, "jsonrpc": "2.0", "result": "0x2" // 2 } ``` #### eth\_syncing Returns an object with data about the sync status or `false`. **Parameters** None **Returns** The precise return data varies between client implementations. All clients return `False` when the node is not syncing, and all clients return the following fields. `Object|Boolean`, An object with sync status data or `FALSE`, when not syncing: * `startingBlock`: `QUANTITY` - The block at which the import started (will only be reset after the sync reached his head) * `currentBlock`: `QUANTITY` - The current block, same as eth\_blockNumber * `highestBlock`: `QUANTITY` - The estimated highest block However, the individual clients may also provide additional data. For example, Geth returns the following: ``` // { "jsonrpc": "2.0", "id": 1, "result": { "currentBlock": "0x3cf522", "healedBytecodeBytes": "0x0", "healedBytecodes": "0x0", "healedTrienodes": "0x0", "healingBytecode": "0x0", "healingTrienodes": "0x0", "highestBlock": "0x3e0e41", "startingBlock": "0x3cbed5", "syncedAccountBytes": "0x0", "syncedAccounts": "0x0", "syncedBytecodeBytes": "0x0", "syncedBytecodes": "0x0", "syncedStorage": "0x0", "syncedStorageBytes": "0x0" } } ``` Whereas Besu returns: ``` // { "jsonrpc": "2.0", "id": 51, "result": { "startingBlock": "0x0", "currentBlock": "0x1518", "highestBlock": "0x9567a3", "pulledStates": "0x203ca", "knownStates": "0x200636" } } ``` Refer to the documentation for your specific client for more details. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": { startingBlock: '0x384', currentBlock: '0x386', highestBlock: '0x454' } } // Or when not syncing { "id":1, "jsonrpc": "2.0", "result": false } ``` #### eth\_chainId Returns the chain ID used for signing replay-protected transactions. **Parameters** None **Returns** `chainId`, a hexadecimal value as a string representing the integer of the current chain id. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}' // Result { "id":67, "jsonrpc": "2.0", "result": "0x1" } ``` #### eth\_gasPrice Returns an estimate of the current price per gas in wei. For example, the Besu client examines the last 100 blocks and returns the median gas unit price by default. **Parameters** None **Returns** `QUANTITY` - integer of the current gas price in wei. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}' // Result { "id":73, "jsonrpc": "2.0", "result": "0x1dfd14000" // 8049999872 Wei } ``` #### eth\_accounts Returns a list of addresses owned by the client. **Parameters** None **Returns** `Array of DATA`, 20 Bytes - addresses owned by the client. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": ["0x407d73d8a49eeb85d32cf465507dd71d507100c1"] } ``` #### eth\_blockNumber Returns the number of the most recent block. **Parameters** None **Returns** `QUANTITY` - integer of the current block number the client is on. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}' // Result { "id":83, "jsonrpc": "2.0", "result": "0x4b7" // 1207 } ``` #### eth\_getBalance Returns the balance of the account of given address. **Parameters** 1. `DATA`, 20 Bytes - address to check for balance. 2. `QUANTITY|TAG` - integer block number, or the string `"latest"`, `"earliest"`, `"pending"`, `"safe"`, or `"finalized"`, see the default block parameter ``` // params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"] ``` **Returns** `QUANTITY` - integer of the current balance in wei. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0x0234c8a3397aab58" // 158972490234375000 } ``` #### eth\_getStorageAt Returns the value from a storage position at a given address. **Parameters** 1. `DATA`, 20 Bytes - address of the storage. 2. `QUANTITY` - integer of the position in the storage. 3. `QUANTITY|TAG` - integer block number, or the string `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, see the default block parameter **Returns** `DATA` - the value at this storage position. **Example:** Calculating the correct position depends on the storage to retrieve. Consider the following contract deployed at `0x295a70b2de5e3953354a6a8344e616ed314d7251` by address `0x391694e7e0b0cce554cb130d723a9d27458f9298`. ``` // contract Storage { uint pos0; mapping(address => uint) pos1; function Storage() { pos0 = 1234; pos1[msg.sender] = 5678; } } ``` Retrieving the value of pos0 is straightforward: ``` // curl -X POST --data '{ "jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1 } ' localhost:8545 { "jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2" } ``` Retrieving an element of the map is harder. The position of an element in the map is calculated with: ``` // keccak(LeftPad32(key, 0), LeftPad32(map position, 0)) ``` This means to retrieve the storage on pos1\["0x391694e7e0b0cce554cb130d723a9d27458f9298"] we need to calculate the position with: ``` // keccak( decodeHex( "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" ) ) ``` The geth console, which comes with the web3 library, can be used to make the calculation: ``` // > var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" undefined > web3.sha3(key, {"encoding": "hex"}) "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" ``` Now to fetch the storage: ``` // curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 {"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} ``` #### eth\_getTransactionCount Returns the number of transactions *sent* from an address. **Parameters** 1. `DATA`, 20 Bytes - address. 2. `QUANTITY|TAG` - integer block number, or the string `"latest"`, `"earliest"`, `"pending"`, `"safe"` or `"finalized"`, see the default block parameter ``` params: [ "0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest", // state at the latest block ] ``` **Returns** `QUANTITY` - integer of the number of transactions sent from this address. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0x1" // 1 } ``` #### eth\_getBlockTransactionCountByHash Returns the number of transactions in a block from a block matching the given block hash. **Parameters** 1. `DATA`, 32 Bytes - hash of a block ``` // params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"] ``` **Returns** `QUANTITY` - integer of the number of transactions in this block. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0x8b" // 139 } ``` #### eth\_getBlockTransactionCountByNumber Returns the number of transactions in a block matching the given block number. **Parameters** 1. `QUANTITY|TAG` - integer of a block number, or the string `"earliest"`, `"latest"`, `"pending"`, `"safe"` or `"finalized"`, as in the default block parameter. ``` // params: [ "0x13738ca", // 20396234 ] ``` **Returns** `QUANTITY` - integer of the number of transactions in this block. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["0x13738ca"],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0x8b" // 139 } ``` #### eth\_getUncleCountByBlockHash Returns the number of uncles in a block from a block matching the given block hash. **Parameters** 1. `DATA`, 32 Bytes - hash of a block ``` // params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"] ``` **Returns** `QUANTITY` - integer of the number of uncles in this block. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0x1" // 1 } ``` #### eth\_getUncleCountByBlockNumber Returns the number of uncles in a block from a block matching the given block number. **Parameters** 1. `QUANTITY|TAG` - an integer of a block number, or a string `"latest"`, `"earliest"`, `"pending"`, `"safe"` or `"finalized"`, see the default block parameter ``` // params: [ "0xe8", // 232 ] ``` **Returns** `QUANTITY` - integer of the number of uncles in this block. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0x0" // 0 } ``` #### eth\_getCode Returns code at a given address. **Parameters** 1. `DATA`, 20 Bytes - address 2. `QUANTITY|TAG` - integer block number, or the string `"latest"`, `"earliest"`, `"pending"`, `"safe"` or `"finalized"`, see the default block parameter ``` // params: [ "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0x5daf3b", // 6139707 ] ``` **Returns** `DATA` - the code from the given address. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0x5daf3b"],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0x6060604052600436106100af576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146100b9578063095ea7b31461014757806318160ddd146101a157806323b872dd146101ca5780632e1a7d4d14610243578063313ce5671461026657806370a082311461029557806395d89b41146102e2578063a9059cbb14610370578063d0e30db0146103ca578063dd62ed3e146103d4575b6100b7610440565b005b34156100c457600080fd5b6100cc6104dd565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561010c5780820151818401526020810190506100f1565b50505050905090810190601f1680156101395780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561015257600080fd5b610187600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061057b565b604051808215151515815260200191505060405180910390f35b34156101ac57600080fd5b6101b461066d565b6040518082815260200191505060405180910390f35b34156101d557600080fd5b610229600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061068c565b604051808215151515815260200191505060405180910390f35b341561024e57600080fd5b61026460048080359060200190919050506109d9565b005b341561027157600080fd5b610279610b05565b604051808260ff1660ff16815260200191505060405180910390f35b34156102a057600080fd5b6102cc600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610b18565b6040518082815260200191505060405180910390f35b34156102ed57600080fd5b6102f5610b30565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561033557808201518184015260208101905061031a565b50505050905090810190601f1680156103625780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561037b57600080fd5b6103b0600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091908035906020019091905050610bce565b604051808215151515815260200191505060405180910390f35b6103d2610440565b005b34156103df57600080fd5b61042a600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610be3565b6040518082815260200191505060405180910390f35b34600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055503373ffffffffffffffffffffffffffffffffffffffff167fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c346040518082815260200191505060405180910390a2565b60008054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156105735780601f1061054857610100808354040283529160200191610573565b820191906000526020600020905b81548152906001019060200180831161055657829003601f168201915b505050505081565b600081600460003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b60003073ffffffffffffffffffffffffffffffffffffffff1631905090565b600081600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054101515156106dc57600080fd5b3373ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff16141580156107b457507fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205414155b156108cf5781600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541015151561084457600080fd5b81600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055505b81600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000206000828254039250508190555081600360008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205410151515610a2757600080fd5b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055503373ffffffffffffffffffffffffffffffffffffffff166108fc829081150290604051600060405180830381858888f193505050501515610ab457600080fd5b3373ffffffffffffffffffffffffffffffffffffffff167f7fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65826040518082815260200191505060405180910390a250565b600260009054906101000a900460ff1681565b60036020528060005260406000206000915090505481565b60018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610bc65780601f10610b9b57610100808354040283529160200191610bc6565b820191906000526020600020905b815481529060010190602001808311610ba957829003601f168201915b505050505081565b6000610bdb33848461068c565b905092915050565b60046020528160005260406000206020528060005260406000206000915091505054815600a165627a7a72305820deb4c2ccab3c2fdca32ab3f46728389c2fe2c165d5fafa07661e4e004f6c344a0029" } ``` #### eth\_sign The sign method calculates an Ethereum-specific signature with: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`. Adding a prefix to the message makes the calculated signature recognizable as an Ethereum-specific signature. This prevents misuse where a malicious dapp can sign arbitrary data (e.g. transaction) and use the signature to impersonate the victim. Note: the address to sign with must be unlocked. **Parameters** 1. `DATA`, 20 Bytes - address 2. `DATA`, N Bytes - message to sign **Returns** `DATA`: Signature **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b" } ``` #### eth\_signTransaction Signs a transaction that can be submitted to the network at a later time using eth\_sendRawTransaction. **Parameters** 1. `Object` - The transaction object * `type`: * `from`: `DATA`, 20 Bytes - The address the transaction is sent from. * `to`: `DATA`, 20 Bytes - (optional when creating new contract) The address the transaction is directed to. * `gas`: `QUANTITY` - (optional, default: 90000) Integer of the gas provided for the transaction execution. It will return unused gas. * `gasPrice`: `QUANTITY` - (optional, default: To-Be-Determined) Integer of the gasPrice used for each paid gas, in Wei. * `value`: `QUANTITY` - (optional) Integer of the value sent with this transaction, in Wei. * `data`: `DATA` - The compiled code of a contract OR the hash of the invoked method signature and encoded parameters. * `nonce`: `QUANTITY` - (optional) Integer of a nonce. This allows to overwrite your own pending transactions that use the same nonce. **Returns** `DATA`, The RLP-encoded transaction object signed by the specified account. **Example** ``` // Request curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","params": [{"data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675","from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","gas": "0x76c0","gasPrice": "0x9184e72a000","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","value": "0x9184e72a"}]}' // Result { "id": 1, "jsonrpc": "2.0", "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b" } ``` #### eth\_sendTransaction Creates new message call transaction or a contract creation, if the data field contains code, and signs it using the account specified in `from`. **Parameters** 1. `Object` - The transaction object * `from`: `DATA`, 20 Bytes - The address the transaction is sent from. * `to`: `DATA`, 20 Bytes - (optional when creating new contract) The address the transaction is directed to. * `gas`: `QUANTITY` - (optional, default: 90000) Integer of the gas provided for the transaction execution. It will return unused gas. * `gasPrice`: `QUANTITY` - (optional, default: To-Be-Determined) Integer of the gasPrice used for each paid gas. * `value`: `QUANTITY` - (optional) Integer of the value sent with this transaction. * `input`: `DATA` - The compiled code of a contract OR the hash of the invoked method signature and encoded parameters. * `nonce`: `QUANTITY` - (optional) Integer of a nonce. This allows to overwrite your own pending transactions that use the same nonce. ``` // params: [ { from: "0xb60e8dd61c5d32be8058bb8eb970870f07233155", to: "0xd46e8dd67c5d32be8058bb8eb970870f07244567", gas: "0x76c0", // 30400 gasPrice: "0x9184e72a000", // 10000000000000 value: "0x9184e72a", // 2441406250 input: "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", }, ] ``` **Returns** `DATA`, 32 Bytes - the transaction hash, or the zero hash if the transaction is not yet available. Use eth\_getTransactionReceipt to get the contract address, after the transaction was proposed in a block, when you created a contract. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331" } ``` #### eth\_sendRawTransaction Creates new message call transaction or a contract creation for signed transactions. **Parameters** 1. `DATA`, The signed transaction data. ``` // params: [ "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", ] ``` **Returns** `DATA`, 32 Bytes - the transaction hash, or the zero hash if the transaction is not yet available. Use eth\_getTransactionReceipt to get the contract address, after the transaction was proposed in a block, when you created a contract. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{see above}],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331" } ``` #### eth\_call Executes a new message call immediately without creating a transaction on the blockchain. Often used for executing read-only smart contract functions, for example the `balanceOf` for an ERC-20 contract. **Parameters** 1. `Object` - The transaction call object * `from`: `DATA`, 20 Bytes - (optional) The address the transaction is sent from. * `to`: `DATA`, 20 Bytes - The address the transaction is directed to. * `gas`: `QUANTITY` - (optional) Integer of the gas provided for the transaction execution. eth\_call consumes zero gas, but this parameter may be needed by some executions. * `gasPrice`: `QUANTITY` - (optional) Integer of the gasPrice used for each paid gas * `value`: `QUANTITY` - (optional) Integer of the value sent with this transaction * `input`: `DATA` - (optional) Hash of the method signature and encoded parameters. For details see Ethereum Contract ABI in the Solidity documentation. 2. `QUANTITY|TAG` - integer block number, or the string `"latest"`, `"earliest"`, `"pending"`, `"safe"` or `"finalized"`, see the default block parameter **Returns** `DATA` - the return value of executed contract. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0x" } ``` #### eth\_estimateGas Generates and returns an estimate of how much gas is necessary to allow the transaction to complete. The transaction will not be added to the blockchain. Note that the estimate may be significantly more than the amount of gas actually used by the transaction, for a variety of reasons including EVM mechanics and node performance. **Parameters** See [eth\_call](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_call) parameters, except that all properties are optional. If no gas limit is specified geth uses the block gas limit from the pending block as an upper bound. As a result the returned estimate might not be enough to executed the call/transaction when the amount of gas is higher than the pending block gas limit. **Returns** `QUANTITY` - the amount of gas used. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}' // Result { "id":1, "jsonrpc": "2.0", "result": "0x5208" // 21000 } ``` #### eth\_getBlockByHash Returns information about a block by hash. **Parameters** 1. `DATA`, 32 Bytes - Hash of a block. 2. `Boolean` - If `true` it returns the full transaction objects, if `false` only the hashes of the transactions. ``` // params: [ "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false, ] ``` **Returns** `Object` - A block object, or `null` when no block was found: * `number`: `QUANTITY` - the block number. `null` when its pending block. * `hash`: `DATA`, 32 Bytes - hash of the block. `null` when its pending block. * `parentHash`: `DATA`, 32 Bytes - hash of the parent block. * `nonce`: `DATA`, 8 Bytes - hash of the generated proof-of-work. `null` when its pending block. * `sha3Uncles`: `DATA`, 32 Bytes - SHA3 of the uncles data in the block. * `logsBloom`: `DATA`, 256 Bytes - the bloom filter for the logs of the block. `null` when its pending block. * `transactionsRoot`: `DATA`, 32 Bytes - the root of the transaction trie of the block. * `stateRoot`: `DATA`, 32 Bytes - the root of the final state trie of the block. * `receiptsRoot`: `DATA`, 32 Bytes - the root of the receipts trie of the block. * `miner`: `DATA`, 20 Bytes - the address of the beneficiary to whom the mining rewards were given. * `difficulty`: `QUANTITY` - integer of the difficulty for this block. * `totalDifficulty`: `QUANTITY` - integer of the total difficulty of the chain until this block. * `extraData`: `DATA` - the "extra data" field of this block. * `size`: `QUANTITY` - integer the size of this block in bytes. * `gasLimit`: `QUANTITY` - the maximum gas allowed in this block. * `gasUsed`: `QUANTITY` - the total used gas by all transactions in this block. * `timestamp`: `QUANTITY` - the unix timestamp for when the block was collated. * `transactions`: `Array` - Array of transaction objects, or 32 Bytes transaction hashes depending on the last given parameter. * `uncles`: `Array` - Array of uncle hashes. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}' // Result { { "jsonrpc": "2.0", "id": 1, "result": { "difficulty": "0x4ea3f27bc", "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32", "gasLimit": "0x1388", "gasUsed": "0x0", "hash": "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", "miner": "0xbb7b8287f3f0a933474a79eae42cbca977791171", "mixHash": "0x4fffe9ae21f1c9e15207b1f472d5bbdd68c9595d461666602f2be20daf5e7843", "nonce": "0x689056015818adbe", "number": "0x1b4", "parentHash": "0xe99e022112df268087ea7eafaf4790497fd21dbeeb6bd7a1721df161a6657a54", "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", "size": "0x220", "stateRoot": "0xddc8b0234c2e0cad087c8b389aa7ef01f7d79b2570bccb77ce48648aa61c904d", "timestamp": "0x55ba467c", "totalDifficulty": "0x78ed983323d", "transactions": [ ], "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": [ ] } } ``` #### eth\_getBlockByNumber Returns information about a block by block number. **Parameters** 1. `QUANTITY|TAG` - integer of a block number, or the string `"earliest"`, `"latest"`, `"pending"`, `"safe"` or `"finalized"`, as in the default block parameter. 2. `Boolean` - If `true` it returns the full transaction objects, if `false` only the hashes of the transactions. ``` // params: [ "0x1b4", // 436 true, ] ``` **Returns** See eth\_getBlockByHash **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}' ``` Result see eth\_getBlockByHash #### eth\_getTransactionByHash Returns the information about a transaction requested by transaction hash. **Parameters** 1. `DATA`, 32 Bytes - hash of a transaction ``` // params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"] ``` **Returns** `Object` - A transaction object, or `null` when no transaction was found: * `blockHash`: `DATA`, 32 Bytes - hash of the block where this transaction was in. `null` when its pending. * `blockNumber`: `QUANTITY` - block number where this transaction was in. `null` when its pending. * `from`: `DATA`, 20 Bytes - address of the sender. * `gas`: `QUANTITY` - gas provided by the sender. * `gasPrice`: `QUANTITY` - gas price provided by the sender in Wei. * `hash`: `DATA`, 32 Bytes - hash of the transaction. * `input`: `DATA` - the data send along with the transaction. * `nonce`: `QUANTITY` - the number of transactions made by the sender prior to this one. * `to`: `DATA`, 20 Bytes - address of the receiver. `null` when its a contract creation transaction. * `transactionIndex`: `QUANTITY` - integer of the transactions index position in the block. `null` when its pending. * `value`: `QUANTITY` - value transferred in Wei. * `v`: `QUANTITY` - ECDSA recovery id * `r`: `QUANTITY` - ECDSA signature r * `s`: `QUANTITY` - ECDSA signature s **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}' // Result { "jsonrpc":"2.0", "id":1, "result":{ "blockHash":"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "blockNumber":"0x5daf3b", // 6139707 "from":"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d", "gas":"0xc350", // 50000 "gasPrice":"0x4a817c800", // 20000000000 "hash":"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b", "input":"0x68656c6c6f21", "nonce":"0x15", // 21 "to":"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb", "transactionIndex":"0x41", // 65 "value":"0xf3dbb76162000", // 4290000000000000 "v":"0x25", // 37 "r":"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea", "s":"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c" } } ``` #### eth\_getTransactionByBlockHashAndIndex Returns information about a transaction by block hash and transaction index position. **Parameters** 1. `DATA`, 32 Bytes - hash of a block. 2. `QUANTITY` - integer of the transaction index position. ``` // params: [ "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0", // 0 ] ``` **Returns** See eth\_getTransactionByHash **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' ``` Result see eth\_getTransactionByHash #### eth\_getTransactionByBlockNumberAndIndex Returns information about a transaction by block number and transaction index position. **Parameters** 1. `QUANTITY|TAG` - a block number, or the string `"earliest"`, `"latest"`, `"pending"`, `"safe"` or `"finalized"`, as in the default block parameter. 2. `QUANTITY` - the transaction index position. ``` // params: [ "0x9c47cf", // 10241999 "0x24", // 36 ] ``` **Returns** See eth\_getTransactionByHash **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}' ``` Result see eth\_getTransactionByHash #### eth\_getTransactionReceipt Returns the receipt of a transaction by transaction hash. **Note** That the receipt is not available for pending transactions. **Parameters** 1. `DATA`, 32 Bytes - hash of a transaction ``` // params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"] ``` **Returns** `Object` - A transaction receipt object, or `null` when no receipt was found: * `transactionHash` : `DATA`, 32 Bytes - hash of the transaction. * `transactionIndex`: `QUANTITY` - integer of the transactions index position in the block. * `blockHash`: `DATA`, 32 Bytes - hash of the block where this transaction was in. * `blockNumber`: `QUANTITY` - block number where this transaction was in. * `from`: `DATA`, 20 Bytes - address of the sender. * `to`: `DATA`, 20 Bytes - address of the receiver. null when its a contract creation transaction. * `cumulativeGasUsed` : `QUANTITY` - The total amount of gas used when this transaction was executed in the block. * `effectiveGasPrice` : `QUANTITY` - The sum of the base fee and tip paid per unit of gas. * `gasUsed` : `QUANTITY` - The amount of gas used by this specific transaction alone. * `contractAddress` : `DATA`, 20 Bytes - The contract address created, if the transaction was a contract creation, otherwise `null`. * `logs`: `Array` - Array of log objects, which this transaction generated. * `logsBloom`: `DATA`, 256 Bytes - Bloom filter for light clients to quickly retrieve related logs. * `type`: `QUANTITY` - integer of the transaction type, `0x0` for legacy transactions, `0x1` for access list types, `0x2` for dynamic fees. It also returns *either* : * `root` : `DATA` 32 bytes of post-transaction stateroot (pre Byzantium) * `status`: `QUANTITY` either `1` (success) or `0` (failure) **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}' // Result { "jsonrpc": "2.0", "id": 1, "result": { "blockHash": "0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3", "blockNumber": "0xeff35f", "contractAddress": null, // string of the address if it was created "cumulativeGasUsed": "0xa12515", "effectiveGasPrice": "0x5a9c688d4", "from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7", "gasUsed": "0xb4c8", "logs": [{ // logs as returned by getFilterLogs, etc. }], "logsBloom": "0x00...0", // 256 byte bloom filter "status": "0x1", "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2", "transactionHash": "0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5", "transactionIndex": "0x66", "type": "0x2" } } ``` #### eth\_getUncleByBlockHashAndIndex Returns information about a uncle of a block by hash and uncle index position. **Parameters** 1. `DATA`, 32 Bytes - The hash of a block. 2. `QUANTITY` - The uncle's index position. ``` // params: [ "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0", // 0 ] ``` **Returns** See eth\_getBlockByHash **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' ``` Result see eth\_getBlockByHash **Note**: An uncle doesn't contain individual transactions. #### eth\_getUncleByBlockNumberAndIndex Returns information about a uncle of a block by number and uncle index position. **Parameters** 1. `QUANTITY|TAG` - a block number, or the string `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, as in the default block parameter. 2. `QUANTITY` - the uncle's index position. ``` // params: [ "0x29c", // 668 "0x0", // 0 ] ``` **Returns** See eth\_getBlockByHash **Note**: An uncle doesn't contain individual transactions. **Example** ``` // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}' ``` Result see eth\_getBlockByHash ### Usage Example #### Deploying a contract using JSON\_RPC This section includes a demonstration of how to deploy a contract using only the RPC interface. There are alternative routes to deploying contracts where this complexity is abstracted away—for example, using libraries built on top of the RPC interface such as web3.js and web3.py. These abstractions are generally easier to understand and less error-prone, but it is still helpful to understand what is happening under the hood. The following is a straightforward smart contract called `Multiply7` that will be deployed using the JSON-RPC interface to an Ethereum node. This tutorial assumes the reader is already running a Geth node. More information on nodes and clients is available [here](https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/). Please refer to individual [client](https://ethereum.org/en/developers/docs/nodes-and-clients/) documentation to see how to start the HTTP JSON-RPC for non-Geth clients. Most clients default to serving on `localhost:8545`. ``` // contract Multiply7 { event Print(uint); function multiply(uint input) returns (uint) { Print(input * 7); return input * 7; } } ``` The first thing to do is make sure the HTTP RPC interface is enabled. This means we supply Geth with the `--http` flag on startup. In this example we use the Geth node on a private development chain. Using this approach we don't need ether on the real network. ``` // geth --http --dev console 2>>geth.log ``` This will start the HTTP RPC interface on `http://localhost:8545`. We can verify that the interface is running by retrieving the coinbase address (by obtaining the first address from the array of accounts) and balance using curl. Please note that data in these examples will differ on your local node. If you want to try these commands, replace the request params in the second curl request with the result returned from the first. ``` // curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[]", "id":1}' -H "Content-Type: application/json" localhost:8545 {"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]} curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545 {"id":2,"jsonrpc":"2.0","result":"0x1639e49bba16280000"} ``` Because numbers are hex encoded, the balance is returned in wei as a hex string. If we want to have the balance in ether as a number we can use web3 from the Geth console. ``` // web3.fromWei("0x1639e49bba16280000", "ether") // "410" ``` Now that there is some ether on our private development chain, we can deploy the contract. The first step is to compile the Multiply7 contract to byte code that can be sent to the EVM. To install solc, the Solidity compiler, follow the Solidity documentation. (You might want to use an older `solc` release to match the version of compiler used for our example). The next step is to compile the Multiply7 contract to byte code that can be send to the EVM. ``` // echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin ======= :Multiply7 ======= Binary: 6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029 ``` Now that we have the compiled code we need to determine how much gas it costs to deploy it. The RPC interface has an `eth_estimateGas` method that will give us an estimate. ``` // curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545 {"jsonrpc":"2.0","id":5,"result":"0x1c31e"} ``` And finally deploy the contract. ``` // curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "gas": "0x1c31e", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 6}' -H "Content-Type: application/json" localhost:8545 {"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"} ``` The transaction is accepted by the node and a transaction hash is returned. This hash can be used to track the transaction. The next step is to determine the address where our contract is deployed. Each executed transaction will create a receipt. This receipt contains various information about the transaction such as in which block the transaction was included and how much gas was used by the EVM. If a transaction creates a contract it will also contain the contract address. We can retrieve the receipt with the `eth_getTransactionReceipt` RPC method. ``` // curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545 {"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}} ``` Our contract was created on `0x4d03d617d700cf81935d7f797f4e2ae719648262`. A null result instead of a receipt means the transaction has not been included in a block yet. Wait for a moment and check if your consensus client is running and retry it. **Interacting with smart contracts** In this example we will be sending a transaction using `eth_sendTransaction` to the `multiply` method of the contract. `eth_sendTransaction` requires several arguments, specifically `from`, `to` and `data`. `From` is the public address of our account, and `to` is the contract address. The `data` argument contains a payload that defines which method must be called and with which arguments. This is where the ABI (application binary interface) comes into play. The ABI is a JSON file that defines how to define and encode data for the EVM. The bytes of the payload defines which method in the contract is called. This is the first 4 bytes from the Keccak hash over the function name and its argument types, hex encoded. The multiply function accepts an uint which is an alias for uint256. This leaves us with: ``` // web3.sha3("multiply(uint256)").substring(0, 10) // "0xc6888fa1" ``` The next step is to encode the arguments. There is only one uint256, say, the value 6. The ABI has a section which specifies how to encode uint256 types. `int: enc(X)` is the big-endian two’s complement encoding of X, padded on the higher-order (left) side with 0xff for negative X and with zero > bytes for positive X such that the length is a multiple of 32 bytes. This encodes to `0000000000000000000000000000000000000000000000000000000000000006`. Combining the function selector and the encoded argument our data will be `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`. This can now be sent to the node: ``` // curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0xeb85a5557e5bdc18ee1934a89d8bb402398ee26a", "to": "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", "data": "0xc6888fa10000000000000000000000000000000000000000000000000000000000000006"}], "id": 8}' -H "Content-Type: application/json" localhost:8545 {"id":8,"jsonrpc":"2.0","result":"0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74"} ``` Since a transaction was sent, a transaction hash was returned. Retrieving the receipt gives: ``` // { blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55", blockNumber: 268, contractAddress: null, cumulativeGasUsed: 22631, gasUsed: 22631, logs: [{ address: "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55", blockNumber: 268, data: "0x000000000000000000000000000000000000000000000000000000000000002a", logIndex: 0, topics: ["0x24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"], transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74", transactionIndex: 0 }], transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74", transactionIndex: 0 } ``` The receipt contains a log. This log was generated by the EVM on transaction execution and included in the receipt. The `multiply` function shows that the `Print` event was raised with the input times 7. Since the argument for the `Print` event was a uint256 we can decode it according to the ABI rules which will leave us with the expected decimal 42. Apart from the data it is worth noting that topics can be used to determine which event created the log: ``` // web3.sha3("Print(uint256)") // "24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da" ``` This was just a brief introduction into some of the most common tasks, demonstrating direct usage of the JSON-RPC. # WebSocket This section provides detailed information on using WebSocket RPC connections for interacting with the BlockDAG blockchain, a Layer 1 proof-of-work network leveraging a Directed Acyclic Graph (DAG) structure for high-speed, secure, and decentralized transactions. WebSocket RPC enables real-time, bi-directional communication, making it ideal for decentralized applications (dApps) requiring live updates, such as transaction confirmations or block additions. ### Introduction WebSocket RPC facilitates seamless interaction with the blockchain by establishing a persistent, full connection over TCP. Unlike traditional HTTP-based RPC, which requires repeated polling, WebSocket RPC allows clients to receive real-time updates, reducing latency and improving efficiency. This is particularly valuable for applications like the BlockDAG Explorer, where users need immediate visibility into network activity. ### Key Features The WebSocket RPC implementation in BlockDAG offers several advantages: * **Real-time Communication**: Enables bi-directional, full-duplex communication over a single TCP connection, allowing instantaneous data exchange between clients and the blockchain. * **Enhanced User Experience**: Supports live updates for dApps, such as real-time block notifications and transaction confirmations, eliminating the need for manual page refreshes. * **Scalability and Performance**: Optimized for high throughput and low latency, capable of handling large data volumes and numerous simultaneous users, making it suitable for high-traffic applications. * **Security**: Utilizes Secure WebSocket (wss\://) for encrypted communication, with authentication mechanisms like token-based access to protect RPC methods. ### Technical Details The WebSocket RPC implementation adheres to industry standards and incorporates optimizations for performance and compatibility: * **Protocol**: Follows the RFC 6455 WebSocket standard, supporting both unencrypted (ws\://) and encrypted (wss\://) connections. Secure connections are recommended for production environments. * **Language Compatibility**: Compatible with various programming languages through libraries and SDKs, including Python (websocket-client), JavaScript (ws), Go (gorilla/websocket), and C++ (libwebsockets). * **Optimization**: * **Message Batching**: Groups multiple messages to reduce overhead and improve throughput. * **Compression**: Uses permessage-deflate to minimize bandwidth usage. * **Memory Management**: Optimized to handle high loads efficiently, ensuring stability under heavy traffic. * **Backward Compatibility**: Designed to work seamlessly with existing RPC interfaces, allowing developers to transition from HTTP-based RPC without significant code changes. ### Supported RPC Methods BlockDAG’s WebSocket RPC supports a range of methods for interacting with the blockchain, as outlined in Dev Release 22. These methods enable developers to query data, execute transactions, and interact with smart contracts. The following table summarizes the key methods: | **Method** | **Description** | **Function Signature** | | ----------------------- | ------------------------------------------------------------------- | -------------------------------------------------------------- | | getBalance | Retrieves the balance for a given account or address. | getBalance(address) | | sendTransaction | Initiates and broadcasts a transaction from one account to another. | sendTransaction(sender, recipient, amount, gasLimit, gasPrice) | | getBlock | Retrieves details about a specific block on the blockchain. | getBlock(blockNumber) | | getTransaction | Fetches detailed information about a transaction using its hash. | getTransaction(transactionHash) | | callSmartContractMethod | Executes specific functions on smart contracts. | callSmartContractMethod(contractAddress, methodName, args) | ### Benefits in BlockDAG Explorer The integration of WebSocket RPC significantly enhances the functionality of the BlockDAG Explorer, a web-based tool for navigating the blockchain. Key benefits include: * **Real-time Block Updates**: New blocks are displayed immediately as they are added, providing users with up-to-date network information. * **Live Transaction Feed**: Transactions appear as they are confirmed, enabling real-time monitoring of network activity. * **Enhanced User Experience**: The explorer offers a dynamic, responsive interface, improving usability for both casual users and developers. * **Scalability**: The WebSocket implementation supports high data volumes, ensuring the explorer remains performant even with increased network activity. These features make the BlockDAG Explorer a powerful tool for tracking transactions, analyzing blocks, and interacting with smart contracts in real time. ### Best Practices for Developers To effectively use BlockDAG’s WebSocket RPC, developers should follow these guidelines: * **Use Secure Connections**: Always use wss\:// endpoints to ensure data privacy and security. * **Handle Reconnections**: Implement logic to automatically reconnect in case of connection drops, using exponential backoff to avoid overwhelming the server. * **Optimize Payloads**: Leverage message batching and compression to minimize bandwidth usage, especially for high-frequency requests. * **Monitor Rate Limits**: Check for any rate limits or throttling policies in the official documentation to avoid being blocked. ### Conclusion BlockDAG’s WebSocket RPC implementation represents a significant advancement in blockchain interactivity, offering real-time communication, scalability, and security for dApps and tools like the BlockDAG Explorer. By supporting key RPC methods and planning future enhancements, BlockDAG is well-positioned to meet the needs of developers building on its high-speed, decentralized network. For the latest endpoint details and API documentation, refer to the BlockDAG Developer Hub. # EVM The **BlockDAG EVM Network** is a powerful ecosystem that provides in-depth insights into network activity, ensuring transparency and efficiency for users. The **Blocks** section displays newly validated blocks, showing key details like block height, timestamps, parent references, and gas usage, allowing users to track the chain’s growth. The **Transactions** page enables real-time tracking of all network activities, including fund transfers and contract executions, providing a clear view of transaction statuses, fees, and confirmations. The **Contracts** section highlights deployed smart contracts, offering users the ability to review execution history and interact with contract functions. The **Tokens** page lists all tokens on the network, including ERC-20 and ERC-721 standards, giving insights into token details, balances, and transfer histories. The **Node Visualizer** provides a graphical representation of network nodes, showing their connections, activity status, and role in transaction validation, enhancing the understanding of BlockDAG’s decentralized structure. With these features, the BlockDAG EVM Network empowers developers, investors, and users to navigate and interact with the ecosystem effortlessly. # Home The BlockDAG Explorer is a comprehensive blockchain tracking tool that provides users with real-time insights into the BlockDAG network's transactions, blocks, contracts, tokens, and nodes. It is designed to help users search, monitor, and interact with the network efficiently, offering a structured dashboard with key blockchain metrics and functionalities. **Explorer Link:**
**Search Bar** Located at the top of the page, this allows users to search for ***“Addresses”***, ***“Transaction Hashes”***, or ***“Block Numbers”*** within the EVM-based BlockDAG blockchain. Users simply input the relevant data and click the ***"Search"*** button or press enter to retrieve detailed information. \ **Nav Bar (Drop-down):** Allows users to switch between EVM and UTXO network. **Dashboard Summary** This section provides a quick overview of essential blockchain statistics: * **BlockDAG Price**\ Displays the current price of BDAG in USDT. * **Total Blocks**\ This shows the total number of blocks that have been created on the BlockDAG network *(for eg: 3,282,823 blocks)*. * **Last Safe Block**\ Displays the number of the latest block that has been confirmed as ***"safe"*** or finalized *(eg: Block #7284)*. * **Total Transactions**\ The total value of transactions processed on the network is currently at ***‘91522’***. * **BlockDAG Transaction History Graph**\ A visual graph that shows transaction activity over time, allowing users to monitor network activity trends.
**Latest Blocks** Displays the most recent blocks created on the network. Each block entry provides the following details: * **Block Number:** Represents the height of the block in the chain, showing the sequence of block creation. *(e.g., #35791)*. * **Hash:** A unique identifier for the block, generated based on the block's contents. * **Age:** The timestamp of when the block was added to the network. *(e.g., "9 sec. ago")*. * **Txn Count:** The number of transactions included in the block, showing how many transactions were confirmed in this block. * **Gas Used:** The total amount of computational effort spent executing transactions within the block. * **Gas Limit:** The maximum amount of gas that can be used in the block, set by the network to regulate transaction throughput. * **Base Fee :** The minimum fee per gas unit that must be paid for a transaction to be included in the block. **Latest Transactions** The Latest Transactions section on the home screen displays recent transactions executed on the BlockDAG network. * **Transaction Hash:** A unique identifier for the transaction, generated using cryptographic hashing. * **Block No.:** The block where this transaction was confirmed, indicating its placement in the BlockDAG structure. * **Events:** Shows the type of action taken in the transaction, such as: * **Transfer**: Standard token transfer. * **Mint**: Token generation (typically ERC-20 or ERC-721/ERC-1155 NFT minting). * **Age:** Time elapsed since the transaction was processed. * **From:** The sender’s wallet address * **To:** The recipient’s wallet address or contract address if interacting with a smart contract. * **Value:** The amount of BDAG (BlockDAG’s native coin) transferred. * **Transaction Fee:** The gas fee paid in BDAG for processing the transaction. **Navigation Sidebar** The menu on the left provides easy access to various sections of the BlockDAG Explorer: * **Home:** The dashboard, showing network stats. * **Blocks:** displays the list of mined blocks and details like block height, timestamp, and miner. * **Transactions:** displays the list of recent transactions, including sender, receiver, gas fees, and status. * **Contract Listing:** Possibly a repository of deployed smart contracts. * **Verification:** Allows the user to verify deployed smart contracts by ensuring the source code matches the deployed bytecode. * **Token:** Might display ERC-20 and ERC-721 (NFT) tokens * **Node Visualizer:** A unique feature for visualizing network nodes and connections.
**Add BDAG Network Button:** This button allows users to easily integrate the BlockDAG network into their wallet or blockchain tools for direct interaction with BDAG tokens. **Price Display:** A small widget in the sidebar shows the current price of BDAG, along with a percentage change indicator. **Pagination:** At the bottom of the transactions section, users can navigate through multiple pages of data using pagination controls, allowing them to view blocks on the blockchain. Also, note that we only show the latest 100,000 blocks and transactions. **Footer:** The footer includes a disclaimer about the risks of cryptocurrency investments, reminding users of the speculative and volatile nature of the market. Users can also access social media links *(Telegram, Twitter, Facebook, etc.)* and other company information at the bottom.
# Block List The block list is a key feature that shows a detailed and record of all the blocks added to the blockchain. It allows users to track transactions in each block, see block details *(like number, timestamp, and miner)*. This helps ensure transparency and allows for real-time monitoring and analysis of blockchain activity.
**Summary Section:** This section provides an at-a-glance view of key metrics for the blockchain: * **Last Safe Block:** Displays the most recent block deemed ***"safe"*** for transactions *(in this case, \`84\`)*. **Block List** Below the summary, you can see a detailed list of blocks *(blocks “90 to 99” are shown here)*. Each block provides various key metrics: * **Block Number:** Represents the height of the block in the chain, showing the sequence of block creation. *(e.g., #35791)*. * **Hash:** A unique identifier for the block, generated based on the block's contents. * **Age:** The timestamp of when the block was added to the network. *(e.g., "9 sec. ago")*. * **Txn Count:** The number of transactions included in the block, showing how many transactions were confirmed in this block. * **Gas Used:** The total amount of computational effort spent executing transactions within the block. * **Gas Limit:** The maximum amount of gas that can be used in the block, set by the network to regulate transaction throughput. * **Base Fee:** The minimum fee per gas unit that must be paid for a transaction to be included in the block. **Block Navigation:** A pagination bar is visible at the bottom of the block list, total number of blocks, and users can navigate through these blocks by page *(\`1/89\`)*.
# Block Detail The block details screen includes the block number, timestamp, miner's address, list of transactions, gas used , gas limit, block hash and parent hash.
**Block Number:** The block number is ***458329***, which indicates its position in the blockchain. Blocks are created sequentially, and this number helps track the order of transactions and network activity. **Current Depth:** The depth of this block is **11,** meaning it is the most recent block. In blockchain, depth represents how many blocks have been built on top of this one. A depth of zero means no newer blocks have been added after it yet. **Base Fee:** The base fee for this block is ***0.00000000007531912 BDAG***. The base fee is a mandatory transaction fee set by the network, dynamically adjusting based on network congestion. This fee is burned, preventing excessive inflation of the token supply. **Block Hash:** The block hash is a unique identifier for this block `0xf8b03ffc25fff0e4f139b2e3ae758fd2dd998fa4664aeb094456785642422649`. It is generated through cryptographic hashing and ensures the integrity of the block’s data. **Age:** This block was created ***23 hours ago**,* at ***2025-03-10 15:30:45***. The timestamp helps in tracking network activity and is useful for analyzing block production time. **Size:** The block size is ***5476 byte*****s**, which represents the total amount of data stored in this block, including transactions, metadata, and other required information. **Gas Used:** This block consumed ***941,489 gas***, which is ***3.14%*** of the total available gas limit. Gas is a measure of the computational work needed to process transactions and smart contracts in this block. **Gas Limit:** The gas limit for this block is ***30,000,000***. This is the maximum amount of gas that can be used by all transactions within this block. It ensures the network remains efficient and prevents any single block from consuming excessive computational resources. **Parent Hash:** The parent hash is\ `0x2ad10bc9b565312166545337746c140b43a6458018bfff9d3d06a94cd3dd5cce`.\ It links this block to its predecessor, maintaining the chain’s continuity. This ensures that blocks are cryptographically connected, making it impossible to alter past transactions without invalidating the entire chain. **Receipts Root:** The receipts root is `0x1e5ac1a1f49bdcbf6f483268bbcc17107cb65b44a69206c6ecd2ca893103f1b0`.\ This is a Merkle root hash that summarizes all transaction receipts within this block. Transaction receipts contain execution results, gas usage, logs, and other important transaction metadata. # Transaction List The transaction list screen allows users to track the movement of BDAG coins, verify transaction statuses, view details like sender, recipient, and amounts, monitor network activity, and analyse transaction patterns. This provides transparency and real-time information for efficient transaction tracking.
**Transaction Summary** * **Total Transactions:** Shows the total number of transactions being displayed *(e.g., "Total of 57 Transactions")*. This helps users understand how many transactions have occurred. * **Total Contract Transaction:** This metric specifically tracks the number of transactions involving smart contract interactions. Contract transactions include deploying smart contracts, executing function calls within contracts, minting NFTs, swapping tokens, and any other interaction requiring contract execution. * **Average Transaction Fee:** The average transaction fee represents the median gas cost paid by users to process transactions on the network. It is determined based on network congestion, gas price variations, and transaction complexity.
**Transaction Table** The main body of the page lists all the transactions, each with specific details: * **Transaction Hash:** A unique identifier for the transaction, generated using cryptographic hashing. * **Block No:** The block where this transaction was confirmed, indicating its placement in the BlockDAG structure. * **FR 4.002c:** **Events**\ Shows the type of action taken in the transaction, such as: * **Transfer**: Standard token transfer. * **Mint**: Token generation *(typically ERC-20 or ERC-721/ERC-1155 NFT minting)*. * **Age:** Time elapsed since the transaction was processed. * **From:** The sender’s wallet address * **To:** The recipient’s wallet address or contract address if interacting with a smart contract. * **Amount:** The amount of BDAG *(BlockDAG’s native coin*) transferred. * **Transaction Fee:** The gas fee paid in BDAG for processing the transaction. **Pagination Controls:** Located at the bottom of the transaction list, this feature allows users to navigate through different pages of transactions. In this case, the system shows there are ***“89 pages”*** with a total of ***“57 transactions”*** displayed. Users can jump between pages by clicking the arrows or typing the page number.
# Transaction Detail The transaction detail screen provides in-depth information about a specific transaction. Users can verify transaction details *(hash, status, block number, timestamp)*, track sender and recipient addresses, check the transaction value, review gas information *(price, limit, used)*, view input data, confirm block inclusion, explore contract interactions, analyze logs and events, and check the nonce.
**Transaction Hash *****(Txn Hash)*** * Displays the unique identifier of the transaction *(e.g., \`0xcd7141bde1dd977648e2c1ddd9d69974805b89b494ec...\`)*. * A ***“Copy”*** icon allows users to easily copy the transaction hash to their clipboard, enabling quick sharing or further analysis. **Transaction Details** The Transaction Details page provides a deep dive into a specific transaction on the BlockDAG blockchain, displaying critical information such as the transaction hash, sender and recipient addresses, gas fees, execution status, and input data. * **Block No. :** Block #7283 indicates the block in which the transaction was confirmed. Confirmed transactions are finalized once they are recorded in a block. * **Status:** This section indicates whether the transaction was successful, pending, or failed. * **Success:** Transaction executed and recorded successfully. * **Pending:** Waiting to be confirmed in a block. * **Failed:** Error occurred due to insufficient gas, invalid contract call, or other reasons. * **Time:** In the time section, **"4 days ago *****(March 7, 2025, at 12:42:29 UTC)*****"** is the exact date and time when this transaction was confirmed on the blockchain. * **From *****(Send Address)*****:** This ***"0x321b06B6073760945539E04f23218201d4435Cde"*** is the wallet or contract address that initiated the transaction. * **To *****(Recipient Address)*****:** In the to section this is the ***"0x321b06B6073760945539E04f23218201d4435Cde"*** recipient wallet or smart contract that **received the transaction**. * **Value:** Represents the amount of ***BDAG coins*** transferred. * **Transaction Fee:** It's the total ***fee paid*** to process the transaction on BDAG. * **Gas Price:** The Gas price ***"0.000000000000064551 BDAG"*** represents the amount of BDAG paid per unit of gas. If the network is congested, users might have to increase the gas price to speed up transactions. * **Gas Used:** The total gas consumed by the transaction execution ***"98,364 Gas Units"***. Each transaction requires a minimum amount of gas, depending on whether it's a simple BDAG transfer or a smart contract interaction. * **Input Data:** The input data field contains encoded contract execution details. # Address Details The transactions screen tracks BDAG coin movements, provides detailed transaction information like addresses and values, shows transaction statuses (pending, confirmed), allows searching and filtering by criteria such as transaction hash or sender, presents a transaction history for analysis, offers fee insights (gas fees), and updates in real-time with the latest blockchain transactions.
The ***“Wallet Address”*** section displays the selected To or From address of the transaction made from that selected wallet address. The ***“Copy”*** option allows the user to copy it as a clipboard. The ***“Balance”*** section displays the balance in the overview section of the transactions screen on Etherscan shows the total amount of BDAG currently held in the specified wallet address. The ***“BlockDAG Value”*** section displays the BDGA value in the overview section displays the total value of all transactions *(in BDAG)* associated with the specified wallet address. This includes the sum of incoming and outgoing transactions. The ***"Last Transaction Sent"*** is the transactions screen that displays the details about the most recent outgoing transaction from the specified wallet address. The ***"First Transaction Sent"*** is the transactions screen that displays the details about the last outgoing transaction from the specified wallet address. The ***“Transaction Hash”*** is the unique identifier for each transaction on the blockchain. The ***“Block Number”*** section displays the block number in which the transaction was included. The ***“Age”*** section displays the block’s age of the time elapsed since the transaction was mined. The ***“From”*** section displays the sender's BDAG address. The ***“To”*** section displays the recipient's BDAG address or the contract address if interacting with a smart contract. The ***“Value”*** section displays the amount of BDAG transferred in the transaction. The ***“Transaction Fees”*** section displays the fees paid for executing the transaction, including gas fees. The ***“View All Transactions”*** option provides a detailed view of all the details transactions. # Contract Listing The contract listing refers to the cataloging of all smart contracts deployed on the BlockDAG blockchain. Each listed contract provides essential information, such as the contract address, creator details, and transaction history.
**Contracts Table:** This table provides a comprehensive list of all contracts in the BlockDAG network, displaying key information and enabling easy access to each contract’s details. * **Contracts:** This section displays the name or symbol of each contract to help the user easily identify the contract. * **Contract Address:** This column displays a unique address of each contract on the network. The user can copy the address using the clipboard icon next to each entry, simplifying the process of sharing or interacting with the contract. * **Type:** This column displays the contract type ***(e.g., "ERC1155")***, indicating the token standard or other compatibility aspects to help identify its functionality within the network. * **Owner:** This column displays the complete list of all the addresses ***(the contract's owner)***, offering transparency regarding the entity managing the contract. * **Age:** This column displays the time elapsed since the contract was deployed or last updated, providing context on the recency and activity level of each contract. * **Status:** This column indicates the verification status of the deployed contract on our BlockDAG chain, showing whether it is ***"Fully Verified", "Partially Verified",*** or ***"Not Verified".*** * **Details Button *****(Arrow Icon):*** Clicking on this icon reveals a detailed view of the contract. This may include additional information, like past transactions and associated metadata, giving users deeper insights into each contract's behavior.
# Contract Details In the BlockDAG Explorer, the Contract Details Transfer Tab provides users with a dedicated view of all transfer activities associated with a particular smart contract. This tab is especially useful for tracking coin movements, transaction histories, and understanding the contract's usage.
**Overview Section**\ This section provides a summary of the selected contract, displaying key information: * **Owner:** This column displays the address of the contract’s owner. The user can click the clipboard icon to copy the address for easy reference. * **Contract Name:** This column displays the name or symbol associated with the contract which is BDAG. * **Token Name:** The Token Name is also ***"MyToken"***, which is the publicly displayed name of the token. This name is what users will see when they trade or transfer the token in wallets or exchanges. * **Type:** This column displays the type of contract, shown as ***"ERC1155"***, which is a standard for NFTs on Ethereum-compatible blockchains. * **Contract Address:** This column displays the unique address for the contract. The user can copy the contract address with the clipboard icon. * **Holders:** This column displays the number of distinct wallet addresses that hold this contract’s tokens. * **Total Transfers:** This column displays the total number of token transfers associated with this contract, useful for tracking contract activity and engagement. * **Price:** The Token Price is ***82,392 USDT***, showing its current value in Tether (USDT) * **Total Supply:** The ***"Total Supply"*** of this token is ***99,999,999,999.99998167666666666*****.** **Market Section:** This section displays the current market price of the contract's token or asset. The price is shown as $0.22 of the BDAG token in US dollars. The market data section helps the users to understand the current valuation of assets tied to the contract. #### **Contract Listing Tabs** The following tabs provide different types of information about the token: * **Transfers Tab:** Displays a list of all transactions involving this token, including sends, receives, and contract interactions. Users can track who sent and received tokens, how much was transferred, and when it happened. * **Holders Tab:** Displays a list of all wallet addresses that own this token, along with their balances. This tab helps users see who the major holders are, which can be useful for tracking whale wallets or checking if the token is well-distributed or concentrated in a few addresses. * **Events Tab:** Displays smart contract events, such as minting new tokens, burning tokens, ownership changes, or approvals for spending tokens. Events help users understand important activities happening behind the scenes. * **Info Tab**: The Info tab provides key information about the token, including its description, trading volume, market capitalization, circulating supply, and on-chain valuation * **Contract Tab:** Provides the smart contract’s source code and allows users to interact with its functions. This is useful for developers or advanced users who want to execute contract functions manually. # Transfer Tab **Transfers Table**\ This table provides details on recent transfers and transactions related to the selected contract. The columns include:
* **TXN Hash:** This column displays the unique identifier for each transaction. The user can click the clipboard icon to copy the transaction hash for future reference or external use. * **Method:** This column displays the method used in the transaction, which in this case is ***"Trans\_Batch"***, indicating a batch transfer. * **Block:** This column displays the block number in which the transaction occurred. This helps in pinpointing the transaction within the blockchain. * **Age:** This column displays the time elapsed since the transaction was executed, useful for tracking the recency of activity. * **From:** This column displays the address from which the tokens were sent. The user can copy the address using the clipboard icon. * **To:** This column displays the address to which the tokens were sent. The user can also copy this address using the clipboard icon. * **Quantity:** This column displays the number of tokens involved in the transfer. In this case, the quantity is ***"0"***, which may indicate a token transfer with no actual value moved or a placeholder for additional data. # Holders Tab **Holders**\ The Holders tab provides information about all wallets that currently own this token, including their addresses, token quantity, value, and ownership percentage.
* **Total Token Holders**\ At the top, we can see that this token has a total of 3 holders. This means that only three different wallet addresses currently own this token. * **Holder Details**\ Each row in the table represents a different wallet that currently holds or has interacted with this token. The key details shown in the table are: * **Address:** The wallet address of the token holder. * **Price:** The current market price of the token in USDT. This helps determine the token’s value in the broader market. * **Quantity:** The number of tokens held by this wallet. * **Value:** The total worth of the tokens held by the wallet, calculated as ***Price × Quantity***. This gives an idea of the wallet’s total token holdings in USDT. * **Percentage:** The wallet’s share of the total token supply, represented as a percentage. # Events Tab **Events**\ The Events tab records on-chain activities related to a token, such as transfers, approvals, and ownership changes. It helps users track what actions took place in the token's smart contract.
* **Total Event Logs**\ At the top, the page shows a total of 3 event logs for this token. Each event log represents a specific action recorded on the blockchain, triggered by a smart contract function. * **Transaction Details**\ Each event is linked to a specific transaction. In this case: * **Transaction Hash:** **0xea2...3ecd8**\ This is a unique identifier for the transaction that triggered the event. Clicking on the hash would show full details of the transaction. * **Block Number:** **7247**\ This tells us when the transaction was confirmed on the blockchain. * **Age:** **6 days ago**\ This indicates that the event happened ***six days ago***, providing a timestamp for when the smart contract executed this action. * **Method:** **Transfer** This shows that the event was triggered by a ***transfer function*** inside the smart contract. This means tokens were sent from one wallet to another. # Info Tab **Info** \ The Info tab provides key information about the token, including its description, trading volume, market capitalization, circulating supply, and on-chain valuation. This section is useful for investors, traders, and analysts who want to understand the token’s market performance and overall supply dynamics.
* **Overview Section**\ The **overview section** gives a brief description of the token. * **Volume (24H):** **$40,548,072,636**\ This represents the total value of this token traded in the last 24 hours across various exchanges and platforms. * **Market Capitalization:** **$1,632,035,673,526**\ Market capitalization *(**market cap**)* is calculated as ***Token Price × Circulating Supply*****.** This represents the total value of all tokens currently in circulation based on their market price. * **Circulating Supply: $19,834,746 USDT** \ This represents the total number of tokens currently available in the market for trading, holding, and use. * **On-Chain Market Capitalization: $134,303,479,645,801,600.** \ This represents the total valuation of all tokens recorded on the blockchain. # Contract Tab **Contract** \ The Contract Tab provides detailed technical information about a smart contract, enabling users to analyze its functionality, verify its integrity, and explore its components. This tab is divided into the following sections:
* **Compiler Details** This section displays information about the contract’s compilation and verification process: * **Verification Status:** Indicates whether the contract is partially or fully verified. * **Contract Name:** The identifier for the contract *(e.g., Blockdag)*. * **Compiler Version:** Specifies the Solidity compiler version used for the contract *(e.g., v0.8.20)*. * **Optimization Enabled:** States whether optimization was applied during compilation *(e.g., False)*. * **Optimization Runs:** The number of optimization runs performed *(e.g., 200)*. * **Verified At:** The date and time when the contract was verified *(e.g., 23rd Jul 2024, 15:29:17)*. # Code Tab **Compiler Messages**\ Displays warnings, errors, or recommendations generated during the compilation process: * Examples include missing SPDX license identifier warnings, unused declarations, or best practice suggestions. * Helps developers understand potential issues or areas for improvement in the code. **Contract Source Code**\ Shows the Solidity source code of the contract: * Developers can review the code to understand its logic, methods, and structure. * Includes key elements such as imports, state variables, functions, and event definitions. * Helps users verify the contract’s functionality and compliance with coding standards. **Contract ABI**\ The ABI *(Application Binary Interface)* defines how external applications or users can interact with the contract: * Lists available functions, their names, and input/output parameters. * Includes definitions for events triggered by the contract. * Provides the necessary interface for wallets, dApps, and other integrations. **Contract Creation Code**\ Displays the bytecode used to deploy the contract: * Useful for developers, auditors, and miners who want to verify the contract’s deployment data. * Ensures that the contract was deployed as intended without tampering or errors.
# Read Tab The Read Contract Tab enables users to access and query the contract's read-only functions to fetch data directly from the blockchain. These functions are used to retrieve information without making any changes to the blockchain, meaning no tokens or gas fees are required.
**Wallet Connection** Allows users to securely connect their wallet to the interface. Although read-only functions don’t require gas or tokens, wallet integration ensures secure and authenticated interactions with the contract. **Contract Information** * **Public Functions:** Displays a list of all publicly accessible read functions within the contract. These functions provide data such as balances, token details, or contract status. * **Expandable Functions:** Each function is listed with its name *(e.g., \_verifyTransfer)*. Users can expand any function to view input fields or directly execute a query to retrieve outputs. * **Inputs and Outputs:** Some functions may require input parameters *(e.g., wallet addresses)* to fetch specific data. The output provides the requested information in real time. # Write Tab The Write Contract Tab allows users to perform state-changing actions on a smart contract, such as transferring tokens, updating settings, or triggering specific operations. These interactions modify the blockchain's state and require wallet authorization.
**Wallet Connection** Users must connect their wallet to execute write functions. This ensures secure interactions, allows authentication and facilitates the payment of gas fees required for the transaction. **Contract Information** * **Callable Functions:** The tab lists all available write functions within the smart contract *(e.g., batchTransferETH)*. These methods enable users to make changes to the blockchain's data. * **Expandable Functions:** Clicking on a function name expands it to reveal input fields and options for user interaction. * **Input Fields:** Each function displays the required inputs *(e.g., wallet addresses, token amounts)* that users must provide to execute the operation. **Executing Transactions** * **Execute Button:** Once all input fields are completed, users can click the Execute button to initiate the transaction. This will prompt the connected wallet for confirmation. * **Gas Fees:** Executing write functions incurs gas fees. The estimated fee is displayed in the wallet confirmation screen, ensuring users are aware of the cost before approving the transaction. # Contract Owner In the BlockDAG Explorer, the Contract Owner section provides information about the address that holds administrative control over a particular smart contract. This address, typically controlled by the developer or organisation that deployed the contract, has special permissions, which may include the ability to modify contract settings, manage funds, or execute specific functions. Understanding the role of the contract owner is crucial for users who want to assess the level of control and potential centralization of a given contract.
**Contract Details** * **Address:** This section displays the address of the selected contract. The copy icon next to the address enables users to copy it to the clipboard for easier sharing or referencing. * **Balance:** This section displays the contract’s balance, here shown as ***"987.74 BDAG"***,where BDAG appears to be the native coin for this network. * **First Txn Sent:** This section displays the hash of the first transaction sent from this contract, with a copy icon for convenience. * **Last Txn Sent:** This section displays the hash of the most recent transaction sent, with a copy icon to easily copy it. * **BlockDAG Value:** This section displays the fiat value of the contract’s balance, here shown as $0.02. It might update in real-time with the cryptocurrency’s exchange rate. \ **Transaction Table**\ This table displays a list of recent transactions related to the contract or account. * **Txn Hash:** This column displays the unique identifier for each transaction. Each hash has a copy icon for the convenience of the user. * **Block:** This column displays the block number in which the transaction was included. * **Age:** This column displays how long ago the transaction was confirmed. * **From:** This column displays the address of the sender in each transaction. * **To:** This column displays the recipient address for each transaction. * **Value:** This column displays the amount of BDAG transferred in each transaction. * **Txn Fee:** This column displays the transaction fee for each transaction. # Contract Verification The Verify and Publish Contract screen allows users to verify their smart contracts by matching the source code with the deployed contract on the blockchain. This process ensures transparency, compliance, and trust in the contract’s operations. ### Steps 1- Enter Contract Details * **Enter Contract Address:** Provide the address of the deployed smart contract *(e.g., 0xF0245F...D80B60)* in the input field. The system uses this address to fetch and validate the contract details on the blockchain. * **Select Compiler Details** * **Compiler Type:** Select the compiler type used during the smart contract's development *(e.g., Solidity)*. * **Compiler Version:** Choose the specific version of the compiler *(e.g., v0.8.20)* to ensure compatibility. * **Open Source License Type:** Specify the license under which the source code is published. This helps maintain compliance with licensing requirements. * **Agree to Terms of Service**\ Check the box to confirm agreement with the platform’s terms of service for using the verification feature. * **Action Buttons** * **Reset:** Clears all entered details and selections, allowing you to start over when the user comes back to this 1st step. * **Continue:** Proceeds to the next step in the verification process, enabling code submission and verification.
### Steps 2- Verify and Publish This step allows users to verify a smart contract by uploading its source code and metadata, ensuring it matches the deployed bytecode on the blockchain. It is a crucial process for maintaining transparency and trust in blockchain applications. Highlights the importance of verifying source code to build trust and ensure transparency. Provides advanced settings guidance, such as bytecode hash matching and optimization runs.
**Input Fields** * **Upload Contract Source Code:** * Users can upload the contract's source code file in supported formats like Solidity or Vyper. * Ensures the uploaded code matches the on-chain bytecode for verification. * **Enter Contract ABI (Optional):** * Allows users to paste the contract’s Application Binary Interface (ABI). * Useful for accessing and interacting with the contract's functions. * **Contract Library Address:** * If the contract relies on external libraries, users can specify up to 10 library addresses. * Ensures proper linkage and accurate verification of dependent components. * **Misc Settings (Runs, EVM Version):** * **Optimization Runs:** Specify the number of optimization runs used during compilation. * **EVM Version:** Indicate the Ethereum Virtual Machine version used, such as Istanbul or Berlin. * **Action Buttons:** * **Previous:** Returns to the previous step in the Verify and Publish Contract workflow. * **Done:** Completes the process, submitting the contract for verification and publication. **How It Works** * **Upload and Match:**\ The system compares the uploaded source code with the deployed bytecode on the blockchain. If matched, the contract is marked as verified. * **Verification Benefits:**\ Verified contracts increase user confidence by proving that the deployed bytecode aligns with the provided source code. Developers can showcase their contract's functionality and transparency. * **Advanced Customization:**\ Enables developers to specify advanced configurations, ensuring accurate and comprehensive verification. # Contract Transaction Details The Contract Transaction Details section provides detailed information about transactions involving smart contracts on the network. This feature helps users track interactions with specific contracts, offering insight into how the contract is being used, who is interacting with it, and the outcomes of these transactions.
**Transaction Hash:** This section displays the unique transaction hash of the specific transaction being viewed. The hash is displayed prominently for easy reference and includes a copy icon for convenient copying of the transaction hash. \ **Transaction Details Section:** This section provides detailed information about the transaction. Each row includes specific transaction-related data: * **Block Number:** This section indicates the block in which this transaction was included, here it’s shown as ***"719"***. * **Status:** This section displays the status of the transaction, with a green ***"Success"*** label indicating that this transaction was successfully processed. * **Time:** This section displays the timestamp of the transaction, showing how long ago it occurred and the exact date and time: ***"6 days ago (2024-10-30 12:16:52)"***. * **From:** This section displays the sender’s address. The address is shown with a copy icon for easy copying. * **To:** This section displays the recipient’s address with a copy icon to copy the address. * **Value:** This section indicates the amount of BDAG ***(the native coin)*** transferred in the transaction. Here, it shows ***"0 BDAG ($0)"*** , indicating that no coins were transferred in this transaction. * **Transaction Fee:** This section displays the fee associated with processing the transaction. In this case, it is shown as ***"0.0000045461 BDAG"***. * **Gas Price:** This section displays the gas price, which is the amount of BDAG paid per unit of gas for this transaction. Here, it is displayed as ***"0.0000000001 BDAG"***.
# Tokens List The Top Token screen displays a list of top tokens in a BlockDAG-based blockchain network. The table provides important details such as token name, price, market cap, volume, and number of holders. This information helps users track and analyze the performance of different tokens in the network.
**Total Tokens** At the top, the dashboard mentions a total of 79 tokens being tracked. However, the table only displays a few tokens per page. The user can navigate through eight pages using the pagination controls at the bottom. #### **Token Name** Each row in the table represents a different token such as ***"MyToken"*** , ***"MyTo"***, and ***"LastTest"***. #### **Price** The price column shows the current value of the token in USDT *(Tether)*. Next to the price, the change *(%)* column indicates how much the token's value has increased or decreased. #### **Trading Volume (24H)** The volume (24H) column represents the total amount of the token traded in the past 24 hours. The value shown is ***"40,063,995,888 USDT"***, meaning there has been significant trading activity. #### **Circulating Market Cap** The circulating market cap is the total value of all tokens currently available in the market. In this case, it is ***"19,834,746 USDT"*** for each token. This metric helps investors understand the token’s overall size and market impact. #### **On-Chain Market Cap** The on-chain market cap is another important metric that represents the total valuation of the token based on its full supply on the blockchain. Here, the value is ***"1,630,931,824,596 USDT"***, which is much higher than the circulating market cap. **Holders** The holders column indicates how many wallet addresses currently own that token. #### **Token Details Button** On the right side of each row, there is a button with a right arrow. Clicking this button likely opens more detailed information about that specific token. # Token Detail This screen displays token details for a token named MyToken on a BlockDAG-based blockchain network. It provides an overview of the token, market information, contract details, and recent transfers. Users can track token ownership, total supply, transactions, and smart contract interactions from this page.
#### **Token Overview** The **overview section** contains key details about the token, helping users understand who created it, what type it is, and how it operates on the blockchain. * **Owner Address**\ The Owner Address is ***"0xFCc221E65A34c1a478B21C6aFdbID0413b6EAeC"***, the address that belongs to the creator or deployer of the smart contract. * **Contract Name**\ The Contract Name is ***"MyToken"***, which is the registered name of the token’s smart contract in the blockchain. This name is mainly used for identification when interacting with the contract. * **Token Name**\ The Token Name is also ***"MyToken"***, which is the publicly displayed name of the token. This name is what users will see when they trade or transfer the token in wallets or exchanges. * **Type**\ The Type of this token is ***"ERC-20"***, which means it follows the ERC-20 token standard. * **Contract Address**\ The Contract Address is ***"0x1C4C583E14D1DB813bbC5Ebe5c4a46C4f0ad530e"***, this address is where all token logic is stored, including minting, burning, transfers, and other token-related functions. If users want to interact with the contract, they would use this address in blockchain explorers, wallets, or dApps. #### **Market Information** The market section provides insights into the token’s activity, price, and overall supply. * **Holders**\ The Holders count is ***3***, meaning only three different wallet addresses currently own this token. * **Total Transfers**\ The Total Transfers are ***3***, which means the token has only been moved between addresses three times. * **Price**\ The ***"Token Price"*** is ***82,392 USDT***, showing its current value in Tether (USDT). * **Total Supply**\ The ***"Total Supply"*** of this token is ***99,999,999,999.99998167666666666*****.** #### **Token Tabs** The following tabs provide different types of information about the token: * **Transfers Tab**\ Displays a list of all transactions involving this token, including sends, receives, and contract interactions. Users can track who sent and received tokens, how much was transferred, and when it happened. * **Holders Tab**\ Displays a list of all wallet addresses that own this token, along with their balances. This tab helps users see who the major holders are, which can be useful for tracking whale wallets or checking if the token is well-distributed or concentrated in a few addresses. * **Events Tab**\ Displays smart contract events, such as minting new tokens, burning tokens, ownership changes, or approvals for spending tokens. Events help users understand important activities happening behind the scenes. * **Info Tab** \ The Info tab provides key information about the token, including its description, trading volume, market capitalization, circulating supply, and on-chain valuation * **Contract Tab**\ Provides the smart contract’s source code and allows users to interact with its functions. This is useful for developers or advanced users who want to execute contract functions manually. # Transfer Tab The table below the tabs displays a list of recent token transactions, including transfers between wallets and changes in ownership. Each transaction provides specific details that help users track token movements, transaction history, and blockchain activity.
**Transaction** This is a transfer transaction, meaning tokens were sent from one wallet to another. * **Transaction Hash *****(0xea2...3ecd8)***\ This is a unique ID for the transaction. Every transaction on the blockchain has a hash, which can be used to track, verify, and check transaction details. * **Event Type *****(Transfer)*** \ This shows that the sender has moved BDAG tokens from their wallet to another address. * **Block Number *****(7247)*** \ This number indicates where in the blockchain the transaction was recorded. * **Age *****(6 days ago)***\ This tells us when the transaction was added to the blockchain. * **From Address *****(0xFCc...EAeC4)***\ This is the wallet address that sent the transaction. * **To Address *****(0xf6D...8e1CF)***\ This is the wallet that has received the tokens. * **Quantity *****(0)***\ The amount of tokens transferred in this transaction. # Transfer Detail Tab (Overview) The tab provides important information about the transaction, including the transaction hash, status, sender, receiver, gas fees, and input data. This information helps users track whether a transaction was successful, how much it cost, and what it did on the blockchain. * **Transaction Hash**\ A transaction hash ***0xea2000a6b7f12b76501e7f6c101bf0c97f710589ab09ac1bf812e40cdf33ecd8*** is like a receipt number that allows anyone to track and verify this transaction on the blockchain. The ***"Copy"***** button**, allows you to copy the transaction hash for reference. * **Block Number**\ The transaction was recorded in ***Block Number 7247***. A block number tells us when a transaction was confirmed on the blockchain. Higher block numbers mean newer transactions. If users want to check other transactions in the same block, they can search for this block number in the blockchain explorer. * **Transaction Status**\ The Status of this transaction is ***Success***, meaning it was successfully processed and recorded on the blockchain. A transaction can have different statuses: * **Success:** The transaction was successfully confirmed, and the tokens were transferred *(if applicable)*. * **Pending:** The transaction is still waiting to be confirmed by the network. * **Failed:** The transaction did not go through, possibly due to ***insufficient gas fees, contract errors, or lack of funds***. * **Timestamp *****(Time of Transaction)***\ The transaction was confirmed ***6 days ago***, on ***March 4, 2025*****,** at ***09:35:57 (UTC time)***. This timestamp helps users understand when the transaction took place. * **Sender *****(From Address)***\ The From Address is ***0xFCc221E65A34c1a478B21C6aFdbID0413b6EAeC4*****.** This is the wallet or smart contract that initiated the transaction. It could belong to a user, exchange, or smart contract. Since this same address appeared in previous transactions, it may be the token creator or contract owner. * **Receiver *****(To Address)***\ The **"*****To Address"*** field displays the recipient of this transaction. * **Value of the Transaction**\ The **"*****Value"*** field shows ***0 BDAG (0 USDT)*****.** This means that no tokens were directly transferred in this transaction. * **Transaction Fee**\ The ***"Transaction Fee"*** is ***0.00000000347 BDAG*****.** This is the amount of BDAG tokens paid as a fee to process this transaction. * **Gas Price and Gas Used**\ ***"Gas Price"*** 0.000000000000064551 BDAG. Gas Price refers to how much the sender was willing to pay per unit of gas. * **Gas Used:** **53,865**\ These values explain how much computational power was used to process the transaction. Gas Used refers to the total amount of gas required to execute this transaction. * **Input Data *****(Function Call Details)***\ The Input Data section shows technical details about the transaction. * **Function:** **Transfer**\ This means the transaction was intended to transfer tokens. However, since the Value field shows 0 BDAG, no tokens were actually moved. * **Parameter \[0]:** **0x00000000f6dE38af2B76130cAeAFe8540dbC5546**\ This is likely the receiving address or a smart contract interacting with this transaction. * **Parameter \[1]:** A long number that could represent token amounts, unique IDs, or encoded transaction details. # Transfer Detail (Logs) The logs provide event data related to the transaction, helping users understand what happened inside the smart contract when the transaction was processed. * **Transaction Hash**\ The ***"Transaction Hash"*** is displayed as *"**0xea2000a6b7f12b76501e7f6c101bf0c97f710589ab09ac1bf812e40cdf33ecd8"*****.** This unique identifier allows users to track and verify the transaction. If needed, users can copy the hash using the ***"Copy"*** button to check it in other blockchain tools. * **Logs Overview**\ The Logs section records what happened during the execution of the transaction. * **Raw Data**\ The Raw section shows the hexadecimal data related to the event. This data is mostly used by developers for debugging and verifying smart contract execution. ***0x000000000f6dE38af2B76130cAeAFe8549dbC5546b428e1cf0000000000000000000000000000000000000000000000000000000000000184*****.** This represents encoded transaction details, including the sender, receiver, amount, and other parameters. * **Method Name**\ The ***"Method Name"*** for this transaction is Transfer. This confirms that tokens were successfully moved from one wallet to another. * **Topics *****(Indexed Data)***\ In blockchain logs, topics help categorize events. They are indexed so that blockchain explorers can quickly search for specific actions, like token transfers or approvals. * **Topic 0:**\ ***0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef***, this is a predefined signature for a Transfer event in ERC-20 tokens. It means the event follows the standard token transfer format. * **Topic 1:**\ ***0x0000000000000000000000000fcc221e65a34c1a478b21c6afdb1d0413b6eaec4***, this represents the wallet address of the sender (the person who sent the tokens). * **Topic 2:**\ ***0x0000000000000000000000000f6dE38af2B76130cAeAFe8549dbC5546b428e1cf***, this represents the wallet address of the recipient (the person who received the tokens). * **Decoded Transfer Details**\ Below the topics, the transaction details are further decoded into human-readable format: * **From *****(Sender Address)*****:**\ ***0xFCc221E65A34c1a478B21C6aFdbID0413b6EAeC4***, this is the wallet address that sent the tokens. * **To *****(Receiver Address)*****:**\ ***0xF6dE38af2B76130cAeAFe8549dbC5546b428e1cf***, this is the wallet that received the tokens. * **Value *****(Amount Transferred)*****:**\ ***1666666666666***, this represents the number of tokens transferred. # Holders Tab The Holders tab provides information about all wallets that currently own this token, including their addresses, token quantity, value, and ownership percentage.
* **Total Token Holders**\ At the top, we can see that this token has a total of 3 holders. This means that only three different wallet addresses currently own this token. * **Holder Details**\ Each row in the table represents a different wallet that currently holds or has interacted with this token. The key details shown in the table are: * **Address:** The wallet address of the token holder. * **Price:** The current market price of the token in USDT. This helps determine the token’s value in the broader market. * **Quantity:** The number of tokens held by this wallet. * **Value:** The total worth of the tokens held by the wallet, calculated as ***Price × Quantity***. This gives an idea of the wallet’s total token holdings in USDT. * **Percentage:** The wallet’s share of the total token supply, represented as a percentage. # Holders Detail The page provides an overview of the wallet, its balance, transaction history, and key metrics related to its activity. * **Wallet Address Information**\ At the top, the wallet address is displayed as ***0xab0810f9187a15bcc4e7bf552a5b781846fdf6af*** of that specific token**.** * **Balance 19.93 BDAG**\ This wallet currently holds ***19.93 BDAG*** tokens. * **BlockDAG Value:** **0.0248 USDT ($0)**\ This is the wallet’s estimated total value based on its holdings and market price. * **Last Transaction Sent:** **0xfa8...3a6f0**\ This is the most recent transaction initiated by this wallet. * **First Transaction Sent:** **0xfa8...3a6f0**\ The first every recorded transaction initiated by this wallet. * **Transaction Details**\ The transactions table below provides a summary of the wallet's activity. Each row represents a transaction linked to this wallet. * **Transaction Hash:** **0xfa8...3a6f0**\ This is the unique ID for the transaction involving this wallet. Clicking on the hash would show the full transaction breakdown. * **Block Number:** **7246**\ The transaction was recorded in **block 7246**, meaning it was confirmed on the blockchain at that point in time. * **Age:** **6 days ago**\ This shows when the transaction took place. * **From Address:** **0xFC...AeC4**\ This is the sender's wallet address. * **To Address:** **0xaB...f6af**\ This is the recipient's wallet address. * **Value:** 1**0 BDAG**\ The transaction moved **10 BDAG** coins. * **Transaction Fee:** **0.0628 BDAG**\ This is the fee which the user has paid to make this specific transaction. # Events Tab The Events tab records on-chain activities related to a token, such as transfers, approvals, and ownership changes. It helps users track what actions took place in the token's smart contract.
* **Total Event Logs**\ At the top, the page shows a total of 3 event logs for this token. Each event log represents a specific action recorded on the blockchain, triggered by a smart contract function. * **Transaction Details**\ Each event is linked to a specific transaction. In this case: * **Transaction Hash:** **0xea2...3ecd8**\ This is a unique identifier for the transaction that triggered the event. Clicking on the hash would show full details of the transaction. * **Block Number:** **7247**\ This tells us when the transaction was confirmed on the blockchain. * **Age:** **6 days ago**\ This indicates that the event happened **six days ago**, providing a timestamp for when the smart contract executed this action. * **Method:** **Transfer** This shows that the event was triggered by a **transfer function** inside the smart contract. This means tokens were sent from one wallet to another. # Info Tab The Info tab provides key information about the token, including its description, trading volume, market capitalization, circulating supply, and on-chain valuation. This section is useful for investors, traders, and analysts who want to understand the token’s market performance and overall supply dynamics.
* **Overview Section**\ The **overview section** gives a brief description of the token. * **Volume (24H):** **$40,548,072,636**\ This represents the total value of this token traded in the last 24 hours across various exchanges and platforms. * **Market Capitalization:** **$1,632,035,673,526**\ Market capitalization (**market cap**) is calculated as ***Token Price × Circulating Supply*****.** This represents the total value of all tokens currently in circulation based on their market price. * **Circulating Supply: $19,834,746 USDT** \ This represents the total number of tokens currently available in the market for trading, holding, and use. * **On-Chain Market Capitalization: $134,303,479,645,801,600.** \ This represents the total valuation of all tokens recorded on the blockchain. # Contracts Tab The Contract tab allows users to inspect the smart contract source code, read functions, and interact with the token’s smart contract. It is particularly useful for developers, security analysts, and users who want to verify whether the contract is safe, transparent, and follows standard practices.
* **Contract Information**\ This section provides important details about the smart contract, including its compiler version, EVM version, and optimization settings. * **Contract Name:**\ The contract is named ***"MyToken",*** which is the official name of the token’s smart contract on the blockchain. * **EVM Version:**\ The contract runs on the ***"London EVM"*** version. EVM versions affect how smart contracts execute transactions and handle gas fees. * **Optimization Runs:**\ The contract was optimized with ***"200"***** runs** before deployment. * **Compiler Version:**\ The contract was compiled using ***"Solidity v0.8.26+commit.8a97fa7a"***. Different Solidity versions have specific security fixes and improvements. * **Optimization Enabled:**\ False (Optimization is Disabled). This means that the contract was deployed without gas optimizations, making it potentially more expensive to interact with. * **Contract Source Code Type:**\ The contract source code is stored in ***"solidity-standard-json-input"*** format. This format is used for structured contract compilation and debugging. It allows developers to easily analyze the code and verify its functions. * **Contract Source Code**\ Below, we see a partial view of the contract’s source code, which is written in **Solidity *****(the most widely used smart contract programming language)***. * The displayed code includes a function named **`toInt248(int256 value)`**, which is responsible for downcasting an integer from 256 bits to 248 bits. * **What does this function do?** * It ensures that the input number fits within 248 bits before storing or using it. * If the input is too large or doesn’t match the expected downcast value, the function **t**riggers a revert error, preventing the contract from continuing execution. * This type of function is used to reduce storage costs and improve efficiency. * **Why does this matter?** * If a contract has incorrect type conversions, it can lead to overflow/underflow bugs, potentially breaking the token's functionality. * Ensuring safe type conversions helps prevent security vulnerabilities and loss of funds. The full source code can be inspected further to check for other important functions like minting, burning, transfers, and access control. #### **Is the Contract a Proxy?** On the right side, there is a blue button labeled **"Is Proxy?"**. * **What is a Proxy Contract?** * Some tokens use a proxy contract architecture, which allows the contract logic to be upgraded in the future without changing the contract address. * This means the token owner can modify its behavior even after deployment. * **Why is this important?** * Non-proxy contracts are more secure because their logic cannot be changed after deployment. * Proxy contracts can be risky if the owner can upgrade them to add malicious functions, such as stealing user funds or minting unlimited tokens. * If this contract is a proxy, users should carefully check who controls it and whether ownership is renounced. If users want full transparency and security, they should avoid interacting with proxy contracts unless they trust the project team. # Token Transfer This screen displays a token transfer history dashboard for a BlockDAG-based blockchain network. It shows recent token transactions, including minting and transfers, along with details such as transaction hash, method, block number, age, sender, receiver, amount, and transaction fee.
#### **Total Transactions** At the top, it states that there are ***"63,711"*** total token transactions recorded. However, only a few transactions are shown on each page. Since there are ***"6,372"***** pages**, users can browse through transactions using pagination controls at the bottom. #### **Transaction Hash (TXN HASH)** Each transaction has a unique identifier called a transaction hash *(TXN HASH)*. This acts as a digital receipt for the transaction. It is displayed in a shortened format *(for example, **0xe01...87850**)* to make it easier to read. If users click on the transaction hash (if supported), they can view detailed transaction data, including gas fees, confirmations, and timestamps. #### **Transaction Method** The method column indicates the type of transaction. There are two main methods visible in the image: 1. **Mint:** This means new tokens were created and added to circulation. Minting transactions are usually done by a contract or a central authority. 2. **Transfer:** This means tokens were sent from one wallet to another. Transfers occur when users or smart contracts move tokens. #### **Block Number** Each transaction belongs to a specific block in the blockchain. The block number represents when the transaction was confirmed. For example, one transaction is in ***"Block 7283"***, while another is in ***"Block 7277"***. Higher block numbers mean more recent transactions. This helps users determine how long ago a transaction was processed. #### **Transaction Age** The age column shows how much time has passed since the transaction was added to the blockchain. For example, some transactions in the image occurred ***"2 days ago"***, while others happened ***"3 days ago"***. This information helps users track how recent or old a transaction is. #### **Sender and Receiver *****(From and To)*** The **From** column shows the wallet address that initiated the transaction, while the To column shows the recipient wallet address. Wallet addresses are displayed in a shortened format *(for example, **0x321...35Cde**)* to keep the display clean. If the same wallet appears in both From and To columns, it could indicate that the user is minting tokens for themselves or performing a contract-related operation. #### **Transaction Amount** The amount column shows how many tokens were transferred or minted in the transaction. In the image, some transactions transferred **$10**, while others moved **$5**. One transaction shows **$10T**, which could mean 10 trillion tokens or another token unit. The last transaction in the list shows **$0**, which might indicate a failed transaction or a token approval request. #### **Transaction Fee (TXN FEE)** The **transaction fee column displays the cost of processing the transaction**. In this image, all transactions have a fee of **$0**, which could mean: 1. The blockchain does not charge transaction fees, or it is a test network. 2. The sender has special permissions that allow free transactions. 3. The transactions were covered by a third party, such as a contract owner. # Node Visualizer ### **Blockchain Network Status** The BlockDAG Network Nodes section provides real-time insights into the network's operational status and performance. It displays key metrics such as the best block, which represents the latest validated block, and the finalized block, indicating the most recently confirmed block in the chain. The average time metric reflects the network's block processing speed, while the last block time shows how recently the latest block was added. Additionally, transactions per second *(TPS)* and transactions per block *(TPB)* provide a snapshot of the network's efficiency and throughput. This section offers a transparent view of the network's health, ensuring users can track and analyze BlockDAG’s decentralized infrastructure in real time.
* **Best Block *****(7283)*****:** This is the highest block currently created in the network. It represents the most up-to-date ledger state. * **Finalized Block *****(7283)*****:** This is the latest block that has been confirmed and finalized. A finalized block is immutable, ensuring no reorganization or changes. * **Average Time *****(0s)*****:** This value usually represents the average time taken to generate a block. A value of 0 seconds may indicate an issue with block production or an inactive network. * **Last Block *****(257331)*****:** The latest block in the Node Visualizer is the most recently validated block, showing its hash, parent hash, transactions, and connections in real time. * **Transactions Per Second *****(1)*****:** This shows the number of transactions processed per second on the network. A low TPS value might indicate either a low transaction load or network limitations. * **Transactions Per Block *****(0.8)*****:** This indicates the average number of transactions per block. A value below 1 suggests that not all blocks contain transactions (some might be empty). ### **Node Listing Toggle** The toggle switch in the top-right corner is turned on, which means the user is currently viewing the node list. If the user turns off the toggle, the display will switch to the graph view instead. ### **Node Information** This section provides details about a specific node participating in the blockchain network. * **Node ID *****(16Uiu...VnbEm)*****:** A unique identifier for the node in the network. Nodes use this ID to communicate and validate transactions. * **Node Name *****(BDAG)*****:** This is the assigned name for the node. * **Country *****(United States)*****:** The geographical location of the node. Nodes are often distributed worldwide for decentralization and resilience. * **City *****(Portland)*****:** The specific city where this node is operating. * **Node IP Address *****(34.213.42.117)*****:** The public IP address assigned to this node. Other nodes use this to establish peer-to-peer connections. # NFT The **NFT Module** provides users with real-time insights into the activity happening around Non-Fungible Tokens (NFTs) on the blockchain. It is divided into two key sub-modules: * **Latest Transfer** * **Latest Mint** These sections allow users to monitor the movement and creation of NFTs with detailed transaction information. # Latest transfers ### 1. Latest Transfer The **Latest Transfer** sub-module displays the most recent transfers of NFTs between wallets.\ It provides transparency on NFT ownership changes and helps track activity within the ecosystem. #### Key Columns: * **Txn Hash**: Unique identifier of the transaction. Clicking on it will take you to the transaction details page. * **Method**: Indicates the action or function executed (e.g., transfer). * **Block**: The block number in which the transaction was recorded. * **Age**: Time elapsed since the transaction was added to the blockchain. * **From**: The wallet address sending the NFT. * **To**: The wallet address receiving the NFT. * **Type:** It tells the type of NFT that was transferred. * **Item:** this displays the image of the sample NFT
If there are no recent transfers, the page will display **“No Data Found”** ### NFT Transfer Detail Page When you click on an NFT from the **Latest Transfer** list, you are taken to a **detail page** that provides complete information about the NFT and its transaction history. #### Information Displayed **1. NFT Preview** * A visual preview of the NFT is shown on the left side (image, videos and GIF). * This helps users easily identify the NFT in question. **2. NFT Metadata** The right panel lists important details about the NFT: * **Creator**: The wallet address that originally created (minted) the NFT. * **Contract Address**: The smart contract address managing the NFT collection. * **Owner**: Current wallet address holding the NFT. * **Contract Type**: The token standard used (e.g., ERC721, ERC1155). * **Quantity**: The number of tokens held (relevant for multi-token standards like ERC1155). * **Mint Time**: Timestamp of when the NFT was minted on the blockchain.
**3. Transaction History** Below the NFT details, you can see a table summarizing all transactions involving the NFT. **Columns in the Transaction History:** * **Txn Hash**: Unique identifier of the transaction (clickable for deeper details). * **Block**: Block number in which the transaction was recorded. * **Age**: Time elapsed since the transaction occurred. * **Type**: Type of transfer (e.g., ERC721 or ERC1155). * **From**: The wallet address that transferred/sent the NFT. * **To**: The wallet address that received the NFT. This gives users a transparent view of how the NFT has changed hands over time.
**Use Case for Users**: * Collectors can validate NFT authenticity and ownership history. * Traders can check how frequently an NFT has been transferred. * Developers and community members can monitor contract-level activities for specific NFTs. # Latest Mint The **Latest Mint** sub-module provides details of newly created NFTs. Minting refers to the process of generating a new NFT on the blockchain, making it unique and verifiable. #### Key Columns: * **Transaction Hash**: Unique identifier of the minting transaction. * **Block**: Block number in which the mint took place. * **Age**: Time elapsed since the minting transaction was added to the blockchain. * **Maker**: The wallet address that initiated the minting of the NFT. * **Type**: Specifies the standard/type of NFT minted (for example, ERC-721, ERC-1155, or other supported standards).
If no minting activity has occurred recently, the page will show **“No Data Found”**. **Tip for Users:** These sections are useful for collectors, traders, and developers who want to monitor NFT activities such as recent transfers between users or the creation of new NFTs in real time. ### NFT Mint Detail Page When you click on an NFT from the **Latest NFT Mint** list, you are taken to a **detail page** that provides complete information about the NFT and its transaction history. #### Information Displayed **1. NFT Preview** * A visual preview of the NFT is shown on the left side (image, videos and GIF). * This helps users easily identify the NFT in question. **2. NFT Metadata** The right panel lists important details about the NFT: * **Creator**: The wallet address that originally created (minted) the NFT. * **Contract Address**: The smart contract address managing the NFT collection. * **Owner**: Current wallet address holding the NFT. * **Contract Type**: The token standard used (e.g., ERC721, ERC1155). * **Quantity**: The number of tokens held (relevant for multi-token standards like ERC1155). * **Mint Time**: Timestamp of when the NFT was minted on the blockchain.
**3. Transaction History** Below the NFT details, you can see a table summarizing all transactions involving the NFT. **Columns in the Transaction History:** * **Txn Hash**: Unique identifier of the transaction (clickable for deeper details). * **Block**: The block number in which the transaction was recorded. * **Age**: Time elapsed since the transaction occurred. * **Type**: Type of transfer (e.g., ERC721 or ERC1155). * **From**: The wallet address that transferred/sent the NFT. * **To**: The wallet address that received the NFT. This gives users a transparent view of how the NFT has changed hands over time.
# Stats & Graphs The **Graphs & Stats** module in BlockDAG Explorer provides a complete overview of the network activity, blockchain state, and smart contract statistics. It helps community members track performance, transactions, and usage trends of the BlockDAG testnet. ### Accessing the Module From the left navigation menu, click on **Stats & Chart**. You will see four key sections: 1. **Overview State** 2. **Blockchain Data** 3. **Contract Data** 4. **Network Data** Each section provides different insights into the network’s health and usage. ### 1. Overview State The **Overview State** gives a quick snapshot of the network. Key metrics displayed include: * **Addresses (Total):** Number of unique wallet addresses created. * **Transactions (Total / 24H):** Total number of transactions processed and new ones in the last 24 hours. * **New Addresses (24H):** Count of wallets created in the past 24 hours. * **Pending Transactions (24H):** Number of transactions waiting to be confirmed. * **Total & Average Transaction Fees (24H):** Fee details for transactions processed within the last 24 hours. * **Tokens (Total):** Total number of tokens deployed on the network. * **Contracts (Deployed / Verified):** Number of contracts created and successfully verified. * **Gas Used (24H):** Total gas consumption within the last 24 hours. * **Network Utilization (24H):** Shows how much of the network’s capacity was used in the past 24 hours.
### 2. Blockchain Data: The **Blockchain Data** section provides deep insights into the network’s transaction, block, and token-level activity. Various charts are available to track performance over time: * **Daily Txn Chart:** Shows the total number of transactions executed each day, giving insight into overall activity trends. * **ERC20 Daily Token Transfer Chart:** Tracks daily token transfers for ERC20 tokens, helping monitor token adoption and circulation. * **Avg Gas Price Chart:** Displays the average gas price across transactions, useful for understanding transaction cost trends. * **Avg Block Time Chart:** Shows the average time taken to produce a block, an indicator of network speed and efficiency. * **Avg Block Size Chart:** Represents the average size of blocks, showing how much data is being packed per block. * **Avg Gas Limit Chart:** Tracks the average gas limit set for blocks, reflecting network throughput capacity. * **Avg Txn Fee Chart:** Shows the average transaction fee paid per day, useful for evaluating network cost efficiency. * **Unique Address Chart:** Displays growth in unique wallet addresses created, an indicator of user adoption. * **Daily Gas Used Chart:** Shows the total gas consumed per day, reflecting overall transaction and contract activity. * **Daily Active ERC20 Address:** Tracks how many unique ERC20 addresses are active per day, providing insights into token ecosystem engagement.
On click of each chart the user is redirected to a more detailed chart with time range filter in it. ### 3. Contracts Data: This section focuses on **smart contract deployment and verification trends**, giving developers and community members visibility into dApp activity. * **Daily Deployed Contracts Chart:** Shows how many new contracts are deployed on the network each day. This reflects developer activity and adoption of the chain for dApp building. * **Daily Verified Contracts Chart:** Tracks how many contracts were successfully verified daily. Verified contracts are open and auditable, which builds transparency and trust in the ecosystem.
### 3. Network Data: The **Network Data** section gives a view into the **operational health and usage of the network**. * **Network Utilisation Chart:** Displays how much of the network’s total capacity is being used. Low utilization suggests unused capacity, while higher utilization shows strong network activity. * **Pending Txn Chart:** Shows the number of pending transactions waiting to be confirmed, giving insight into congestion levels. * **Network Txn Fee Chart:** Tracks the overall transaction fees across the network, helping assess transaction cost trends. * **Node Tracker Chart:** A global map showing the distribution of network nodes worldwide, useful to understand decentralization and participation.
# New Features This explains the content that has been newly added to this blockchain release. The following are the components in this release: 1. **Account Abstraction:** The **ERC-4337 Account Abstraction (AA) implementation on the BlockDAG** introduces a new transaction model that moves away from externally owned accounts (EOAs) toward smart contract-based accounts with customizable validation logic. Instead of sending traditional transactions, users create **UserOperations (UserOps)**, which are richer transaction objects containing fields like sender, nonce, callData, initCode, gas limits, fee settings, and optional Paymaster data. These UserOps are submitted to a specialized **bundler service** rather than the normal Ethereum mempool. The bundler validates them using the **EntryPoint v0.6 contract**, maintains a reputation-based mempool, and batches multiple UserOps into a single transaction that the EntryPoint executes. The system comprises three main components: **EntryPoint**, a core smart contract that handles validation, execution, replay protection, deposits, and emits standardized logs; the **Bundler Service**, which accepts UserOps via RPC, simulates validation, manages the alternative mempool, and bundles operations efficiently; and the **Verifying Paymaster**, which enables **gasless transactions** by sponsoring gas fees for users after verifying signatures and validity windows. Together, these components unlock features such as custom signature schemes (MPC, biometrics, social recovery), sponsored transactions, account upgradeability, batching, and enhanced UX for decentralized applications. By deploying EntryPoint v0.6, extending the reference bundler, and integrating the Verifying Paymaster, the BlockDAG mainnet now supports a **secure, extensible, and user-friendly account abstraction framework**. This lays the foundation for programmable accounts, gas sponsorship, and advanced transaction flows, making decentralized applications more accessible and flexible without requiring consensus-layer changes. 2. **Upgradability** **with Governance**: The **GovernanceV1 contract** is a decentralized governance framework that enables token holders to create and vote on proposals using staked BDAG or ERC20 tokens, with an added council oversight mechanism to ensure balanced execution. Governance operates in four phases: proposal creation, community voting, council review, and final execution. Proposals can only be created by users with the **Proposer Role** who meet the staking threshold, and voting power is determined by the amount of tokens staked. Once a proposal passes community voting by meeting quorum and majority requirements, it moves to the **Council Review** stage, where council members—trusted participants holding the **Council Role**—decide whether it should be executed. At least 60% of council votes must support execution for it to proceed, after which users with the **Executor Role** can finalize the proposal. The system incorporates multiple security and administrative controls through roles such as **Admin** (who manages council members, voting parameters, and upgrades) and **Default Admin** (the super admin). To prevent abuse, the contract requires proposer deposits, enforces slashing on canceled proposals, and includes safeguards like reentrancy protection, pausability, and upgradeability via OpenZeppelin’s UUPS pattern. Together, these mechanisms ensure that governance decisions are transparent, community-driven, and secured with strong checks and balances. # Account Abstraction **Version:** ERC-4337 (EntryPoint v0.6)\ **Deployed Components:** EntryPoint, Bundler Service, Verifying Paymaster\ **Network:** BlockDAG Mainnet ### 1. Introduction Account Abstraction (AA) redefines Ethereum’s account model by moving from Externally Owned Accounts (EOAs) with private keys and gas payments toward smart contract accounts that define their own validation logic. The key enabler is ERC-4337, which introduces a new transaction flow without requiring changes to Ethereum’s consensus layer. Instead of EOAs sending transactions directly, users submit UserOperations (UserOps) to an alternative mempool, processed by a bundler service. This model unlocks: * Custom signature schemes (biometrics, MPC, social recovery). * Gas sponsorships (transactions without holding ETH). * Flexible UX (batching, meta-transactions, account upgradeability). ### 2. UserOperations A UserOperation is the ERC-4337 equivalent of a transaction, but with richer structure. #### Core Fields * sender – Smart account address. * nonce – Replay protection. * initCode – Code to deploy the account if it doesn’t exist yet. * callData – Encoded function calls. * callGasLimit, verificationGasLimit, preVerificationGas – Gas budgeting. * maxFeePerGas, maxPriorityFeePerGas – Fee configuration (EIP-1559 compatible). * paymasterAndData – Optional field for Paymaster sponsorship. * signature – Authorization proof.\
1. User signs and submits a UserOperation to the bundler RPC. 2. Bundler validates via simulateValidation in EntryPoint. 3. If valid, it enters the alternative mempool. 4. Bundler selects UserOps, forms a bundle, and submits a single transaction to EntryPoint. 5. EntryPoint executes and emits UserOperationEvent logs.
### 3. Core Components #### 3.1 EntryPoint Contract (v0.6) * Deployed once per chain. * Provides validation and execution logic. * Tracks deposits for accounts and Paymasters. * Ensures replay protection and security checks. * Emits logs (UserOperationEvent) for monitoring. #### 3.2 Bundler Service The bundler is a specialized node implementing the ERC-4337 mempool and RPC. **Responsibilities** * Accept UserOps via RPC (eth\_sendUserOperation). * Run simulateValidation: * Validates account logic. * Checks Paymaster conditions. * Computes prefunding. * Maintain mempool and reputation system. * Bundle UserOps based on thresholds/time and submit to EntryPoint. * Provide query methods: * eth\_estimateUserOperationGas * eth\_getUserOperationReceipt * eth\_getUserOperationByHash **Execution Flow** 1. Validate UserOp. 2. Compute prefund requirement. 3. Add to mempool with reputation tracking. 4. Bundle → Submit → Process events. **Bundler implementation:** Eth Infinitism reference repo, extended for BlockDAG. #### 3.3 Paymaster Contract (Verifying Paymaster) The Verifying Paymaster enables gasless transactions by covering gas costs for users. **How paymasterAndData Works** paymaster(20 bytes) \+ abi.encode(uint48 validUntil, uint48 validAfter) \+ signature * Constructed by VerifyingPaymasterAPI.ts. * Signs a hash of the UserOperation plus validity window. * Computes preVerificationGas (PVG) with a placeholder signature, re-signs if necessary.\
**Runner Integration** * CLI flags: * \--paymaster \ * \--verifierMnemonic \ * \--pmValidFor \ * \--pmAutoTopUp * Verifies account owner and Paymaster signatures before submission. * Can automatically top up the Paymaster deposit in EntryPoint.\
**Requirements** * Paymaster must be staked and funded. * On-chain verifying signer must match the local signer. **Outputs** * Logs PVG components and computed hash. * Provides detailed error diagnostics on failure. ### 4. System Workflow flowchart TD A\[User] -->|Signs UserOp| B\[Bundler RPC] B --> C\[simulateValidation in EntryPoint] C -->|Valid| D\[Mempool] D --> E\[Bundle Manager] E -->|Submit tx| F\[EntryPoint Contract] F -->|Executes call| G\[dApp/Smart Account] F -->|Gas Sponsorship| H\[Verifying Paymaster] F --> I\[UserOperationEvent Logs] ### 5. References * ERC-4337 Specification:\ [EIP-4337: Account Abstraction Using Alt Mempool
](https://eips.ethereum.org/EIPS/eip-4337) * EntryPoint Contracts:\ [account-abstraction repo
](https://github.com/eth-infinitism/account-abstraction) * Bundler Implementation:\ [eth-infinitism bundler](https://github.com/eth-infinitism/bundler) ### 6. Conclusion Account Abstraction on BlockDAG introduces programmable accounts, gasless transactions, and advanced sponsorship models. With EntryPoint v0.6, a fully compliant bundler service, and the Verifying Paymaster, we have established a secure and extensible framework for user-friendly decentralized applications.
# Account Abstraction Deployment Report **Environment:** BlockDAG Network\ **Version:** EntryPoint v0.6, Bundler Service, Verifying Paymaster ### 1. Introduction We have successfully deployed Account Abstraction (AA) components on the BlockDAG test network in line with ERC-4337 specifications. This deployment includes: * EntryPoint v0.6 Contract – the central router for UserOperations. * Bundler Service – a spec-compliant service for UserOperation validation, mempooling, and bundling. * Verifying Paymaster Contract – an on-chain paymaster enabling sponsored (gasless) transactions with signature validation. Together, these provide a secure and user-friendly foundation for gas abstraction and next-generation dApps. ### 2. Components Deployed #### 2.1 EntryPoint v0.6 * Core contract validating and executing UserOperations. * Provides replay protection, batching, and signature verification. * Fully aligned with ERC-4337. #### 2.2 Bundler Service The bundler was deployed using the Eth Infinitism reference implementation and extended for our BlockDAG environment. Key Features: * Spec RPC Endpoints: eth\_sendUserOperation, eth\_estimateUserOperationGas, eth\_getUserOperationReceipt, eth\_getUserOperationByHash. * Validation Pipeline: Uses simulateValidation to ensure correctness before acceptance. * Mempool & Reputation: Valid UserOps are queued, invalid ones filtered with reputation checks. * Execution Flow: Validate → Prefund/Paymaster check → Mempool → Bundle → Submit → Event tracking. * Diagnostics: Detailed logging for signatures, prefund, gas fields, and execution results. #### 2.3 Verifying Paymaster Contract The Verifying Paymaster allows transactions to be sponsored by an on-chain contract, removing the need for users to hold native gas tokens. **How It Works** * The paymasterAndData field is built as:
paymaster(20 bytes) \+ abi.encode(uint48 validUntil, uint48 validAfter) \+ signature * Implementation in VerifyingPaymasterAPI.ts: * Ensures the local verifying signer matches the on-chain verifyingSigner. * Computes preVerificationGas with a placeholder 65-byte signature. * Signs getHash(op, validUntil, validAfter). * If PVG changes, re-computes and re-signs.
**Runner Usage** The runner (runop.ts) provides flexible integration: * \--paymaster \
– specify Paymaster contract. * \--verifierMnemonic \ – load verifying signer. * \--pmValidFor \ – define validity window. * \--pmAutoTopUp – automatically fund Paymaster deposit if required. It verifies both account owner signatures and Paymaster signatures before sending. **Prerequisites** * EntryPoint deployed and registered. * Paymaster staked and funded on-chain. * Verifying signer is configured on-chain and locally available. **Outputs & Diagnostics** * Logs PVG components and computed hashes. * Signature length and recovery checks. * Detailed failure dumps for gas or validation errors. **Example Workflow** 1. Start Bundler: | yarn bundler --config ./localconfig/bundler.config.json --unsafe --auto | | ----------------------------------------------------------------------- | 2. Send UserOperation with Paymaster: |

yarn runop \
--deployFactory \
--network \
--entryPoint 0x5FF1...2789 \
--paymaster 0xAaBb...1122 \
--verifierMnemonic ./verifier.txt \
--pmValidFor 300 \
--pmAutoTopUp

| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 3. paymasterAndData Layout: 0x<20-byte paymaster address> \ \ \ ### 3. Benefits to the User * Gasless Transactions: Users interact without holding native tokens. * Custom Sponsorship Policies: Time-bound or conditional approvals. * Diagnostics & Security: Strong validation checks and transparent failure reporting. * Future-proof: Compatible with ERC-4337 tooling and SDKs. # Run-time Chain Upgradability ## GovernanceV1 Contract ### Overview The GovernanceV1 contract is a sophisticated decentralized governance system that allows token holders to create and vote on proposals, with an additional council oversight layer for execution approval. The contract supports both BDAG and ERC20 token staking. ### Key Features * Proposal Creation & Voting: Users can create proposals and vote with staked tokens/BDAG * Council Oversight: A council of trusted members provides an additional layer of approval * Stake-based Voting: Voting power is determined by the amount staked * Upgradeable: Uses OpenZeppelin's UUPS upgrade pattern * Security Features: Reentrancy protection, pausable functionality, and access controls ### Contract Roles #### 1. DEFAULT\_ADMIN\_ROLE: * #### Can grant/revoke all roles, including ADMIN\_ROLE. * #### It’s the “super admin”. #### 2. ADMIN\_ROLE * Permissions: Ultimate authority over the contract * Can do: * Grant/revoke all other roles * Add/remove council members * Change voting parameters * Pause/unpause the contract * Authorize contract upgrades #### 3. PROPOSER\_ROLE * Permissions: Can create new proposals * Requirements: Must stake the minimum threshold amount #### 4. EXECUTOR\_ROLE * Permissions: Can execute approved proposals * Requirements: The proposal must pass the council voting #### 5. COUNCIL\_ROLE * Permissions: Council members who vote on proposal execution * Requirements: Minimum 5 council members required for the system to function ### How Governance Works #### Phase 1: Proposal Creation 1. Proposer creates a proposal with a description 2. Stake Required: Must deposit minimum threshold (BDAG or tokens) 3. Voting Period: Starts immediately and runs for the set voting period #### Phase 2: Community Voting 1. Duration: Configured voting period (1 hour to 15 days) 2. Participation: Any user can vote by staking tokens/BDAG 3. Vote Types: FOR or AGAINST 4. Requirements: 5. Quorum must be met (total votes ≥ quorum threshold) 6. The majority must vote FOR #### Phase 3: Council Review (if proposal succeeds) 1. Trigger: Any council member can start council voting 2. Duration: Configured council voting window (1 hour to 7 days) 3. Vote Types: FOR, AGAINST, or ABSTAIN 4. Execution Requirements: 5. 60% of active votes (FOR + AGAINST) must be FOR 6. Abstain votes don't count toward quorum #### Phase 4: Execution 1. Who: Users with EXECUTOR\_ROLE 2. When: After the council voting period ends and requirements are met 3. Result: Proposal is executed, and the proposer gets the deposit back ### User Actions Guide Creating a Proposal Requirements: * Have PROPOSER\_ROLE * Stake minimum threshold amount * Description ≤ 256 characters Steps: // For BDAG staking propose("Proposal description") { value: stakingAmount } // For ERC20 token staking // 1. First approve tokens token.approve(governanceContract, stakingAmount) // 2. Then propose propose("Proposal description") #### Voting on Proposals Requirements: * Proposal must be in Active state * Haven't voted on this proposal yet * Have tokens/BDAG to stake Steps: // Vote FOR with BDAG vote(proposalId, VoteType.For, amount) { value: amount } // Vote AGAINST with tokens // 1. Approve tokens first token.approve(governanceContract, amount) // 2. Then vote vote(proposalId, VoteType.Against, amount) #### Council Voting (Council Members Only) Requirements: * Have COUNCIL\_ROLE * Proposal must be in CouncilVoting state * Haven't voted on this proposal yet Steps: // Vote options: CouncilType.Against (0), CouncilType.For (1), CouncilType.Abstain (2) councilVoteToExecute(proposalId, CouncilType.For) #### Withdrawing Stakes When you can withdraw: * Proposal failed during voting * Proposal was canceled * Proposal was executed * Proposal succeeded but no council voting started within 7 days * Council voting failed Steps: withdrawStake(proposalId) #### Withdrawing Proposer Deposit When proposers can withdraw: * Proposal failed during community voting * Proposal succeeded but no council voting started within 7 days Steps: withdrawProposerDeposit(proposalId) *** ### Proposal States Explained | State | Description | What Users Can Do | | ------------- | ----------------------- | ---------------------------------------------- | | Pending | Before voting starts | Wait for voting to begin | | Active | Community voting period | Vote with stakes | | Succeeded | Passed community vote | Council can start council voting | | Failed | Failed community vote | Withdraw stakes | | CouncilVoting | Council review phase | Council members vote, others wait | | Executed | Successfully executed | Withdraw stakes | | Canceled | Proposal canceled | Withdraw stakes (proposer gets partial refund) | *** ### Important Parameters #### Voting Parameters * Voting Period: 1 hour to 15 days * Council Voting Window: 1 hour to 7 days * Minimum Proposal Threshold: 0.1 BDAG (configurable for tokens) * Council Execution Quorum: 60% of active votes must be FOR #### Limits * Maximum Description Length: 256 characters * Maximum Council Size: 100 members * Minimum Council Members: 5 (required for functionality) * Slash Percentage: 50% (applied to canceled proposal deposits) #### Timeouts * Council Voting Deadline: 7 days after proposal ends to start council voting * Stake Withdrawal: Available immediately after final state is reached ### Key Functions Reference #### Core Functions * propose(description) - Create a new proposal * vote(proposalId, voteType, amount) - Vote on a proposal * startCouncilVoting(proposalId) - Start council review phase * councilVoteToExecute(proposalId, councilVote) - Council member votes * execute(proposalId) - Execute approved proposal * cancel(proposalId) - Cancel proposal (admin/council only) #### Stake Management * withdrawStake(proposalId) - Withdraw voting stakes * withdrawProposerDeposit(proposalId) - Withdraw proposal deposit #### View Functions * getProposal(proposalId) - Get complete proposal information * getProposalState(proposalId) - Get current proposal state * canExecute(proposalId) - Check if proposal can be executed * getCouncilMembers() - Get list of council members * getCouncilVoteInfo(proposalId, member) - Get council member's vote ### Security Features #### Access Controls * Role-based permissions for different actions * Multi-signature style council approval for execution * Proposer deposits to prevent spam #### Economic Security * Stake-based voting aligns incentives * Slashing mechanism for canceled proposals (50% penalty) * Deposit requirements prevent frivolous proposals #### Technical Security * Reentrancy protection on all state-changing functions * Pausable functionality for emergency situations * Upgradeable design for future improvements * Safe token transfers using OpenZeppelin libraries \ **Common Scenarios** #### Scenario 1: Successful Proposal Flow 1. User creates proposal with required stake 2. Community votes and proposal passes quorum + majority 3. Council member starts council voting 4. Council votes and 60%+ vote FOR 5. Executor executes the proposal 6. All participants withdraw their stakes #### Scenario 2: Failed Proposal 1. User creates proposal 2. Community votes but fails to meet quorum or majority votes AGAINST 3. Proposer and voters can withdraw stakes immediately 4. Proposer gets full deposit back #### Scenario 3: Council Rejection 1. Proposal passes community voting 2. Council voting starts but fails to get 60% FOR votes 3. Proposal can be canceled after council voting ends 4. Proposer gets 50% deposit back (50% slashed to treasury) 5. Voters can withdraw full stakes ### Best Practices #### For Proposers 1. Write clear, concise descriptions (≤256 characters) 2. Ensure you meet the threshold before proposing 3. Monitor your proposal through all phases 4. Withdraw deposits promptly when eligible #### For Voters 1. Vote with appropriate amounts based on conviction 2. Monitor proposal progress to know when to withdraw 3. Participate actively in governance for healthy ecosystem 4. Understand the risks - stakes are locked until completion #### For Council Members 1. Vote responsibly on execution decisions 2. Start council voting promptly for successful proposals 3. Consider community sentiment when making decisions 4. Maintain active participation to ensure system functionality ### Error Messages & Troubleshooting #### Common Errors * "Invalid proposal" - Proposal ID doesn't exist * "Not active" - Trying to vote on non-active proposal * "Already voted" - Attempting to vote twice on same proposal * "Insufficient BDAG/tokens" - Not enough stake provided * "Cannot withdraw yet" - Proposal not in final state * "Cannot execute" - Council voting requirements not met ### Integration Guide for Developers #### Contract Address & ABI * Deploy the contract with proper initialization parameters * Grant appropriate roles to initial users * Set up proper monitoring for governance events #### Event Monitoring Key events to monitor: * ProposalCreated - New proposals * VoteCast - Voting activity * CouncilVotingStarted - Council phase begins * CouncilExecutionVote - Council member votes * ProposalExecuted - Successful execution * ProposalCanceled - Canceled proposals This governance system provides a robust framework for decentralized decision-making with appropriate checks and balances through the council system.
# Issues & Recommendations **1. RPC Node Inconsistency** * Transactions may appear confirmed on the explorer but pending via RPC. * Read calls (`eth_call`) can revert for recently created functions or NFTs. * Some RPC endpoints return 500 errors or time out under load. **2. Delayed Read-After-Write** * Newly submitted data (functions, NFTs, transactions) may take several minutes to propagate across all nodes. * Frontend verification may fail immediately after a successful write. **3. Account Abstraction / Bundler** * Same UserOperation works on other chains but fails on BlockDAG if RPC is out of sync. * Ensure RPC endpoint used is fully synced before testing. **4. Stuck Transactions / Pending Receipts** * Transactions may remain in limbo temporarily. * Avoid canceling or redeploying immediately; wait for network convergence. ### Recommendations **For Builders / Developers** * Use explorer as the source of truth when RPC and frontend disagree. * Log RPC endpoint, transaction hash, and screenshots to help diagnose issues. * Implement retry logic in frontend for reads that may fail temporarily. * Allow non-blocking verification in UIs to prevent workflow interruption. # BlockDAG Crypto Mining: Expectations and Preparation Guide **INTRODUCTION** \ Welcome to the world of cryptocurrency mining, with a special focus on the emerging BlockDAG technology. This guide aims to set realistic expectations about mining profitability, explain what you need to know before investing in mining hardware, and prepare you for the upcoming release of ASIC miners specifically designed for BlockDAG. \ **UNDERSTANDING BLOCKDAG TECHNOLOGY** \ BlockDAG (Directed Acyclic Graph) represents an evolution from traditional blockchain architecture, offering several fundamental advantages: \ BlockDAG differs from traditional blockchains by allowing multiple blocks to be added simultaneously in a graph structure, where each block can reference multiple previous blocks. This contrasts with traditional blockchains that add blocks sequentially in a single chain. \ *The key benefits of BlockDAG include:* \ ● Higher throughput: Multiple blocks processed simultaneously means higher transaction capacity \ ● Faster confirmation times: The parallel structure allows for quicker transaction finality \ ● Better scalability: Network performance actually improves with more participants \ ● Greater resistance to centralization: The architecture helps distribute mining opportunities more equitably \ Currently, BlockDAG exists primarily in testnet phase, with mining only possible through specialized nodes. However, dedicated ASIC mining hardware is coming soon, which will open up new opportunities for miners. \ **WHAT IS CRYPTO MINING REALLY?**
At its core, cryptocurrency mining serves two essential functions: 1. Network security: Miners validate transactions and secure the network through distributed consensus 2. Currency issuance: Mining introduces new coins into circulation according to predetermined protocols When you mine, your specialized hardware works to solve complex cryptographic puzzles. Successful miners receive newly created coins as rewards, plus any transaction fees included in the blocks they process. Mining is fundamentally a competitive process – your rewards are proportional to the computational power (hash rate) you contribute relative to the entire network.
**MANAGING PROFITABILITY EXPECTATIONS** \ Understanding the economics of mining is crucial for making informed decisions: \ **Key Profitability Factors** \ ● Hardware investment: ASIC miners represent a significant upfront cost \ ● Electricity expenses: Your largest ongoing operational cost \ ● Market price volatility: Revenue fluctuates with cryptocurrency prices \ ● Network difficulty adjustments: As more miners join, individual rewards typically decrease \ ● Hardware lifecycle: ASICs have limited useful lifespans as newer models emerge
**Realistic Return Projections**
For most miners, the break-even point typically falls between 9-18 months after initial investment, assuming stable market conditions. *Several scenarios worth considering:* \ ● Bull market: Faster returns possible as coin prices increase \ ● Sideways market: ROI depends primarily on operational efficiency \ ● Bear market: Miners may operate at a loss while awaiting market recovery
Professional miners often calculate their "cost per coin" – the total expense of mining a single coin – and compare this to market prices to determine profitability.
**BLOCKDAG-SPECIFIC CONSIDERATIONS**
*As BlockDAG mining is still emerging*: \ ● Early adopters may benefit from lower initial network difficulty \ ● Hardware specifically designed for BlockDAG's algorithms will likely command premium prices initially \ ● Mining economics may be more volatile until the ecosystem matures
**Setting Up Your Mining Environment** \ A well-designed mining setup maximizes efficiency and hardware longevity, particularly important for ASIC operations. \ **ASIC Hardware Planning**
*When the BlockDAG ASIC miners become available*: \ ● Understand that ASICs are single-purpose machines specifically designed for particular algorithms \ ● Research power consumption specifications carefully – this directly impacts profitability \ ● Consider space requirements and noise generation – ASICs are typically louder than other computing hardware \ ● Plan for limited resale value as these are specialized devices
**Cooling Requirements**
*Effective cooling is absolutely essential for ASIC mining:* \ ● ASICs generate significant heat during operation \ ● Ambient temperature should ideally remain below 80°F (27°C) \ ● Industrial cooling solutions may be necessary for larger operations \ ● Inadequate cooling will reduce hardware lifespan and performance
**Power Infrastructure**
*ASIC miners demand robust electrical infrastructure:* \ ● Verify your electrical system can handle the amperage requirements \ ● Consider dedicated circuits for mining operations \ ● Install surge protection and power distribution units \ ● Calculate total power costs based on your local electricity rates \ ● Explore options for more affordable power sources if scaling up
**Network Considerations**
*Stable connectivity is crucial for consistent mining:* \ ● Ensure reliable internet connection with minimal downtime \ ● Wired connections are preferable to wireless for stability \ ● Consider backup internet options for critical operations \ ● Understand bandwidth requirements, especially for initial blockchain synchronization
**SOLO MINING VS POOL MINING**
**Solo Mining** \ *Advantages:* \ ● Full block rewards when successful \ ● No pool fees \ ● Complete autonomy over mining operations \ *Disadvantages:* \ ● Extremely unpredictable income \ ● May go months without finding a block \ ● Only viable with substantial mining power or on very new networks \ Solo mining makes sense primarily for miners with very large operations or those mining newer coins with lower difficulty.
**Pool Mining** \ *Advantages:* \ ● Steady, predictable income \ ● Lower variance in rewards \ ● Suitable for miners of all sizes \ *Disadvantages:* \ ● Pool fees reduce earnings (typically 1-3%) \ ● Less control over mining operations \ ● Dependence on pool reliability and honesty
For most miners, especially those just starting, pool mining provides the most reliable return on investment. *When selecting a pool, consider*: \ ● Fee structure \ ● Payout thresholds and frequency \ ● Server locations (proximity reduces latency) \ ● Pool size and reputation \ ● Supported payment methods
For BlockDAG mining specifically, expect specialized pools to emerge once the mainnet launches and ASIC mining hardware becomes available.
**ADDITIONAL CONSIDERATIONS**
**Tax and Legal Compliance**
Mining generates taxable income in most jurisdictions. Keep detailed records of: \ ● All equipment purchases \ ● Electricity and operational costs \ ● Mining rewards received with timestamps \ ● Market value of coins at the time of receipt
Consider consulting with a tax professional familiar with cryptocurrency to ensure compliance.
**Security Best Practices** \ ● Use hardware wallets to secure mined coins \ ● Implement strong passwords and two-factor authentication \ ● Keep all software updated \ ● Maintain physical security for your mining equipment \ ● Consider operational security to protect your mining location
**Long-term Strategy Development**
*Successful miners typically adopt one of these approaches:* \ ● HODL strategy: Mine and hold coins, betting on future appreciation \ ● Immediate conversion: Regularly convert mined coins to fiat currency \ ● Hybrid approach: Convert enough to cover expenses, hold the remainder
Whichever strategy you choose, establish clear profit-taking and loss-limiting parameters.
**PREPARING FOR BLOCKDAG ASIC MINING**
As BlockDAG transitions from testnet to mainnet with dedicated ASIC hardware, here are key preparation steps: 1. Stay informed: Follow official BlockDAG project communications about mining specifications 2. Evaluate hardware announcements: Review specifications, power requirements, and projected hash rates 3. Plan infrastructure: Ensure your electrical, cooling, and network infrastructure can support the new hardware 4. Budget appropriately: Factor in both acquisition costs and ongoing operational expenses 5. Connect with the community: Join BlockDAG mining communities to share information and strategies
**CONCLUSION**
BlockDAG mining represents an exciting frontier in cryptocurrency, potentially offering improved economics through its innovative architecture. However, successful mining requires careful planning, realistic expectations, and proper infrastructure. \ As dedicated ASIC hardware becomes available for BlockDAG mining, those who have prepared thoroughly will be best positioned to capitalize on this opportunity. Remember that the crypto mining landscape evolves rapidly—staying informed and adaptable will be key to your mining success. \ While BlockDAG is currently in its early stages, the foundations you build now—in knowledge, infrastructure, and strategy—will serve you well when full mining capabilities launch. # BlockDAG Primordial Testnet: Node Operator's Onboarding Guide **INTRODUCTION** \ Welcome to the BlockDAG ecosystem! This guide will help you navigate the available resources and understand how to get started as a node operator on the BlockDAG Primordial testnet. Rather than providing explicit technical instructions, this document serves as a roadmap to help you locate and utilize the official resources effectively. \ **UNDERSTANDING BLOCKDAG'S VISION** \ Before diving into the technical aspects, it's worth understanding what makes BlockDAG unique. According to the BlockDAG Network website, BlockDAG implements a Directed Acyclic Graph structure that allows for parallel block processing, offering significant improvements in transaction throughput and network scalability compared to traditional blockchain architectures. \ The Primordial testnet represents an early opportunity to participate in this ecosystem, helping to build and secure the network while it's still in development.
**RESOURCES OVERVIEW**
**Main Resources** 1. Official Website: ○ The primary source for general information about BlockDAG \ ○ Contains links to other official resources and documentation \ ○ Features updates about network status and developments\\ \ 2\. GitHub Repository: ○ Contains scripts and tools necessary for node operation \ ○ Includes configuration examples and documentation \ ○ The primary technical resource for operators\\ \ 3\. Discord Community: Join through the link on the official website ○ Direct support from team members and experienced community members \ ○ Announcements about network updates and changes \ ○ Troubleshooting assistance from other node operators\\ \ 4\. BlockDAG Explorer: Available through the website ○ Monitor network activity \ ○ Verify your node's participation \ ○ Track blocks and transactions\\ \ **GETTING STARTED: YOUR JOURNEY MAP** \ **Phase 1: Preparation and Research** 1. *System Requirements Assessment* ○ Navigate to the GitHub repository's README file \ ○ Review the hardware and software requirements \ ○ Ensure your system meets the minimum specifications for running a node\\ \ *2. Network Architecture Understanding* ○ Read the technical documentation on the BlockDAG website \ ○ Understand the difference between BlockDAG and traditional blockchain \ ○ Familiarize yourself with key concepts like parallel block processing\\ \ *3. Join the Community* ○ Connect with other node operators through Discord \ ○ Introduce yourself and your intentions for running a node \ ○ Subscribe to announcement channels to stay updated\\ \ **Phase 2: Environment Setup** 1. *Operating System Preparation* ○ BlockDAG currently supports major Linux distributions \ ○ Ensure your system is updated and secured \ ○ Install prerequisite packages as listed in the GitHub documentation\\ \ *2. Network Configuration* ○ Set up proper firewall rules as specified in documentation \ ○ Ensure your internet connection is stable and meets bandwidth requirements \ ○ Configure port forwarding if running behind NAT\\ \ *3. Storage Preparation* ○ Allocate sufficient disk space according to specifications \ ○ Consider using SSDs for better performance \ ○ Plan for future growth of the blockchain data\\ \ **Phase 3: Node Installation** 1. *Repository Access* Clone the BlockDAG scripts repository: \ git clone \\ \ ○ Navigate to the appropriate directory based on documentation\\ \ *2. Configuration Files* ○ Locate the example configuration files in the repository \ ○ Customize them according to your environment \ ○ Pay special attention to network connection parameters\\ \ *3. Node Software Installation* ○ Follow the installation instructions in the repository's documentation \ ○ Verify installation success through the provided verification methods \ ○ Become familiar with the control commands and interfaces\\ \ **Phase 4: Node Operation**
1. *Initial Synchronization* ○ Start your node following the documented procedures \ ○ Monitor the synchronization process using the provided tools \ ○ Be patient as initial sync may take significant time\\ \ *2. Node Monitoring* ○ Set up logging and monitoring as recommended \ ○ Learn to interpret node status indicators \ ○ Implement alerts for potential issues\\ \ *3. Troubleshooting Common Issues* ○ Reference the FAQ section in documentation \ ○ Search Discord for similar issues others have encountered \ ○ Follow the prescribed troubleshooting steps\\ \ **Phase 5: Active Participation** 1. *Network Contribution* ○ Understand how your node contributes to network security \ ○ Learn about the block validation process \ ○ Monitor your node's performance metrics\\ \ *2. Community Engagement* ○ Share your experience with other operators \ ○ Report issues and suggest improvements \ ○ Participate in network upgrade discussions\\ \ *3. Ongoing Maintenance* ○ Keep your node updated with latest releases \ ○ Perform regular system maintenance \ ○ Back up critical configuration files\\ \ **RESOURCE NAVIGATION TIPS** \ **GitHub Repository Structure**\\ \ The BlockDAG scripts repository at is organized into several key sections: 1. **README.md:** Start here for an overview and basic instructions 2. **Installation Scripts:** Contains automation for node setup 3. **Configuration Examples:** Reference configurations for different environments 4. **Utility Scripts:** Tools for monitoring and maintenance *When navigating this repository:* \ ● Check the commit dates to ensure you're looking at recent information \ ● Review both code and documentation comments for insights \ ● Pay attention to version-specific instructions\\ \ **Documentation Approach** \ The documentation across resources follows a progressive disclosure model: 1. Conceptual Understanding: Introduction to the BlockDAG architecture 2. Technical Requirements: Hardware, software, and network specifications 3. Installation Procedures: Step-by-step setup instructions 4. Operational Guidelines: Day-to-day operation and maintenance Navigate the documentation in this order to build a comprehensive understanding before diving into technical implementation. \ **POTENTIAL CHALLENGES AND SOLUTIONS** \ ● Resource Location: Check the GitHub README for synchronization expectations \ ● Approach: Follow recommended optimization settings for faster sync \ ● Community Support: Ask in Discord about current sync times and tips \ **Challenge: Network Connectivity** \ ● Resource Location: Network configuration section in documentation \ ● Approach: Verify port configurations and network settings \ ● Community Support: Share connection logs for troubleshooting assistance \ **Challenge: Software Updates** \ ● Resource Location: Announcements channel in Discord and GitHub releases \ ● Approach: Subscribe to notifications and follow the update procedures \ ● Community Support: Discuss update experiences with other operators \ **CONCLUSION**
Running a node on the BlockDAG Primordial testnet represents an opportunity to participate in cutting-edge blockchain technology development. This guide has provided a roadmap to help you navigate the available resources effectively. \ Remember that as a testnet participant, you're not just operating a node but contributing to the development of the BlockDAG ecosystem. Your feedback, issues, and suggestions help shape the future of this technology. \ For specific technical instructions, always refer to the official GitHub repository and documentation, as procedures may change as the testnet evolves. \ Welcome to the BlockDAG community, and thank you for your participation in building the future of decentralized technology! # ASIC Mining Setup Guide: From Unboxing to Mining **INTRODUCTION**
Welcome to the world of ASIC mining. This guide will walk you through the process of setting up an ASIC miner for cryptocurrency mining, covering both solo and pool mining configurations. While this guide provides general ASIC setup principles applicable to most devices, we've included specific considerations for the upcoming BlockDAG network ASICs. \ ASIC (Application-Specific Integrated Circuit) miners are specialized devices designed for maximum efficiency when mining specific cryptocurrency algorithms. Unlike general-purpose computers or GPUs, ASICs are built to do one thing exceptionally well: generate hashing power for a particular mining algorithm. \ *Before You Begin: Essential Preparations* \ **ENVIRONMENT ASSESSMENT** \ *Before your ASIC arrives, prepare an appropriate environment:* \ ● Location: Choose a well-ventilated space, ideally separate from living areas due to noise and heat \ ● Temperature: Ambient temperature should remain below 80°F (27°C) \ ● Airflow: Ensure good air circulation with intake and exhaust options \ ● Noise considerations: ASICs typically generate 70-90 decibels of noise (similar to a vacuum cleaner) \ ● Dust: Minimize dust exposure as it can affect cooling efficiency \ **ELECTRICAL REQUIREMENTS** \ *ASICs have substantial power demands that require proper planning:* \ ● Circuit capacity: Verify your electrical panel can handle the amperage (typically 15-20A per device) \ ● Outlet type: Most ASICs require 220-240V outlets for optimal efficiency \ ● Power quality: Consider using power conditioners or UPS systems to protect from surges \ ● PDU (Power Distribution Unit): Recommended for managing multiple devices \ ● Electricity costs: Calculate your cost per kilowatt-hour to estimate operating expenses
For context, modern ASICs typically consume between 1,500-3,500 watts of electricity continuously. When BlockDAG ASICs launch, their power specifications will be provided to help you prepare accordingly. \ **NETWORK INFRASTRUCTURE** \ *Reliable connectivity is essential for mining operations*: \ ● Internet connection: Stable, always-on broadband connection \ ● Ethernet cables: Use Cat5e or Cat6 cables rather than Wi-Fi \ ● Router configuration: Know how to access your router settings for port forwarding \ ● Static IP: Consider setting up a static IP for your miner \ **TOOLS AND ACCESSORIES** \ *Have these items ready before unboxing your ASIC:* \ ● Screwdriver set: For any assembly or maintenance \ ● Ethernet cables: For connecting to your network \ ● Power cables: Compatible with your outlets and the ASIC's requirements \ ● Compressed air: For periodic dust removal \ ● Thermal paste: For maintenance of cooling components \ ● Digital thermometer: To monitor ambient temperature \ ● Decibel meter app: To assess noise levels \ ● Kill-A-Watt meter: To measure actual power consumption \ **UNBOXING AND INITIAL SETUP**
**Hardware Inspection** \ *When your ASIC arrives:* 1. Carefully unpack and inspect for any shipping damage 2. Verify all components are included according to the manufacturer's checklist 3. Check for loose connections or components 4. Remove any shipping materials or protective coverings 5. Photograph the device and serial numbers for your records
**PHYSICAL INSTALLATION** \ *Proper physical setup helps ensure longevity*: 1. Place on a stable, non-flammable surface 2. Allow at least 6 inches (15cm) clearance on all sides for airflow 3. Position intake fans to draw in cooler air 4. Ensure exhaust air has a clear path out of your space 5. Consider rubber feet or vibration dampeners to reduce noise transmission 6. For multiple ASICs, arrange in rows with coordinated airflow directions
**INITIAL POWERUP** \ *The first power-up should be done methodically:* 1. Connect the Ethernet cable from your router to the ASIC 2. Verify the power switch is in the OFF position 3. Connect the power cable to the ASIC first, then to the outlet 4. Power on and listen for the cooling fans to start 5. Watch for indicator lights showing proper operation 6. Allow 3-5 minutes for the system to fully initialize
**NETWORK CONFIGURATION**
**Finding Your ASIC on the Network** \ *Most ASICs use one of these methods to establish initial connection:* 1. **Automatic IP assignment:** The ASIC receives an IP address from your router via DHCP 2. **Default static IP:** Some ASICs use a preconfigured IP address (check manufacturer documentation) 3. **Device scanning app:** Manufacturers often provide tools to locate your device on the network \ *To find your ASIC's IP address:* 1. Log into your router's admin panel 2. Look for "Connected Devices" or "DHCP Clients List" 3. Identify your ASIC by its MAC address (printed on the device) 4. Note the assigned IP address
Alternatively, use an IP scanner tool like Advanced IP Scanner (Windows) or Angry IP Scanner (cross-platform) to scan your network for connected devices. \ **ACCESSING THE CONTROL INTERFACE** \ *Most ASICs provide a web-based control panel:* 1. Open a web browser on a computer connected to the same network 2. Enter the ASIC's IP address in the address bar 3. You'll typically be prompted for login credentials \ ○ Default usernames and passwords are usually available in the manufacturer's documentation \ ○ Common defaults include admin/admin, admin/password, or root/root 4. **IMPORTANT:** Change the default password immediately after first login \ Basic Configuration Once logged in, configure these essential settings: 1. **System settings:** ○ Set a strong admin password \ ○ Configure time zone settings \ ○ Set up email notifications for critical alerts \ ○ Update the firmware to the latest stable version\\ \ **2. Network settings:** ○ Consider assigning a static IP to prevent address changes \ ○ Configure DNS servers (you can use 1.1.1.1 and 8.8.8.8 as reliable options) \ ○ Set up NTP (Network Time Protocol) for accurate timekeeping \ **3. Temperature and fan controls**: ○ Review default temperature thresholds \ ○ Configure fan speed settings (automatic adjustment recommended) \ ○ Set up automatic shutdown triggers if temperatures exceed safe levels \ **CHOOSING YOUR MINING METHOD : Solo vs. Pool** \ **Solo Mining Configuration** \ *Solo mining means attempting to find and validate blocks independently, receiving full block rewards when successful:* \ **Advantages:** \ ● Full block rewards (no shared rewards or fees) \ ● Complete control over mining operations \ ● Privacy (no need to share information with pools) \ **Disadvantages:** \ ● Highly unpredictable income \ ● May go months without finding a block \ ● Only practical with substantial hashing power **When to consider solo mining:** \ ● You have significant mining power (multiple high-performance ASICs) \ ● You're mining a newer cryptocurrency with lower difficulty \ ● You're comfortable with income volatility \ ● You prioritize privacy and independence \ Solo mining configuration steps: 1. **Run a full node:** ○ Install the blockchain's full node software on a separate computer \ ○ Allow the blockchain to fully synchronize (may take days) \ ○ Configure the node to accept mining connections \ ○ Set up wallet addresses to receive rewards \ **2. Configure your ASIC for solo mining:** ○ In your ASIC's control panel, find mining settings \ ○ Select "Solo Mining" mode \ ○ Enter your full node's IP address and port \ ○ Input your wallet address for receiving rewards \ ○ Save settings and restart mining \ For BlockDAG specifically, solo mining will require running the BlockDAG node software and connecting your ASIC to this node once available. The BlockDAG node software can be found at . \ **POOL MINING CONFIGURATION** \ *Pool mining combines your hashing power with other miners, sharing rewards proportionally:* \ **Advantages:** \ ● Steady, predictable income \ ● Lower variance in rewards \ ● Suitable for miners with any amount of hashing power \ ● No need to run a full node \ **Disadvantages:** \ ● Pool fees reduce earnings (typically 1-3%) \ ● Less control over mining operations \ ● Potential security risks if choosing untrustworthy pools \ **When to consider pool mining:** \ ● You have limited mining power (one or few ASICs) \ ● You prefer steady, predictable income \ ● You want simpler setup without running a full node \ ● You're new to mining \ Pool mining configuration steps: 1. **Select a mining pool:** ○ Research reliable pools supporting your cryptocurrency \ ○ Compare fee structures and payout methods \ ○ Check server locations (closer servers reduce latency) \ ○ Review minimum payout thresholds \ ○ Assess pool history and reputation \ **2. Register with the pool:** ○ Create an account on the pool's website \ ○ Set up two-factor authentication if available \ ○ Configure payout settings and wallet addresses \ ○ Generate worker names for your devices \ **3. Configure your ASIC for pool mining:** ○ In your ASIC's control panel, find mining settings \ ○ Select "Pool Mining" mode \ ○ Enter the pool's stratum address and port \ ○ Input your username (usually wallet.workername) or as specified by pool \ ○ Enter your worker password if required \ ○ Save settings and restart mining \ For BlockDAG, specific mining pools will emerge once the network launches. The BlockDAG team will provide information about compatible pools through their official channels at . \ **OPTIMIZING PERFORMANCE AND EFFICIENCY** \ **Hash rate Optimization** \ *Finding the sweet spot between performance and efficiency:* 1. Factory settings: Begin with manufacturer defaults to establish baseline performance 2. Overclocking: Cautiously increase clock speeds in small increments while monitoring: \ ○ Temperature stability \ ○ Rejection rate (should remain below 1%) \ ○ Overall efficiency (hash rate per watt) 3. Underclocking: Sometimes reducing power slightly improves efficiency with minimal hash rate impact 4. Firmware options: Some ASICs support custom firmware that can improve efficiency
Remember that optimal settings vary based on your specific ASIC model, ambient conditions, and electricity costs. Document changes and their effects to find your optimal configuration. \ **Cooling Optimization** 1. Effective cooling directly impacts longevity and performance: 2. Intake air quality: Consider using air filters if your environment is dusty 3. Exhaust management: Direct hot air outside when possible 4. Supplemental cooling: Additional fans can improve air circulation 5. Immersion cooling: Advanced option using mineral oil for significant noise reduction and cooling improvement 6. Seasonal adjustments: Be prepared to modify settings based on seasonal temperature changes \ **Power Efficiency** \ *Maximizing return on electricity costs*: 1. Power supply quality: Higher efficiency power supplies reduce waste heat and electricity consumption 2. Off-peak mining: Consider power scheduling during lower-cost electricity hours 3. Efficiency mode: Some ASICs offer efficiency modes that optimize hashrate-to-power ratios 4. Power monitoring: Track actual consumption against expected specifications 5. Solar integration: For advanced setups, solar power can offset mining electricity costs
**MONITORING AND MAINTENANCE** \ **Daily Monitoring** \ *Establish a routine to check these metrics daily:* 1. Hashrate: Verify performance meets expectations 2. Temperature: Ensure operating within safe ranges 3. Rejection rate: Should remain below 1% 4. Fan speeds: Monitor for changes that might indicate problems 5. Earnings: Track actual vs. expected returns \ Many miners use mobile apps or set up notifications to alert them of any issues requiring attention.
**Regular Maintenance** \ Preventative maintenance extends ASIC lifespan: 1. **Weekly:** Visual inspection of cables and connections 2. **Monthly:** Compressed air cleaning of dust from heat sinks and fans 3. **Quarterly:** Deep cleaning and thermal paste replacement if needed 4. **Bi-annually:** Check power supply connections for corrosion or overheating
T**ROUBLESHOOTING COMMON ISSUES**
*Prepare for these common scenarios:* 1. **Hash rate drops:** ○ Check internet connectivity \ ○ Verify pool status \ ○ Monitor operating temperature \ ○ Inspect for hardware errors in logs \ **2. Connection instability:** ○ Test network cables \ ○ Check router settings \ ○ Verify DNS configuration \ ○ Consider static IP assignment \ **3. Overheating:** ○ Clean dust from intake and exhaust \ ○ Check ambient temperature \ ○ Verify all fans are operating \ ○ Consider additional cooling solutions \ **4. Excessive noise:** ○ Inspect for fan imbalance \ ○ Check for loose components \ ○ Consider noise dampening options \ ○ Verify proper firmware for fan control \ **SECURITY CONSIDERATIONS** \ **Physical Security** \ *Protect your investment with these measure*s: 1. Location security: Limited access area, preferably locked 2. Video monitoring: Consider simple surveillance 3. Environmental monitoring: Temperature and humidity alerts 4. Fire safety: Appropriate extinguishers rated for electrical fires 5. Insurance: Verify coverage for mining equipment
**Network Security** \ *Protect against remote threats:* 1. Separate VLAN: Isolate mining equipment from your primary network 2. Strong passwords: Use unique, complex passwords 3. Firmware updates: Keep ASIC firmware updated 4. Two-factor authentication: Enable for all accounts 5. VPN access: Consider for remote management \ **Operational Security** \ *Protect your mining identity and assets:* 1. Wallet security: Use hardware wallets for storing mined coins 2. Regular transfers: Move mining rewards to secure storage regularly 3. Privacy practices: Consider separating mining identity from personal identity 4. Documentation: Maintain secure records of serial numbers and configurations
**BlockDAG-Specific Considerations** \ *As you prepare for BlockDAG ASIC availability, keep these points in mind*: 1. **Network architecture:** BlockDAG's parallel processing design may influence optimal mining strategies 2. **Node requirements:** Familiarize yourself with the node software through the testnet 3. **Community resources:** Join the BlockDAG community to stay informed about mining developments 4. **Mining pools:** Watch for announcements about BlockDAG-compatible mining pools 5. **Hardware specifications:** Review power and cooling requirements when announced
The BlockDAG testnet provides an opportunity to understand the network architecture before committing to ASIC hardware. Explore the testnet resources at to build familiarity with the system. \ **CONCLUSION**
Setting up an ASIC miner requires thoughtful preparation and ongoing management, but can be a rewarding endeavor for those willing to invest the time and resources. Whether you choose solo or pool mining, the fundamentals of proper setup, cooling, and maintenance remain essential to success. \ As BlockDAG progresses toward mainnet launch with ASIC support, the knowledge gained from general ASIC operation will transfer directly to BlockDAG mining. By establishing good practices now, you'll be well-positioned to participate effectively when BlockDAG ASICs become available. \ Remember that mining is both an investment and a learning process. Start conservatively, document your experiences, engage with mining communities, and expand your operation methodically as you gain confidence and expertise. # Introduction to Crypto Mining Crypto mining is a process used by blockchain networks to finalize transactions, add new coins to circulation, and secure the network. It involves using specialized computers (nodes) to solve complex mathematical problems, which validates transactions and adds them to the blockchain, a public ledger. Miners are rewarded with cryptocurrency for their work. Here's a more detailed breakdown: · **Validation and Ledger:** Crypto mining validates transactions and adds them to the blockchain, ensuring the accuracy of the shared records and preventing double-spending of digital currency. · **Proof of Work:** Miners use computational power to solve complex mathematical problems, a process known as "proof of work". The first miner to solve the puzzle is rewarded with new cryptocurrency. · **Security:** Mining helps maintain the security of the cryptocurrency network by validating transactions and adding them to the blockchain. · **Decentralized:** The mining process is decentralized, meaning that any individual can participate in mining with their computers. · **Energy Consumption:** Crypto mining is a highly energy-intensive process, which has been criticized for its environmental impact. · **Mining Pools:** Miners can pool their resources (computing power) to increase their chances of solving a block and earning rewards. # BlockDAG Consensus ## BlockDAG Consensus #### 1. What is Consensus? * The process of reaching agreement in a decentralized network. * Ensures validity and security of transactions on the blockchain. * Prevents double-spending and attempts to alter the block records. #### 2. What is DAG? A Directed Acyclic Graph (DAG) is a particular data structure connecting various information elements. magine a DAG protocol as a sequence of nodes and edges connecting them. The edges are unidirectional, implying that information cannot move in opposite directions. Any information in the DAG cannot move back to its source if we follow the graph’s direction. BlockDAG is an instance of a distributed ledger technology that uses DAGs to create an asynchronous Byzantine Fault-Tolerant consensus.
#### 3. How BlockDAG Achieves Consensus A DAG (Directed Acyclic Graph) based weighted voting mechanism on the BlockDAG blockchain leverages the graph structure of a DAG to facilitate consensus and improve performance by assigning weights to nodes or transactions. Instead of traditional block-based voting, DAG-based consensus allows nodes to vote on transactions, and these votes are recorded as edges in the DAG. Here's a breakdown of how this mechanism works: **4. DAG STRUCTURE AND CONSENSUS:** · **DAG as a Ledger:** Instead of a linear chain of blocks, a DAG represents the transaction history as a graph where transactions are nodes and dependencies (e.g., a transaction referencing a previous one) are edges. · **Asynchronous Consensus:** DAG-based consensus relies on asynchronous voting, meaning nodes don't wait for all other nodes to agree before confirming a transaction. · **No Need for a Leader:** In some DAG-based consensus mechanisms, there's no single leader node. Instead, nodes interact and agree on the order of transactions. 5. **WEIGHTED VOTING:** · **Assigning Weights:** Nodes or transactions can be assigned weights based on various factors, such as the amount of stake a node holds, their reputation, or the latency they experience with other nodes. · **Impact on Consensus:** Nodes with higher weights may have a greater influence on the outcome of voting or the selection of a transaction. · **Optimizing Performance:** Weighted voting can improve consensus latency (time to finalize a transaction) and throughput (number of transactions processed per second). **6. ADVANTAGES OF DAG-BASED WEIGHTED VOTING:** · **Increased Scalability:** DAGs can offer higher transaction throughput and lower consensus latency than traditional blockchain approaches. · **Reduced Latency:** By allowing asynchronous consensus and potentially using weighted voting, DAGs can achieve faster transaction finality. · **Improved Security:** The distributed and decentralized nature of DAGs can enhance security and resilience against attacks. · **More Flexible and Adaptive:** Weighted voting mechanisms can be adapted to different use cases and network conditions.