# Welcome ENI is an enterprise-grade, ultra-high performance modular L1 featuring infinite TPS, built specifically for mass commercial adoption. At its core, the ENI Matrix architecture (Mainnet + Hub + AppChain) works in tandem with a proprietary Hyper-ordered Parallel Engine to enable global-scale parallel execution and real-time on-chain settlement. As a Quantum-Computing-Grade L1, ENI decouples business logic from regulatory requirements, empowering enterprises to deploy custom AppChains under a unified governance framework. Beyond the protocol, ENI serves as the "Chief Architect" for enterprise on-chain migration. We provide a full-stack suite of strategic consulting, custom development, regulatory compliance, and business expansion services, ensuring a frictionless transition for real-world assets and operations to move on-chain. ENI is a decentralized blockchain infrastructure. The ENI Foundation is solely responsible for the development, maintenance, and technical support of the underlying ENI public blockchain, and is committed to providing developers with a secure, stable, and open decentralized blockchain development environment. Developers and their respective communities are solely responsible for any products or services independently developed or deployed on the ENI public blockchain, as well as all related activities. ### Jump right in
Getting StartedConnecting to the ENI network/pages/psz849Jrl9znhBqC1Mhj/pages/CyH2xJQs9yWJ1S8BYNav
DevelopSmart Contracts and Deployment/pages/fuTxyTRiW08Bnd8IYQYY/pages/7aUFmnCMx9m4smGncsXL
NodeOperation Node, CLI, enid/pages/qd4vO4l2sUJlSiOrWYmV/pages/JjjojIyKxaiBPzzLwvtg
# About ENI ENI is an enterprise-grade, ultra-high performance modular L1 featuring infinite TPS, built specifically for mass commercial adoption. At its core, the ENI Matrix architecture (Mainnet + Hub + AppChain) works in tandem with a proprietary Hyper-ordered Parallel Engine to enable global-scale parallel execution and real-time on-chain settlement. As a Quantum-Computing-Grade L1, ENI decouples business logic from regulatory requirements, empowering enterprises to deploy custom AppChains under a unified governance framework. Beyond the protocol, ENI serves as the "Chief Architect" for enterprise on-chain migration. We provide a full-stack suite of strategic consulting, custom development, regulatory compliance, and business expansion services, ensuring a frictionless transition for real-world assets and operations to move on-chain. ## What is EVM? The **Ethereum Virtual Machine (EVM)** is used to process transactions on blockchains like Ethereum. Most crypto-native developers are very familiar with EVM. Unfortunately, the EVM has relatively low efficiency — on **Ethereum Layer 1 (L1)**, it cannot handle more than about **20 transactions per second (TPS)**. This leads to: * **High transaction fees** for users, with simple transactions often costing **hundreds of dollars**. * **Limited design space** for developers, making it difficult to build **high-performance applications**. ## What is Parallelization? **Parallelization** allows you to process multiple tasks simultaneously (i.e., parallel processing). In software engineering, this technique is commonly used to leverage modern hardware with multiple cores to handle several workflows at the same time. For ENI, parallelization is used to process **multiple independent transactions** simultaneously. ## **What Optimizations Did** ENI **Introduce?** ENI introduced **four major innovations** to enhance performance and scalability: * **Dual-Turbo Consensus:**This feature enables ENI to achieve the **fastest finality time** of any blockchain — only **400 milliseconds**, unlocking a **Web2-like experience** for applications. * **Optimistic Parallelization:**This feature allows developers to **unlock parallel processing** for their **Ethereum applications** **without any additional work**. * **Efficient Database:**This major upgrade enables ENI to handle **higher data storage, read, and write rates**, which is **crucial for high-performance blockchains**. * **Interoperable EVM:**This allows existing **Ethereum ecosystem developers** to deploy their **applications, tools, and infrastructure** to ENI **without any modifications**, while enjoying a **100x performance improvement** provided by ENI. All these features together **unlock a new, scalable design space** for the **Ethereum ecosystem**. ## ENI **Performance Metrics** Through these optimizations, ENI can achieve: * **1-second finality time**. * **10,000 transactions per second** (**theoretical maximum of 12,500 TPS**). *** ## **What Are the Advantages of** ENI**?** * **100x improvement** over traditional **EVM**. * Unlocks a **new design space** for application developers. * **Significantly reduces costs** for everyday users to access EVM. # Quickstart #### Creating a Wallet and Signing Transactions *** ## **Install a Wallet App** To access full functionality, it is recommended to use one of the wallets listed on the **wallet page**, such as: * **MetaMask Wallet** * **Gate** * **TokenPocket** * **Trust Wallet** * **Bitget Wallet** * **OKX Wallet** **Note:**\ It is **not recommended** to manually import wallets between **EVM-only** wallet apps and **Cosmos-based** wallet apps using a **mnemonic phrase**. Doing so may generate unexpected wallet addresses due to differences in the coin types. *** ## **Add the** ENI **Network to MetaMask** * Adding the ENI chain to MetaMask takes just a few clicks. * Use the button provided to connect your wallet and import the network settings. *** **Manual Import** If **automatic connection** fails, you can **manually add** the ENI EVM network by following these steps: **ENI Mainnet** * **Network Name:** `ENI Mainnet` * **RPC URL:** [`https://rpc.eniac.network`](https://rpc.eniac.network/) / [`wss://rpc.eniac.network/ws/`](wss://rpc.eniac.network/ws/) * **EVM Chain ID:** `173` * **Currency Symbol:** `EGAS` * **Block Explorer URL:** [`https://scan.eniac.network/`](https://scan.eniac.network/)
**ENI Testnet** * **Network Name:** `ENI Testnet` * **RPC URL:** [`https://rpc-testnet.eniac.network`](https://rpc-testnet.eniac.network) / [`wss://rpc-testnet.eniac.network/ws/`](wss://rpc-testnet.eniac.network/ws/) * **EVM Chain ID:** `174` * **Currency Symbol:** `EGAS` * **Block Explorer URL:** [`https://scan-testnet.eniac.network/`](https://scan-testnet.eniac.network/) *** ## Get ENI Testnet Token ENI is the native utility token of the ENI Chain, primarily used to pay transaction fees on the network. You can obtain test ENI tokens from a faucet specifically designed for the ENI testnet. [ENI Testnet Faucet](https://faucet-testnet.eniac.network/) *** ## **Advanced: Wallet Addresses** Since ENI now supports **two types of wallet addresses**, it is essential to understand their relationship. * Every account on ENI has a **unique public key**. * This public key can generate **multiple wallet addresses**, which look different but **function the same**. * Depending on the application, these addresses might be **interchangeable**. **Analogy:**\ The difference is like the difference between the **number "2"** and the **word "two"**. They both define the same value but might be used in **different contexts**. *** ## **Types of Addresses** 1. **"hex" Address:** * Starts with **0x**. * Used for **EVM-based** transactions. 2. **"bech32" Address:** * Starts with **"eni"**. * Used for ENI**-native** functionalities. **Key Insight:** * Although these addresses look different, they **share the same underlying account**. * This means any action performed with one address **affects the other** as well. **Example:**\ If you **deposit funds** to your **EVM address**, you can access those funds using your **ENI address**, and vice versa. This setup ensures **seamless integration** between the **EVM and ENI ecosystems**. *** #### **Linking EVM and ENI Addresses** To link your **EVM and ENI addresses**, initiate a transaction **from your EVM address**. * For example, you can send tokens **to yourself** within your wallet. *** ## **Types of Transactions** **"Ethereum" Transactions** * **Signing EVM transactions** is straightforward. * When an application initiates a transaction, MetaMask will **prompt you to sign**, requesting your approval to proceed. *** **"ENI-native" Transactions** * The user experience for signing **ENI-native transactions** is almost the same. * **Under the hood:** * The process is similar to signing EVM transactions. * The difference is that the **transaction target** is an **ENI precompiled contract**. * Your approval via MetaMask **executes the transaction**. **Note for Smart Contract Developers:** * Ensure that the **MetaMask transaction target** is set to a **precompiled contract** on ENI. *** ## **Viewing Tokens** **ERC20 Tokens** * The process of viewing **ERC20 tokens** in MetaMask is the **same as on other EVM chains**. * For tokens that are **not listed automatically**, you will need to **manually import** them into your wallet. *** **ERC721 NFTs** * To view **NFTs (ERC721)** in MetaMask, you need to **manually add them**. # Chain Setup ## Chain ENI utilizes multiple chains for various stages of the development lifecycle. This multi-chain approach allows developers to build, deploy, manage, and iterate confidently, ensuring thorough testing and feedback before updates go live on the mainnet. > All **chain updates** are initially **deployed to the development network** to ensure **stability**. After successful testing on the development network, they are **migrated to the testnet** for **further testing and validation**. Finally, the updates are **released on the mainnet**. > > This process enables developers to **thoroughly test** their applications and **raise any concerns** about the upgrades **before they go live**. ## Mainnet The **Chain 173** chain is the mainnet of the ENI blockchain. It is the live, production environment where actual transactions and smart contract deployments occur. This chain is used for all real-world applications and activities. * **Purpose**: Production * **Chain ID**: `173` * **EVM Chain ID**: `173AA`
## Testnet **Chain 174** is the **testnet** for the ENI **blockchain**. It is used for **testing and development purposes**. Developers can **deploy and test** their **dApps and smart contracts** in a **controlled environment** that **simulates mainnet conditions**. This network is **crucial for ensuring** that applications **function as expected** before they go live on the mainnet. * **Purpose**: Staging * **Chain ID**: `174` * **EVM Chain ID**: `174AA` ## Devnet **Chain 174** is the **development network** for the ENI **blockchain**. It serves as an **early-stage testing and experimentation** environment. This network is typically used by developers to **test new features**, conduct **integration tests**, and **develop prototypes** in an **isolated environment**. * **Purpose**: Testing * **Chain ID**: `175` * **EVM Chain ID**: `175AA` ## Local Chains Developers can also run local chains on their machines for testing and development purposes. Local chains are isolated environments that mimic the behavior of the mainnet, testnet, or devnet chains. They are useful for testing new features, debugging issues, and experimenting with smart contracts with full control over all tokens and governance decisions. * **Purpose**: Development * **Chain ID**: Set by user (default: eni-1) ### Chain Registry The [ENI Chain Registry](https://github.com/eni-chain/chain-registry)  contains additional information about each chain. # Account Structure On ENI, accounts are represented by two address formats: * ENI **native Bech32** (`eni...`) * **EVM-compatible Hex** (`0x...`) Both addresses for a single account are derived from the same **public key**.Because eni is fully compatible with Ethereum and the Ethereum ecosystem is prosperous, it is recommended to use an eth address. *** #### Deriving Addresses from Public Key **ENI Address Derivation** **ENI native addresses** are derived from the **public key** using the following steps: 1. Hash the public key using the `Keccak256` algorithm. 2. Extract the **first 20 bytes** of the resulting hash. 3. Encode the extracted bytes in **Bech32 format** with the **"eni" prefix.** Example implementation: ```ts import { bech32 } from 'bech32'; import { keccak256 } from 'ethereumjs-util'; export function deriveEniAddress(publicKey: Buffer): string { const hash = keccak256(publicKey); const words = bech32.toWords(hash.slice(0, 20)); return bech32.encode('eni', words); } ``` #### **EVM Address Derivation** The EVM-compatible address is derived as follows: 1. Hash the public key using the `Keccak256` algorithm. 2. Extract the **last 20 bytes** of the resulting hash. 3. Prefix the extracted bytes with `0x` to obtain the EVM address. Example implementation: ```ts import { keccak256 } from 'ethereumjs-util'; export function deriveEVMAddress(publicKey: Buffer): string { const hash = keccak256(publicKey); return `0x${hash.slice(-20).toString('hex')}`; } ``` #### **Summary** * **Public Key Hash**：Both address derivations rely on the **Keccak256 hashing algorithm**. * **ENI Address**： * Extracts the **first 20 bytes** of the hash. * Encodes these bytes into **Bech32 format** with the **"eni" prefix**. * **EVM Address**： * Extracts the **last 20 bytes** of the hash. * Formats these bytes as **Hex** with the **"0x" prefix**. #### **Why This Works** `Keccak256` **hashing** ensures that the process of deriving both address formats from the same public key is **consistent and verifiable**. This mechanism enables a **single account** to remain **compatible** in both **ENI native** and **EVM environments**. *** #### **Next Steps** For a detailed technical explanation on how to perform **account linking**, please refer to the **Wallet Linking** section. # Token Standards ## Token Standards In this section, we will dive deep into the various token standards supported by ENI. Understanding these standards is crucial for developers as they form the foundation of many decentralized applications. ENI supports four primary token types: * ENI Token * Smart Contract Tokens ### ENI **Token** The ENI token is the native token of the ENI blockchain, serving multiple roles within the ecosystem. * **Fee Token**: Used to pay transaction fees on the ENI network. * **Governance Token**: Used to participate in governance decisions that affect the network. **EVM** `1 ENI = 10**18 wei = 1000000000000000000 wei` `1 ENI = 10**9 wei = 1000000000 gwei` (giga-wei) ### **Fungible Tokens** Fungible tokens are digital assets that are interchangeable and lack unique characteristics. ENI supports both ERC20 and CW20 fungible token standards, allowing developers to choose between using the native TokenFactory or creating tokens via smart contract standards. #### Smart Contract Tokens * **ERC20**: The ERC20 standard defines a common set of rules for fungible tokens on EVM-based blockchains. These tokens can be transferred, approved, and queried using standard functions. * **Interoperability**: Both standards support pointer contracts, enabling seamless interaction between the native environment and the EVM environment. * **Recommended Use**: Suitable for applications requiring standard token interactions with existing dApps and maximum compatibility. ### **NFTs** Non-fungible tokens (NFTs) represent unique digital assets. ENI supports the ERC721 standard, along with its royalty counterpart (2981). * **ERC721**: The ERC721 standard defines the structure for non-fungible tokens on EVM-based blockchains. Each token is unique and cannot be exchanged on a one-to-one basis like fungible tokens. * **ERC2981**: This standard defines royalty mechanisms for NFTs, ensuring creators receive a percentage of sales. * **Interoperability**: Similar to fungible tokens, NFTs can interact across different standards via pointer contracts. * **Pointer Contract Registry**: A registry used to track pointer contracts specific to NFTs. # Gas **Gas** is the unit that measures the **computational workload** required to execute transactions or contracts on the **ENI network**. *** ## Key Terms and Concepts **Gas** Gas is a measure of the amount of work required to execute a transaction, and its value varies according to the complexity of the transaction being executed. *** **Gas Price** Gas Price refers to the amount of **$ENI** a user is willing to pay per unit of gas. Users can set the **gas price** to influence transaction fees. *** **Gas Limit** **Gas limit** is the maximum amount of gas a user wants to use for a transaction. If the gas limit is set too low, a node attempting to execute the transaction will run out of gas, fail to complete the transaction, and consume the entire specified gas limit. *** **Fees** **Fees = Gas Price \* Gas Limit**. * ```bash curl -H "Authorization: your-apikey-here" https://api.blocknative.com/gasprices/blockprices?chainid=$CHAIN_ID ``` *** **Maximum Gas** The maximum gas limit for transactions ensures that complex transactions do not consume excessive resources. You can query an RPC node using `/consensus_params` (i.e., ) to find the maximum gas limit for each chain. *** **Minimum Gas Price** ENI enforces a minimum gas price to prevent junk transactions. These prices are set by chain. *** **Maximum Byte Size** Each transaction has a maximum byte limit, defined by each chain. This limit can be retrieved by querying the `/consensus_params` endpoint of an RPC node. *** **Maximum Gas Limit for Queries** Since queries also consume gas, they have a maximum gas limit. This limit is specific to each RPC provider, so check with your provider to determine the maximum gas limit for your query. *** #### Sending Gas in Transactions When submitting a transaction for broadcast, the user needs to specify the gas price and the gas limit to determine the fee. *** **Using enid** When using enid, fees are set via the `--fees` flag, and gas limits and gas prices can be set via the `--gas` and `--gas-prices` flags, respectively. ```bash enid tx bank send --gas --gas-prices --fees ``` *** **Using CosmJS** In any CosmJS transaction, the gas fee must be specified using the `StdFee` object. ```js const fee = { amount: [{ denom: 'ueni', amount: '5000' }], gas: '200000' }; const result = await client.signAndBroadcast(address, [msg], fee, memo); ``` *** **Using EVM (wagmi)** ```js import { sendTransaction } from 'wagmi/actions'; sendTransaction({ request: { to: '0xRecipientAddress', value: '1000000000000000000', // 1 ENI gasPrice: '100000000000', // 100 Gwei gasLimit: '21000' } }); ``` *** ## Optimizing Gas Prices for Smart Contracts **Best Practices for Efficient Gas Usage:** * **Minimize storage operations:** Storage is expensive in terms of gas. * **Use fixed-size data structures:** They are more gas-efficient. * **Avoid unnecessary computations:** Streamline your smart contract logic. Optimizing gas usage ensures **lower costs** and **faster execution** for smart contracts on the ENI network. # Divergence from Ethereum Despite ENI's full EVM compatibility, there are still some differences between ENI's EVM and Ethereum's EVM. ## EVM Differences Unlike Ethereum's mainnet, which uses the Cancun version on the execution layer, ENI uses the Shanghai version of EVM. This means that ENI does not support features like blob transactions. ## Opcode Differences ### **PREVRANDAO** Since ENI does not rely on the same pseudo-randomness method as Ethereum's Proof of Stake (PoS) to determine the next validator, it does not have a RANDOM pseudo-random value that can be set as the return value for PREVRANDAO. In ENI, PREVRANDAO is set to return the hash of the current block time. For contract logic that requires strong guarantees of randomness, it is recommended to use externally verifiable oracles (as is also recommended on Ethereum). ### **COINBASE** The Coinbase address in ENI is always set to the EVM address of the global fee collector. ### **State Root** Since EN uses **IAVL trees** instead of **Merkle Patricia Tries (MPT)** for data storage, ENI does not have a state root for each account. The global state root is the root of the AVL tree, which is also different from Ethereum's overall state root (which is the MPT root). ### **Block Hash** The block hash on ENI is calculated based on the **Tendermint data format** of the block header, so it is different from Ethereum's block hash. ### **Base Fee and Tips** ENI supports all types of transactions. However, for traditional (non-EIP-1559) transactions, you must specify a **base fee of 1 gwei**. In addition, any "gas demand/gas limit" that exceeds the actual "gas used" may not be refunded in full or in part. ## Block Limits ENI's gas limit on the mainnet is 10M, while Ethereum's gas limit is 30M.\ Additionally, ENI has a 21MB byte size limit, whereas Ethereum does not have a byte-based limit. ## Finality ENI has instant finality, meaning that commitment levels such as "safe," "latest," "justified," and "finalized" on Ethereum are all the same on ENI. ## Pending State On Ethereum, the block proposer executes the proposed block first (updating its local state) before broadcasting the proposal to other nodes. This updated state remains pending until it is accepted by other nodes. However, on ENI, the block proposer broadcasts the proposal first, and it is only executed once accepted. Since each node executes the block almost simultaneously, ENI does not have a “pending state” window. # Transactions On the ENI blockchain, transactions are essential for any **state update**, including **Token transfers, Account linking, Smart contract execution.** While creating an account does not require a transaction, but **linking an account** to blockchain operations does. ## Transaction Types Since ENI supports both EVM and Cosmos SDK transactions, there are different transaction types based on the execution environment. The following sections provide an overview of Cosmos and EVM transactions on ENI. ### Cosmos Transactions Cosmos transactions are used for interacting with Cosmos based RPC’s and tooling. They consist of the body, auth info, and signatures #### Signing Cosmos Transactions Cosmos transactions on the ENI blockchain follow the standard Cosmos SDK format. They include various types of messages that can be included in the transaction body. Using the `enid` CLI, you can use the `--generate-only` flag to generate an unsigned transaction in JSON format. The transaction can then be signed and broadcasted to the network. Assuming you have an unsigned JSON transaction file, you can sign it using the `enid tx sign` command. The signed transaction will be in JSON format and can be broadcasted to the network. ``` enid tx sign unsigned_tx.json --chain-id $CHAIN_ID --keyring-backend test --from $SIGNER_ADDRESS ``` ### **EVM Transactions** The **ENI blockchain** supports **Ethereum Virtual Machine (EVM) transactions**, allowing compatibility with **Ethereum-based tools and smart contracts**. The structure of EVM transactions is **different** from that of **Cosmos transactions**. # Creating Transaction ## Creating Templates Transaction Messages/Data #### Using a Simple Flag: **--generate-only** Transaction templates form the foundation of blockchain development and automation in ENI. With the `--generate-only` flag and Foundry's `cast` tool, developers can create, analyze, and debug transactions in both native Cosmos and EVM environments. Understanding these tools unlocks powerful possibilities for building complex applications and development workflows. #### Native Transaction Templates The `--generate-only` flag transforms any ENI CLI transaction command into a template generator, creating a complete transaction structure without broadcasting it. These templates serve as building blocks for applications, frontends, and automation tools. **Basic Usage Pattern** The general pattern follows this structure: ```bash enid tx --from --generate-only ``` For example, a token transfer template: ```bash enid tx bank send \ $(enid keys show sender -a) \ $(enid keys show recipient -a) \ 1000000ueni \ --from sender \ --generate-only | jq ``` #### EVM Transaction Analysis ENI's EVM compatibility introduces additional complexity when handling transactions. Let’s explore how to generate and analyze EVM transactions using ENI’s native tools and Foundry’s `cast` command. **Generating an EVM Transaction Template** To generate an EVM transaction template, use the `evm` module with `--generate-only`. Here’s an example of registering an EVM pointer: ```bash enid tx evm register-evm-pointer NATIVE \ factory/eni1ep3f207kt7julz9tjwxp2x8kluj0y9l6u0fume/gptw \ --gas-fee-cap=100000000000 \ --gas-limit=2500000 \ --evm-rpc=https://rpc.eniac.network \ --from tf \ --generate-only ``` This command returns a transaction hash, which you can further analyze using Foundry’s `cast` tool. **Analyzing an EVM Transaction with Cast** Once you have the transaction hash, you can use Foundry’s `cast` command to inspect transaction details: ```bash cast tx 0x5010e6600e67f04a9bc3d3b670a7c2de380b180713d9a014a5dbd76b7e2190f1 \ --rpc-url=https://rpc.eniac.network ``` This provides detailed transaction information: ``` blockHash 0x4696d63a9a9ae88b03bcc94ccbd87f407e994b309d1dff9c0626de51ac57b76e blockNumber 130076639 from 0xAa55a16dD4E73c48C968928983c2bcC98d913d96 transactionIndex 7 effectiveGasPrice 100000000000 accessList [] chainId 173 gasLimit 2500000 hash 0x5010e6600e67f04a9bc3d3b670a7c2de380b180713d9a014a5dbd76b7e2190f1 input 0xc31d960f0000... maxFeePerGas 100000000000 maxPriorityFeePerGas 100000000000 nonce 3 r 0x92313277d1ffad9a18260303081671a2d40035016ac83740486dee916c964db7 s 0x158de03cac836b1fad26770274cffdb06b0809961811eb0b66aebfff95186417 to 0x000000000000000000000000000000000000100b type 2 value 0 yParity 1 ``` **Understanding EVM Transaction Components** Let’s break down the key components of an EVM transaction: * `input`: Encoded function call data * `maxFeePerGas`: Maximum total fee per unit of gas * `maxPriorityFeePerGas`: Maximum priority fee per unit of gas * `gasLimit`: Maximum gas allowed for the transaction * `to`: Target contract address * `type`: Transaction type (2 indicates an EIP-1559 transaction) #### Practical Applications **Development Workflow** When developing applications that interact with native and EVM functionality: ```javascript async function analyzeTransaction(txHash) { // First, get the native transaction details const nativeTx = await fetch(`${eniRestEndpoint}/cosmos/tx/v1beta1/txs/${txHash}`).then((res) => res.json()); // If it's an EVM transaction, get EVM details if (nativeTx.tx.body.messages[0]['@type'].includes('evm')) { const evmTx = await fetch(`${evmRpcEndpoint}`, { method: 'POST', body: JSON.stringify({ jsonrpc: '2.0', method: 'eth_getTransactionByHash', params: [txHash], id: 1 }) }).then((res) => res.json()); return { native: nativeTx, evm: evmTx }; } return { native: nativeTx }; } ``` **Template Generation for Different Transaction Types** Generate templates for various transaction types: ```bash # Native governance proposal enid tx gov submit-proposal param-change proposal.json \ --from validator \ --generate-only > native_template.json # EVM contract interaction enid tx evm send-tx \ --evm-rpc=https://rpc.eniac.network \ --gas-limit=2500000 \ --from=mykey \ --generate-only > evm_template.json ``` #### Best Practices **Transaction Analysis** When analyzing transactions: * Always validate both the native and EVM aspects of a transaction * Use `cast` to decode input data when dealing with EVM transactions * Track gas parameters on both layers * Monitor transaction status on both the native and EVM layers **Error Handling** Handle potential issues on both layers: ```javascript try { // Check native transaction status const nativeStatus = await checkNativeStatus(txHash); // If native succeeds but EVM fails, investigate the EVM layer if (nativeStatus.success) { const evmStatus = await checkEvmStatus(txHash); if (!evmStatus.success) { const evmError = await cast.call(['tx', txHash, '--rpc-url', evmRpcUrl]); console.error('EVM transaction failed:', evmError); } } } catch (error) { console.error('Transaction analysis failed:', error); } ``` **Security** * Keep private keys secure and never include them in templates * Use `.env` files or other environment variables whenever possible when dealing with hardcoded wallet keys or mnemonics # Precompiled contracts #### **Precompiled Contracts** **ENI precompiled contracts** are **smart contracts** that are **directly embedded** within the **ENI EVM environment**. They serve as **gateways** for users and developers to **access native ENI functionalities** through the **EVM RPC interface**. For instructions on **how to use EVM precompiled contracts**, please refer to the **Example Usage** section. # Governance Governance is a crucial aspect of blockchain, allowing delegators to participate in the decision-making process that shapes the future of the network. This section outlines the governance processes, how to vote, where to view votes, proposal timelines, voting options, and other important information. ### Overview Governance on the ENI blockchain allows delegators to propose, discuss, and vote on changes to the network. This decentralized approach ensures that the community has a say in important decisions, thereby maintaining the integrity of the network and aligning it with the interests of its participants. ### Proposal Timeline The governance process follows a structured timeline to ensure ample discussion and consideration of each proposal. 1. **Proposal Submission**: Any user can submit a proposal by paying a deposit. 2. **Deposit Period**: The community has a specific time to deposit funds for the proposal. If the minimum deposit threshold is reached, the proposal will enter the voting period. 3. **Voting Period**: After the deposit period ends, the proposal enters the voting period, during which voting takes place. 4. **Result Period**: After the voting period ends, the results are counted and the final outcome determined. ### Voting Options When a proposal enters the voting period, delegators have the following voting options: * **Yes**: Agree with the proposal. * **No**: Disagree with the proposal. * **No with Veto**: Strongly oppose the proposal and request the deposit to be burned. * **Abstain**: Choose not to vote in favor of or against the proposal while still participating in the governance process. ### Proposal Quorum To make a proposal valid, a certain quorum must be achieved, which is a minimum percentage of total staked tokens participating in the vote. ### Proposal Types Proposals can range from parameter changes, software upgrades, community spending proposals, to other governance-related matters. #### Proposals Anyone can create governance proposals on ENI. After garnering support and feedback from the community, the proposer drafts and submits the proposal along with the initial deposit. The most common types of proposals include: * `ParameterChangeProposal`: Used to change parameters defined in each module. * `CommunityPoolSpendProposal`: Used for spending funds from the community pool. * `TextProposal`: Used for addressing other matters, such as significant directional changes or any decisions that require manual implementation. #### Voting Process Community members use their staked ENI to vote. One staked ENI equals one vote. If users do not specify a vote, their vote will default to that of their staked validator. Validators will vote with their full stake unless directed otherwise by their delegators. Therefore, it is crucial for each delegator to vote according to their preferences. Below is a basic overview of the governance process: 1. **Proposal Submission**: Users submit a proposal, starting a two-day deposit period. 2. **Deposit Period**: Users deposit ENI as collateral to support the proposal. This period ends either after the two-day deposit period or when the minimum expedited deposit threshold of 7000 ENI is reached. The deposit is aimed at preventing spam proposals. If the minimum deposit of 3500 ENI is not met, all deposits will be burned, and the proposal will not proceed. 3. **Voting Period**: A five-day voting period begins. Voting options include: * `Yes`: Support. * `No`: Do not support. * `NoWithVeto`: Do not support, and the deposit should be burned. * `Abstain`: Abstain. Abstain votes count towards the quorum. 4. **Tallying Votes**: Votes are counted. A proposal passes if three conditions are met: * Achieve `Quorum`: At least 33.4% of all staked ENI must participate in the vote. * `NoWithVeto` votes must be less than 33.4% of the total vote. * Achieve `Threshold`: `Yes` votes must exceed the combined total of `No` and `NoWithVeto` votes. `Abstain` votes are not counted towards the `Threshold`. 5. **Result Period**: If the above conditions are not met, the proposal is rejected. 6. **Implementation**: Approved proposals will be executed. Once passed, changes described in the governance proposal will automatically come into effect. General proposals, such as approved `TextProposal`, must be reviewed and manually implemented by the ENI team and community. 7. **Deposit Refund/Burn**: Depending on the voting results, deposits will either be refunded or burned. #### Deposits The deposit mechanism is used to prevent unnecessary proposals and spam. Users can veto any proposals they consider spam by voting `NoWithVeto`. If a proposal fails to reach the minimum deposit amount during the deposit period, it will not enter the voting period, and the deposit will be burned. Proposals that meet the minimum deposit requirement and enter the voting period will have their deposits refunded for any result other than `NoWithVeto`. If `NoWithVeto` votes exceed 33.4% of the total votes, the deposit will be burned. In other cases, the deposit will be refunded. ### Additional Information The governance mechanism of the ENI blockchain empowers the community to actively participate in the development and evolution of the network. By understanding the governance processes and participating in voting, token holders can influence the direction of the network, ensuring it aligns with the community's vision and values. *** #### Frequently Asked Questions **What happens if my proposal is rejected?** If your proposal is rejected and does not meet the minimum deposit threshold, the deposit will be burned. Otherwise, the deposit will be refunded to the proposer. **Can I change my vote during the voting period?** No, once you cast your vote, it is final and cannot be changed. # Proposals ## Creating a New Proposal Anyone can create a governance proposal, which will begin with a deposit period. Once the minimum deposit amount is reached, it will enter the voting period. Anyone can make deposits for the proposal during the deposit period. ### Submitting a Proposal To submit a new proposal, you can send a transaction that includes the proposal details and specifies the deposit amount. This deposit amount does not need to be greater than the minimum deposit (the minimum amount required to enter the voting phase), but the proposal will remain in the deposit period until the total deposit amount is met. The transaction to submit a proposal must include a non-zero positive deposit amount. Example: ```bash enid tx gov submit-proposal param-change proposal.json --from $PROPOSER_KEY ``` Please note that we allow for expedited proposals through the `--is-expedited` flag. This will halve the proposal time but requires double the deposit amount. ### Querying a Proposal You can also view the details and status (deposit period, voting period, etc.) of an existing proposal by querying a specific proposal ID. Example: ```bash enid query gov proposal $PROPOSAL_ID ``` You can also query the proposer of a specified proposal to see the address that initially submitted it. Example: ```bash enid query gov proposer $PROPOSAL_ID ``` ### Depositing for a Proposal If the created proposal is in the deposit period, you can increase the deposit to encourage the proposal to move into the voting period. The deposit amount is represented in deposit amount and deposit tokens, for example, 10000ENI. If the proposal does not reach the minimum deposit before the end of the deposit period, all deposits will be burned. Example: ```bash enid tx gov deposit $PROPOSAL_ID $DEPOSIT_AMOUNT --from $YOUR_KEY ``` ### Querying Deposits Users can query a specific address's deposit on a specific proposal. This can be used to check your current deposit amount or see another account's deposit amount. Example: ```bash enid query gov deposit $PROPOSAL_ID $DEPOSITOR_ADDR ``` You can also use a separate query command to check all deposits for a proposal. Example: ```bash enid query gov deposits $PROPOSAL_ID ``` ### Voting on a Proposal This allows an address to vote on a specified proposal. There are four options when voting: * Yes * No * Abstain * No with veto Example: ```bash enid tx gov vote $PROPOSAL_ID $VOTE_OPTION --from $VOTER_KEY --chain-id $CHAIN_ID ``` ### Weighted Voting Weighted voting transactions allow voters to distribute voting power among various voting options. This is particularly useful for representing multiple stakeholders in different voting decisions. When executing a weighted vote, the transaction is performed with voting weights instead of a single option. Voting weights are represented as a comma-separated string mapping voting options to their weights. The voting weights must sum up to 1 for the transaction to be valid. #### Defining Weights ```bash voting_weights=yes=0.3,no=0.2,no_with_veto=0.15,abstain=0.35 ``` #### Example ```bash enid tx gov weighted-vote $PROPOSAL_ID $VOTING_WEIGHTS --from $VOTER_KEY --chain-id $CHAIN_ID ``` ### Querying Proposal Details This will return information for a single proposal specified by `proposal_id`. Example: ```bash enid query gov proposal $PROPOSAL_ID --chain-id $CHAIN_ID ``` ### Querying Proposal Tally This will return the current vote count for the provided `proposal_id`. ```bash enid query gov tally $PROPOSAL_ID --chain-id $CHAIN_ID ``` ### Querying Individual Votes This will query the voting information for a specific voting address and proposal ID. Example: ```bash enid query gov vote $PROPOSAL_ID $VOTER_ADDR --chain-id $CHAIN_ID ``` # Oracles ## Oracle technology evolution and paradigm breakthrough ### Trust bounds for traditional oracle Traditional oracle architectures (such as **Chainlink**) achieve data trustworthiness through **multi-node signature mechanisms** but face two core challenges: * **Data Transparency Paradox:**\ On-chain disclosure of raw data may lead to sensitive information leaks (such as financial trading strategies and corporate operation data). * **Single-Dimensional Verification:**\ Relies solely on the number of signatures to verify data authenticity, lacking verifiability of the data generation process. **ENI** introduces an innovative **four-layer trust verification system** by incorporating **Zero-Knowledge Proofs (ZKP)** and **cross-chain verification frameworks**: * **Privacy Layer:** Uses **zk-SNARK** for **anonymizing input data**. * **Verification Layer:** Combines **Tendermint BFT consensus** with **threshold signatures** for **dual-layer verification**. * **Proof Layer:** Utilizes the **IBC protocol** to achieve **compressed zero-knowledge proofs** for **cross-chain state verification**. * **Incentive Layer:** Implements a **Proof of Contribution (PoC)**-based **reputation system** for nodes. ### Matrix of zero-knowledge oracle technologies | Technical Dimension | Traditional Solution | ENI’s Solution | | ------------------------- | ------------------------------- | -------------------------------------------------- | | Data Privacy | Plaintext Transmission | Verifiable Encrypted Data Flow | | Verification Efficiency | Multi-round Mutual Verification | Single Effective Proof | | MEV Resistance Capability | Transactions Easily Front-Run | Zero-Knowledge Encapsulation of the Entire Process | | Cross-Chain Verification | Relies on Third-Party Bridges | Native IBC Proof Verification | *** ## Core Architecture of ENI Zero-Knowledge Oracles ### **System Layering Model** Privacy Data Flow Pipeline: (Data Collection → zk Preprocessing → Multi-Chain Verification → Proof Aggregation → Smart Contract Interface) *** ### **Key Technological Innovations** #### **Dual Privacy Protection Mechanism:** * **Input Privacy:** Uses the **Paillier homomorphic encryption algorithm** to enable **aggregation of encrypted data**. * Leverages the **Groth16 protocol** to generate **validity proofs**. Verifier nodes only need to validate the proof’s correctness without accessing raw data. *** #### **Cross-Chain Verification Network** * **IBC Light Client Verification:** Compresses **external chain state proofs** into **zk-SNARK circuits**. * **State Snapshot Signatures:** Generates **verifiable cross-chain state snapshots** every **30 blocks**. *** #### **MEV-Resistant Design** * **Request Obfuscation Pool:** Uses **ring signature technology** to **hide the identity of requestors**. * **Delayed Proof Mechanism:** Executes **data responses** and **proof generation asynchronously** to mitigate MEV risks. *** ## ICore Functions of Zero-Knowledge Oracles ### **Privacy Data Verification** * **Compliance Proofs:** Enterprises can submit proofs for **compliance with carbon emissions standards** without revealing exact data. * **Credit Assessment:** Financial institutions can **verify user credit scores** without accessing full credit records. *** ### **Cross-Chain State Proofs** * **Cross-Chain Asset Verification:** Verifies asset states on **other chains** via the IBC channel, generating **compressed proofs**. * **Smart Contract Interoperability:** Supports **cross-chain contract calls** under **zero-knowledge conditions.** *** ### **IoT Data On-Chain** * **Encrypted Device Fingerprinting:** Processes **industrial sensor data** through zk circuits to generate **unique device fingerprints**. * **End-to-End Verification:** Ensures **verifiable and confidential** data flows from **collection to on-chain storage**. *** ## Developer Integration Guide ### **Basic Integration Process** #### **Initialize Oracle Contracts:** ```solidity interface IZKOracle { function request( bytes32 circuitID, bytes calldata encryptedParams ) external returns (uint256 requestId); } ``` #### **Build Zero-Knowledge Circuits:** * Define **data verification logic** using **Circom language**. * Deploy **verification keys** to the **on-chain registry**. *** ### **Typical Application Scenarios** #### **Scenario 1: Privacy Financial Contracts** * **Anonymous Lending:** Borrowers can prove their **asset holdings** without exposing details. * **Dark Pool Trading:** Executes **large-scale trade orders** under **zero-knowledge conditions**. #### **Scenario 2: Compliance Data On-Chain** * **Medical Data Sharing:** Hospitals can verify that **patient test results** meet treatment standards without exposing data. * **Supply Chain Traceability:** Suppliers can prove **raw material compliance** while protecting trade secrets. *** ## Security Enhancement Mechanisms ### **Five-Layer Protection System** * **Circuit Security Audit:** Conducts **formal verification** of zk circuits. * **Node Reputation Pruning:** Dynamically **adjusts validator node weights** based on reputation. * **Anomaly Circuit Breaker:** **Automatically suspends services** if data deviation exceeds a threshold. * **Proof Retrospective System:** Permanently **stores all proofs** for audit purposes. * **Quantum Resistance:** Adopts **STARK-based quantum-resistant algorithms** for disaster recovery. *** ## Performance Optimization Solutions ### **Proof Generation Acceleration** * **GPU Acceleration:** Supports **CUDA-accelerated** zk proof generation. * **Batch Proofing:** Merges multiple requests into a **single proof** to enhance efficiency. *** ### **Resource Graded Scheduling** Implements **tiered scheduling** for **optimal resource utilization**. | Service Level | Response Time | Proof Complexity | Applicable Scenarios | | ------------- | ------------- | ----------------------------- | ------------------------------- | | Platinum | <1s | Million-gate Circuit | High-Frequency Trading | | Gold | 3s | Hundred-thousand-gate Circuit | IoT Data | | Standard | 10s | Ten-thousand-gate Circuit | Regular Commercial Applications | *** #### **Conclusion** By **deeply integrating zero-knowledge proofs** with the **Cosmos ecosystem**, this system establishes the **first oracle infrastructure** supporting **full privacy and cross-chain verification**. Developers can retain their **familiar EVM development paradigms** while benefiting from **quantum-safe privacy protection** capabilities. This innovation opens up new frontiers for **Web3 applications** in **finance, healthcare, IoT**, and other **sensitive domains**. # Chainlink Relayer The Chainlink Relayer presents an innovative solution, seamlessly and instantaneously bridging Chainlink price feeds from Ethereum to the ENI Chain. This crucial functionality empowers decentralized applications (dApps) on ENI that require robust and up-to-date pricing information. Crucially, these price updates are precisely relayed to a dedicated smart contract on the ENI Chain, which we refer to as the 'Shadow Aggregator.' This Shadow Aggregator is meticulously engineered to possess an identical interface to Chainlink's native aggregators. This design significantly streamlines the development process: once dApps complete their initial integration with the ENI ecosystem, they can effortlessly pivot their existing Chainlink integrations to leverage the relayed data, minimizing development overhead. To ensure transaction finality and data integrity, clients typically await approximately 20 block confirmations – roughly a 5-minute window – after submitting a transaction. This synchronization mechanism guarantees the reliable delivery of critical information. **Currently, during this introductory (or 'XPlan') phase, data submissions by Relayers are restricted to authorized addresses to ensure stability and control. However, a key aspect of our future vision is to evolve into a fully permissionless system. Upon the mainnet's launch, we plan to upgrade this mechanism, enabling anyone to run a Relayer and contribute price data, thereby embracing a truly decentralized model.** ### Shadow Aggregators For each aggregator on Ethereum, ENI provides a *shadow aggregator* on ENI Chain. ### Service Status {% embed url="" %} # APRO Oracle ## Data Pull #### Data Pull: On-Demand & Real-Time APRO Data Pull offers a "**Pull-Based**" data model, which we use to provide [**real-time Price Feed** ](https://docs.apro.com/en/data-pull/price-feed-id)services to decentralized applications (dApps). This solution is specifically designed for use cases that demand **on-demand** access, **high-frequency** updates, **low latency**, and **cost-effective** data integration. The model excels in the oracle ecosystem by emphasizing flexibility and efficiency, making it particularly suitable for DeFi protocols, decentralized exchanges, and other applications that require rapid, dynamic data without continuous on-chain costs. #### On-Demand Data for DeFi & Derivatives The APRO **Pull** **Model** is particularly advantageous for DeFi protocols and derivatives platforms where high-frequency and low-latency price updates are crucial. For example, in a derivatives platform, a trade might only require the latest price when a user executes a transaction. With APRO’s pull-based oracle, the necessary data can be fetched and verified at that specific moment, ensuring accuracy and minimizing costs. #### Key Features of APRO Data Pull * **On-Demand & Cost-Efficient** Unlike the continuous updates of a push-based model, APRO's pull-based approach allows applications to fetch data only when needed, reducing unnecessary on-chain transactions and saving on gas fees. This makes it an ideal solution for real-time data access with improved cost efficiency, especially for applications needing frequent updates or managing multiple assets. * **Customizable Data Frequency** The pull model enables developers to determine how frequently they pull data. This allows the model to accommodate both applications needing constant high-frequency data and those that only require updates during specific events, such as trading or settlement periods. * **Flexible Scalability** With the ability to access data dynamically, APRO’s pull model supports a greater range of assets and market conditions. It provides the infrastructure for applications to scale in complexity while keeping the system’s efficiency intact. * **Data Verification & Security** APRO ensures a secure and trustworthy computing environment by combining off-chain data retrieval with on-chain verification. This cryptographic verification process guarantees that the data pulled from off-chain sources is accurate, tamper-resistant, and agreed upon by a decentralized oracle network. ## Price Feed ID
ChainVerifier Proxy Address
ENI Mainnet

  • VerifierProxy: 0x80C02e85B367AA128CF00A11dF67eBc423e1cd00
  • Valueless_Test Token: 0x90217f167e95d5705C6387ba15F03eEA480A22C2
  • WEGAS: 0x6D1e851446F4D004AE2A72F9AfEd85e8829A205E
## Price Feed Data # ENI DAO {% hint style="info" %} **Attention: The token used to create spaces must inherit from** [**ERC20Votes**](https://docs.openzeppelin.com/contracts/5.x/api/token/ERC20#erc20votes)**.** {% endhint %} ### What is ENI DAO? ENI DAO is a **voting platform** that allows DAOs, DeFi protocols, or NFT communities to vote easily and **without gas fees**.The tool allows high customization of the voting process to cater to the diverse needs of the users and organizations. Customization includes different aspects like calculation of the users' voting power, selection of the voting mechanism, proposal and vote validation, and many more.In short, ENI DAO is an off-chain gasless multi-governance client which results are easy to verify and hard to contest. #### Key features * **Gasless:** Create proposals and cast your votes without any gas fees. * **Flexible voting strategies:** Customize how the voting power is calculated through single or combined strategies that enable voting with ERC20s, NFTs, other contracts, and more. * **Proposal and voting validation:** Use custom logic to define who can create a proposal or cast a vote. * **Multiple voting systems:** Single choice, approval voting, quadratic voting, and more. * **Signed messages:** Votes are cast through signed messages easily verifiable. * **Custom branding** - spaces can use their own branding, color schemes and domain name. ### How does it work? ENI DAO’s protocol involves three core elements: spaces, proposals, and votes. A space functions like an organization’s profile, and every proposal and vote is tied to that space. Once a space is set up, users can submit proposals and cast their votes on the space’s page. Administrators of the space can tailor the rules for creating proposals and voting by configuring various voting and validation strategies. For instance, a space might require users to hold a minimum of 500 tokens to create a proposal, or it might assign voting power proportionally to the token balance in a user’s wallet.
### Who can vote on proposals? There are several aspects that define if you are eligible to vote on a specific proposal. #### Voting strategies Each space specifies their voting strategies in the space settings. You can see the custom setup by opening the space settings. This setup can define if you are eligible to take part in the voting and what is your voting power calculated at the snapshot of proposal creation. In most cases you will be required to have a sufficient amount of tokens in the connected wallet at the time of proposal creation. One of the most common questions we receive on our support channels is **Why can't I vote?** More often than not the answer is - **you did not hold the sufficient amount of specified token at the time of proposal creation.** #### Voting validation Another aspect determining whether you are eligible to vote or not is a voting validation defined by the space. It is a mechanism used to define certain conditions like minimum token balance or also to prevent Sybil Attacks. In other words the space owner wants to make sure that you are human and that bot or fake accounts are not used to overrule the outcome of the voting. ### Cast a vote 1. Click the `Connect wallet` button in the top right corner. 2. Connect with the wallet provider where you hold the tokens relevant for the space you want to vote in. 3. Go to the space page on ENI DAO and selected the active proposal you are interested in. 4. Select the option(s) you want to vote for. The voting systems can differ between individual proposals. 5. Click to `Vote` button and sign the message via your wallet provider when prompted. 6. Voilà! You have casted a vote 🎉 If you are using MetaMask you'll need to scroll to the end of the signature and click on the arrow down for the Sign button to become active. Voting on ENI DAO doesn't affect your account or the funds that are associated to it. # Yochi NFT Yochi NFT Integration Guide ### Overview This document describes how to integrate with the Yochi NFT minting process using the `mintWithChannel` function of the `YochiNFTGenerator` contract. This function allows for the minting of Yochi NFTs with specific configurations by specifying a channel ID. ### Contract Interface #### `mintWithChannel` Function Mints a Yochi NFT through a specified channel. ```solidity function mintWithChannel(uint256 _channel) external returns (uint256) ``` **Parameters** * `_channel` (uint256): The channel ID, used to identify different co-branded series or events. **Return Value** * `uint256`: The Token ID of the minted NFT. **Usage Example** ```javascript // JavaScript Example (using web3.js or ethers.js) const abi = [{"inputs":[{"internalType":"uint256","name":"_channel","type":"uint256"}],"name":"mintWithChannel","outputs":[{"internalType":"uint256","name":"","type":"uint256"}],"stateMutability":"nonpayable","type":"function"}]; const contract = new web3.eth.Contract(abi, "0x882276945dc518C02bDd7414e4D77E205d59Be1c"); await contract.methods.mintWithChannel(100).send({ from: userAddress }); ``` ### Applying for New Co-branded Yochi NFTs If you wish to apply for a new co-branded Yochi NFT, please fill out the following form: [Apply for New Co-branded Yochi NFT Form](https://docs.google.com/forms/d/e/1FAIpQLSfpOCx9viMXwFlFmszlghNg3qfiTUmVON-nR-DtZ6TdfSij1g/viewform?pli=1) Our team will review your application and contact you regarding potential collaboration. # ✅Verified Contract Eni Mainnet Official Token | Name | Address | | -------------------------------------------------------------------------------------------------------- | ------------------------------------------ | | [Wrapped EGAS (WEGAS)](https://scan.eniac.network/token/0x6D1e851446F4D004AE2A72F9AfEd85e8829A205E) | 0x6D1e851446F4D004AE2A72F9AfEd85e8829A205E | | [ENI-Peg USDT (USDT)](https://scan.eniac.network/token/0xDC1a8A35b0BaA3229b13f348ED708a2fd50b5e3a) | 0xDC1a8A35b0BaA3229b13f348ED708a2fd50b5e3a | | [ENI-Peg USDC (USDC)](https://scan.eniac.network/token/0xaFF944b96c1BAEA587159ec446280E468B32ee15) | 0xaFF944b96c1BAEA587159ec446280E468B32ee15 | | [ENI-Peg ETH (ETH)](https://scan.eniac.network/token/0xB0bd57cbEFf9Acf419E550b4C2eD667D90471f55) | 0xB0bd57cbEFf9Acf419E550b4C2eD667D90471f55 | | [ENI-Peg BTC (BTC)](https://scan.eniac.network/token/0xeB42854e3ef027Ac9f39248e6bc519ACA9dc045d) | 0xeB42854e3ef027Ac9f39248e6bc519ACA9dc045d | | [ENI-Peg BNB (BNB)](https://scan.eniac.network/token/0x9b3214ce953B7ce39eFba2e5B936AC51B82fa4f5) | 0x9b3214ce953B7ce39eFba2e5B936AC51B82fa4f5 | | [ENI-Peg SOL (SOL)](https://scan.eniac.network/token/0xeDf484b50CF1492282aa0dED187B117d1d081b4A) | 0xeDf484b50CF1492282aa0dED187B117d1d081b4A | | [ENI Token Option (ENIOPT)](https://scan.eniac.network/token/0xe5fE11Aacaa8e8d0EEB05DD2C9b2Ef80fB8F63f4) | 0xe5fE11Aacaa8e8d0EEB05DD2C9b2Ef80fB8F63f4 | | [EGT Token Option (EGTOPT)](https://scan.eniac.network/token/0xf82f4a68ACa2aA66C9f9575D5c1443912F1803b4) | 0xf82f4a68ACa2aA66C9f9575D5c1443912F1803b4 | # Setup and Installation ## enid CLI enid is a command-line tool for interacting with the ENI blockchain. This page will guide you through setting up Enid and introduce some basic commands to help you get started. ### Prerequisites * Go 1.24+: Installation instructions can be found [here](https://go.dev/doc/install). ### Installation To install enid, first find the version you wish to use [here](https://github.com/eni-chain/go-eni/releases), then run the following commands: ```bash git clone https://github.com/eni-chain/go-eni.git cd go-eni git checkout main make install ``` You can verify that enid is installed correctly by running: ```bash enid version ``` If you encounter an error like `command not found: enid`, you may need to set the `GOPATH` environment variable. 1. Use `go env GOPATH` to find your `GOPATH` 2. Add the following lines to your `~/.bashrc` or `~/.zshrc`: ```bash export GOPATH=[GOPATH obtained from step 1] export PATH=$PATH:$GOPATH/bin ``` More information can be found [here](https://pkg.go.dev/cmd/go#hdr-GOPATH_environment_variable). ### Commands enid supports all the commands necessary for interacting with the chain. To see a list of available commands and their descriptions, run `enid`: ```plaintext Start goeni node Usage: enid [command] Available Commands: blocktest run EF blocktest comet CometBFT subcommands completion Generate the autocompletion script for the specified shell config Utilities for managing application configuration debug Tool for helping with debugging your application export Export state to JSON genesis Application's genesis-related subcommands help Help about any command in-place-testnet Updates chain's application and consensus state with provided validator info and starts the node init Initialize private validator, p2p, genesis, and application configuration files keys Manage your application's keys module-hash-by-height Get module hashes at a given height multi-node Initialize config directories & files for a multi-validator testnet running locally via separate processes (e.g. Docker Compose or similar) prune Prune app history states by keeping the recent heights and deleting old heights query Querying subcommands rollback rollback Cosmos SDK and CometBFT state by one height snapshots Manage local snapshots start Run the full node status Query remote node for status tx Transactions subcommands version Print the application binary version information Flags: -h, --help help for enid --home string directory for config and data (default "/Users/moses/.eni") --log_format string The logging format (json|plain) (default "plain") --log_level string The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:,:') (default "info") --log_no_color Disable colored logs --trace print out full stack trace on errors Use "enid [command] --help" for more information about a command. ``` #### Adding a Wallet You can create a new wallet using the `enid keys` command: ```bash enid keys add $NAME ``` Replace `$NAME` with the name you want to use for this key. This will generate a mnemonic phrase and store the account in the CLI for use. Write down this mnemonic phrase and store it securely. Alternatively, if you want to import an existing mnemonic phrase, you can add the `--recover` flag: ```bash enid keys add $NAME --recover ``` You will then be prompted to enter the mnemonic phrase. If importing from an EVM wallet like MetaMask, you may need to specify the coin type. Ethereum-based (EVM) wallets use coin type `60`, while Eni defaults to `118`. For example, ```bash enid keys add $NAME --coin-type=60 ``` This will generate an address different from the default coin type `118`. To view your local wallets, you can run ```bash enid keys list ``` to see a list of all added wallets, or run ```bash enid keys show $NAME ``` to view details of a specific wallet. # Smart Contracts # EVM (General) ### Overview The Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts, supporting compatibility with Ethereum-based decentralized applications (dApps). ENI is an EVM-compatible blockchain. ENI’s parallelized EVM ensures high performance and efficiency. Here are some key points about the EVM: 1. **Turing Completeness**: The EVM is Turing complete, meaning it can execute any computable function. This allows developers to write complex smart contracts. 2. **Gas**: Transactions and contract executions on EVM-compatible networks consume gas. Gas is a unit of measure for computational work, and users pay for gas on the ENI network using ueni. Gas ensures that malicious or inefficient code does not overload the network. 3. **Bytecode Execution**: Smart contracts are compiled into bytecode (low-level, machine-readable instructions) and deployed to EVM-compatible networks. The EVM executes this bytecode. ### Smart Contract Languages The two most popular languages for developing smart contracts on the EVM are **Solidity** and **Vyper**. #### Solidity * An object-oriented, high-level language for implementing smart contracts. * A curly-brace language most heavily influenced by C++. * Statically typed (variable types are known at compile time). * Supports: * Inheritance (can extend other contracts). * Libraries (reusable code can be created and called from different contracts—similar to static functions in static classes in other object-oriented programming languages). * Complex user-defined types. **Solidity Contract Example** ```solidity // SPDX-License-Identifier: GPL-3.0 pragma solidity >= 0.7.0; contract Coin { // The keyword "public" makes variables // accessible from other contracts address public minter; mapping (address => uint) public balances; // Events allow clients to react to specific // contract changes you declare event Sent(address from, address to, uint amount); // Constructor code is only run when the contract // is created constructor() { minter = msg.sender; } // Sends an amount of newly created coins to an address // Can only be called by the contract creator function mint(address receiver, uint amount) public { require(msg.sender == minter); require(amount < 1e60); balances[receiver] += amount; } // Sends an amount of existing coins // from any caller to an address function send(address receiver, uint amount) public { require(amount <= balances[msg.sender], "Insufficient balance."); balances[msg.sender] -= amount; balances[receiver] += amount; emit Sent(msg.sender, receiver, amount); } } ``` #### Vyper * A Pythonic programming language. * Strong typing. * Small and understandable compiler code. * Efficient bytecode generation. * Deliberately has fewer features than Solidity with the aim of making contracts more secure and easier to audit. Vyper does not support: * Modifiers * Inheritance * Inline assembly * Function overloading * Operator overloading * Recursive calling * Infinite-length loops * Binary fixed points **Example Vyper Contract** ```python # Open Auction # Auction params # Beneficiary receives money from the highest bidder beneficiary: public(address) auctionStart: public(uint256) auctionEnd: public(uint256) # Current state of auction highestBidder: public(address) highestBid: public(uint256) # Set to true at the end, disallows any change ended: public(bool) # Keep track of refunded bids so we can follow the withdraw pattern pendingReturns: public(HashMap[address, uint256]) # Create a simple auction with `_bidding_time` # seconds bidding time on behalf of the # beneficiary address `_beneficiary`. @external def __init__(_beneficiary: address, _bidding_time: uint256): self.beneficiary = _beneficiary self.auctionStart = block.timestamp self.auctionEnd = self.auctionStart + _bidding_time # Bid on the auction with the value sent # together with this transaction. # The value will only be refunded if the # auction is not won. @external @payable def bid(): # Check if bidding period is over. assert block.timestamp < self.auctionEnd # Check if bid is high enough assert msg.value > self.highestBid # Track the refund for the previous high bidder self.pendingReturns[self.highestBidder] += self.highestBid # Track new high bid self.highestBidder = msg.sender self.highestBid = msg.value # Withdraw a previously refunded bid. The withdraw pattern is # used here to avoid a security issue. If refunds were directly # sent as part of bid(), a malicious bidding contract could block # those refunds and thus block new higher bids from coming in. @external def withdraw(): pending_amount: uint256 = self.pendingReturns[msg.sender] self.pendingReturns[msg.sender] = 0 send(msg.sender, pending_amount) # End the auction and send the highest bid # to the beneficiary. @external def endAuction(): # It is a good guideline to structure functions that interact # with other contracts (i.e. they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) # 3. interacting with other contracts # If these phases are mixed up, the other contract could call # back into the current contract and modify the state or cause # effects (ether payout) to be performed multiple times. # If functions called internally include interaction with external # contracts, they also have to be considered interaction with # external contracts. # 1. Conditions # Check if auction endtime has been reached assert block.timestamp >= self.auctionEnd # Check if this function has already been called assert not self.ended # 2. Effects self.ended = True # 3. Interaction send(self.beneficiary, self.highestBid) ``` ### Deploying EVM Contracts on ENI Since ENI is an EVM-compatible chain, existing EVM tools such as [Hardhat](https://hardhat.org/), [Foundry Forge](https://book.getfoundry.sh/), or others can be reused. In this example, we will use the [Foundry tools](https://book.getfoundry.sh/). Install [Foundry tools](https://book.getfoundry.sh/) by following the [installation guide](https://book.getfoundry.sh/getting-started/installation.html). Create a new project by following the [new project guide](https://book.getfoundry.sh/projects/creating-a-new-project). Also, ensure you have a wallet on the ENI network. After the project is created, adjust the contract code by adding a `getCount` function as shown below: ```solidity // SPDX-License-Identifier: UNLICENSED pragma solidity ^0.8.13; contract Counter { uint256 public number; function setNumber(uint256 newNumber) public { number = newNumber; } function increment() public { number++; } function getCount() public view returns (uint256) { return number; } } ``` And update the test code to the following: ```solidity // SPDX-License-Identifier: UNLICENSED pragma solidity ^0.8.13; import {Test, console} from "forge-std/Test.sol"; import {Counter} from "../src/Counter.sol"; contract CounterTest is Test { Counter public counter; function setUp() public { counter = new Counter(); counter.setNumber(0); } function test_Increment() public { counter.increment(); assertEq(counter.number(), 1); } function testFuzz_SetNumber(uint256 x) public { counter.setNumber(x); assertEq(counter.number(), x); } function test_GetCount() public { uint256 initialCount = counter.getCount(); counter.increment(); assertEq(counter.getCount(), initialCount + 1); } } ``` Run the tests with the following command: ```bash $ forge test ``` If the tests pass, deploy the contract to the ENI chain using the following command: ```bash $ forge create --rpc-url $ENI_NODE_URI --mnemonic $MNEMONIC src/Counter.sol:Counter ``` Where `$ENI_NODE_URI` is the URI of the ENI node, and `$MNEMONIC` is the mnemonic phrase of the account deploying the contract. If you are running a local ENI node, the address will be `http://localhost:8545`; otherwise, you can obtain the `evm_rpc` URL from the [registry](https://github.com/eni-chain/chain-registry/blob/main/chains.json). If the deployment is successful, you will see the EVM contract address in the output. ```bash [⠒] Compiling... No files changed, compilation skipped Deployer: $0X_DEPLOYER_ADDRESS Deployed to: $0X_CONTRACT_ADDRESS Transaction hash: $0X_TX_HASH ``` Let’s query the contract using the `cast` command: ```bash $ cast call $0X_CONTRACT_ADDRESS "getCount()(uint256)" --rpc-url $ENI_NODE_URI ``` This command should return `0`, the initial value of the counter. Now, use the `cast` command to call the `increment` function: ```bash $ cast send $0X_CONTRACT_ADDRESS "increment()" --mnemonic $MNEMONIC --rpc-url $ENI_NODE_URI ``` If the command succeeds, you will receive the transaction hash and other information. Now call the `getCount` function again; this time it should return `1`. ### Calling the Contract from a JS Client To call the contract from a frontend, you can use `ethers`, for example: ```tsx import {ethers} from "ethers"; const privateKey = ; const evmRpcEndpoint = const provider = new ethers.JsonRpcProvider(evmRpcEndpoint); const signer = new ethers.Wallet(privateKey, provider); if (!signer) { console.log('No signer found'); return; } const abi = [ { "type": "function", "name": "setNumber", "inputs": [ { "name": "newNumber", "type": "uint256", "internalType": "uint256" } ], "outputs": [], "stateMutability": "nonpayable" }, { "type": "function", "name": "getCount", "inputs": [], "outputs": [ { "name": "", "type": "int256", "internalType": "int256" } ], "stateMutability": "view" }, { "type": "function", "name": "increment", "inputs": [], "outputs": [], "stateMutability": "nonpayable" } ]; // Define the address of the deployed contract const contractAddress = 0X_CONTRACT_ADDRESS; // Create a new instance of the ethers.js Contract object const contract = new ethers.Contract(contractAddress, abi, signer); // Call the contract's functions async function getCount() { const count = await contract.getCount(); console.log(count.toString()); } async function increment() { const txResponse = await contract.increment(); const mintedTx = await txResponse.wait(); console.log(mintedTx); } await increment(); await getCount(); ``` # EVM (CLI) ## Interacting with the EVM on ENI via CLI Once the `enid` command is installed (see Installing enid), you can easily query or send transactions to ENI through the CLI. ### Querying If the machine running these commands is not running a node on the network, you need to append `--node http://url-to-eni-cosmos-rpc` to the commands. Refer to the Tools and Resources page for a list of RPC endpoints. * `enid q evm eni-addr [some EVM address]`: Retrieves the associated ENI address for the queried EVM address (if it exists on-chain). * `enid q evm evm-addr [some ENI address]`: Retrieves the associated EVM address for the queried ENI address (if it exists on-chain). * `enid q evm erc20 [erc20 address] [method] [args...]`: Queries the ERC20 contract at the specified address using the given method and arguments. * `enid q evm payload [abi file path] [method] [args...]`: Generates a hexadecimal payload for a method call based on the provided ABI. * `enid q evm pointer [type] [pointee]`: Retrieves the pointer contract for the requested pointee. The `type` parameter can be one of "NATIVE", "CW20", "CW721", "ERC20", or "ERC721", and `pointee` is the target contract address. For the "NATIVE" type, `pointee` will be the native token denomination. ### Transactions Sending transactions via the CLI requires you to add a key using `enid keys add`. You can then specify the key to use by appending `--from=[key name]` to the commands. If the machine running these commands is not a node on the network, you need to append `--evm-rpc http://url-to-eni-evm-rpc` to the commands. Refer to the Tools and Resources page for a list of RPC endpoints. * `enid tx evm send [target EVM address] [amount in wei]`: Sends native tokens to the target EVM address. * `enid tx evm deploy [binary file path]`: Deploys the EVM contract specified in `path_to_binary`. * `enid tx evm call-contract [address] [payload hex]`: Sends a transaction to call the contract at the target address with the provided payload. * `enid tx evm erc20-send [address] [receiver] [amount]`: Sends ERC20 tokens from the contract at `address` to the target receiver. # Querying State ## Querying Blockchain State Querying the blockchain state to retrieve account balances, token balances, and other information is essential. ### Querying State All nodes contain the latest blockchain state. This means you can query the blockchain state by connecting to an RPC node. There are three primary methods to query a node: * RPC Endpoint * gRPC Endpoint * REST Endpoint * Websockets ### Querying Historical State When working with blockchain applications, querying historical state data is crucial for various types of applications. To query historical state data, you can use an archive node and specify the block height at which you want to retrieve the state. • **Example**: To query the state at a specific block height, you can use the following method: Querying with enid by block height `enid query bank balances [address] --height ` • This command allows you to specify a block height and retrieve the state at that specific point in time. ### **Pruning** Pruning is the process of removing old blockchain data that is no longer needed to save disk space and improve performance. Pruned nodes retain only a limited amount of recent blockchain data, making them faster and less storage-intensive for RPC providers. • **Purpose**: Pruning helps reduce the storage requirements of a blockchain node, making it more efficient and easier to manage. • **Limitation**: Pruned nodes do not retain the full blockchain history, so they cannot be used to query historical data beyond the pruning window. ### **Archive Nodes** On the other hand, archive nodes store the entire blockchain history from the genesis block to the latest block. This makes them essential for querying historical state data. • **Purpose**: Archive nodes preserve the complete blockchain history, allowing developers to query any past state by block height. • **Use Cases**: Archive nodes are critical for tasks requiring access to historical data, such as catching up indexers, conducting historical analysis, and verifying past transactions. ### **Using Indexers for Historical Data** While archive nodes provide raw historical data, indexers are vital for efficiently querying and analyzing this data. Indexers organize and optimize the data, making it more accessible and easier to analyze. # Frontend Development # Overview Developing a frontend for a dApp on ENI involves connecting to wallets, interacting with the blockchain via RPC endpoints, and signing and broadcasting transactions. A dApp should choose either EVM or Cosmos as its connection method but can leverage interoperability features like precompiles and pointer contracts to support both environments. #### Wallet Connection Connecting to a wallet is a critical step in dApp development. Below are some recommended wallet connection libraries, each with its specific advantages: #### EVM and EVM RPC dApps: * **Wagmi**: A React-based library for Ethereum dApps that simplifies wallet connections and interactions. It provides hooks for interacting with Ethereum wallets and contracts, making it suitable for modern frontend libraries and frameworks. * [Wagmi Documentation](https://wagmi.sh/) * **Viem**: A lightweight and flexible Ethereum development library. * [Viem Documentation](https://viem.sh/docs/getting-started) * **Ethers.js**: A complete and compact library for interacting with the Ethereum blockchain and its ecosystem. Known for its simplicity and extensive functionality. * [Ethers.js Documentation](https://docs.ethers.io/v6/) #### RPC Endpoints dApps need to connect to RPC providers to broadcast transactions or query the chain. There are many free providers available on testnets and development networks, while mainnets have some rate-limited providers. For more information and links, refer to the RPC Providers section. #### Polyfills Warning When developing frontend applications for blockchain, it’s important to note that certain libraries may require polyfills, especially when used in a browser environment. For example, the `Buffer` class and other Node.js-specific features are not natively available in browsers and need to be polyfilled. If you’re using Vite or another Rollup-based frontend library, you can add the following to your application’s entry point: ```tsx import { Buffer } from 'buffer'; // Polyfill self for browsers, global for Node.js const globalObject = typeof self !== 'undefined' ? self : global; Object.assign(globalObject, { process: process, Buffer: Buffer }); ``` If you’re using a Webpack-based bundler, you can use the following plugin in your Webpack configuration: ``` yarn add -D node-polyfill-webpack-plugin ``` ```tsx import NodePolyfillPlugin from 'node-polyfill-webpack-plugin'; ... // The rest of your Webpack configuration plugins: [ ... new NodePolyfillPlugin(), ... ], ... ``` #### Advice for New Developers 1. **Understand Gas Fees**: Gas fees are essential for executing transactions on the blockchain. Ensure you understand how they work and how to optimize your contracts to minimize gas usage. 2. **Security Practices**: Always follow best security practices. Regularly audit your code and stay informed about the latest security vulnerabilities and patches. 3. **Testing**: Thoroughly test your dApps in different environments to ensure they function correctly. Use testnets and faucets to test transactions without spending real tokens. 4. **Documentation**: Leverage the extensive documentation available for each library and tool. Good documentation can significantly speed up your development process. 5. **Community and Support**: Join developer communities, forums, and chat groups. Engaging with other developers can provide valuable insights and help you resolve issues more efficiently. # How to Deploy Your First dApp ### 1. Environment Setup and Toolchain Configuration #### 1.1 Development Environment Requirements * Node.js v18+ (recommended to use nvm for version management) * Go 1.24+ (for Cosmos SDK-relat4ed toolchain) * MetaMask wallet (configured with custom RPC) * Git (version control) #### 1.2 Chain Node Configuration ```bash git clone https://github.com/eni-chain/go-eni.git cd go-eni make install ``` #### 1.3 MetaMask Network Configuration 1. Open MetaMask -> Networks -> Add Network 2. Fill in the parameters: * Network Name: ENI Mainnet * RPC URL: * ChainID: 173 * Symbol: ENI * Block Explorer: #### 1.4 Development Tools Installation ```bash # Install Hardhat npm install --save-dev hardhat npx hardhat init # Select TypeScript template ``` *** ### 2. Smart Contract Development and Deployment #### 2.1 Creating a Sample Contract ```solidity // contracts/MoodDiary.sol // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract MoodDiary { string private mood; event MoodUpdated(address indexed user, string newMood); function setMood(string memory _mood) public { mood = _mood; emit MoodUpdated(msg.sender, _mood); } function getMood() public view returns (string memory) { return mood; } } ``` #### 2.2 Deployment Configuration (hardhat.config.ts) ```typescript import { HardhatUserConfig } from "hardhat/config"; const config: HardhatUserConfig = { solidity: "0.8.20", networks: { yourchain: { url: "https://rpc.eniac.network", accounts: [process.env.PRIVATE_KEY!], chainId: 173, } } }; ``` #### 2.3 Deployment Script ```typescript // scripts/deploy.ts import { ethers } from "hardhat"; async function main() { const MoodDiary = await ethers.getContractFactory("MoodDiary"); const moodDiary = await MoodDiary.deploy(); await moodDiary.waitForDeployment(); console.log("Contract deployed to:", await moodDiary.getAddress()); } main().catch((error) => { console.error(error); process.exitCode = 1; }); ``` #### 2.4 Execute Deployment ```bash # Compile the contract npx hardhat compile # Deploy to mainnet (requires PRIVATE_KEY environment variable configured beforehand) npx hardhat run scripts/deploy.ts --network $NETWORK_NAME ``` > Example output: `Contract deployed to: 0x3c45B8...dC7` *** ### 3. Frontend Integration Development #### 3.1 Initialize React Project ```bash npx create-react-app dapp-frontend --template typescript cd dapp-frontend npm install ethers @metamask/providers ``` #### 3.2 Core Interaction Logic ```typescript // src/services/contract.ts import { ethers } from "ethers"; const contractAddress = "0x3c45B8...dC7"; const abi = [...]; // Obtained from artifacts/contracts/MoodDiary.sol/MoodDiary.json export async function getMood() { const provider = new ethers.BrowserProvider(window.ethereum); const contract = new ethers.Contract(contractAddress, abi, provider); return await contract.getMood(); } export async function setMood(newMood: string) { const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const contract = new ethers.Contract(contractAddress, abi, signer); const tx = await contract.setMood(newMood); return tx.wait(); } ``` #### 3.3 Wallet Connection Component ```tsx // src/components/WalletConnect.tsx import { useState } from 'react'; import { ethers } from 'ethers'; export default function WalletConnect() { const [account, setAccount] = useState(""); const connectWallet = async () => { if (window.ethereum) { try { await window.ethereum.request({ method: 'eth_requestAccounts' }); const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); setAccount(await signer.getAddress()); } catch (error) { console.error("User denied account access"); } } else { alert("Please install MetaMask!"); } }; return ( ); } ``` *** ### 4. Testing and Validation #### 4.1 Claim Test Tokens 1. Visit the chain’s test faucet website 2. Enter your wallet address to receive test ENI tokens #### 4.2 Functional Testing Process 1. Start the frontend: `npm start` 2. Connect the wallet (switch to ENI Testnet) 3. Test scenarios: * Set Mood: Enter any string and submit * Get Mood: Verify the return value matches the blockchain state * Check Transaction Hash: Verify transaction details on the block explorer *** ### 5. Advanced Deployment Options #### 5.1 Deploying Contracts Using Cosmos CLI (Alternative) ```bash # Upload contract ABI and bytecode to the chain enid tx evm deploy --from --chain-id $CHAIN_ID ``` #### 5.2 Calling Chain-Specific Enhanced Features ```solidity // Example of accessing Cosmos SDK features interface ICosmosPrecompile { function queryValidator(address valAddr) external view returns (uint256 votingPower); } contract ValidatorInfo { function getVotingPower(address valAddr) public view returns (uint256) { return ICosmosPrecompile(0x000000000000000000001).queryValidator(valAddr); } } ``` *** ### 6. Best Practice Recommendations 1. **Security Auditing**: Use Slither or MythX for static contract analysis 2. **Gas Optimization**: Leverage Cosmos SDK’s batch transaction features to reduce fees 3. **State Monitoring**: Integrate Tendermint RPC for real-time event subscriptions 4. **Cross-Chain Integration**: Interact with other Cosmos ecosystem chains via the IBC protocol # Ecosystem # Tools and Resources Here, you’ll find a curated list of development tools, public endpoints for testing, and other resources to support your development journey on ENI. **EVM** * [Foundry](https://getfoundry.sh/): EVM smart contract development toolchain * [Hardhat](https://hardhat.org/): Ethereum development environment ### Resources To support your development and testing efforts, we provide a range of public RPC endpoints. ### Public Endpoints Public RPC endpoints should only be used in development environments. For production applications, please use dedicated RPC endpoints or set up your own RPC node. # Resources In this section, we will provide a comprehensive overview of the main tools and technologies used in the ENI blockchain ecosystem. Whether you are new to web3 development or an experienced developer looking to expand your skills, these resources will help you get started and deepen your understanding. Developers on ENI have the unique advantage of choosing between smart contract development on CosmWasm and EVM, and they can seamlessly interact between the two environments. #### Cosmos SDK The Cosmos SDK is a modular framework for building custom blockchains in the Cosmos ecosystem. It provides a set of tools and libraries that simplify the creation and management of interoperable blockchains. * **Tendermint**: Tendermint is the consensus engine that powers the Cosmos SDK. It ensures fast and secure consensus through a Byzantine Fault Tolerance (BFT) protocol. * [Tendermint Documentation](https://docs.tendermint.com/) * **Modular Architecture**: The Cosmos SDK adopts a modular architecture that allows developers to create and integrate various modules to build feature-rich blockchains. * [Modular Architecture Documentation](https://docs.cosmos.network/v0.46/building-modules/intro.html) * **Transaction Structure**: Understanding the transaction structure is crucial for developing applications on the Cosmos SDK. Transactions are the primary way to interact with the blockchain. * [Transaction Structure Documentation](https://docs.cosmos.network/main/learn/advanced/transactions) * **IBC (Inter-Blockchain Communication)**: IBC is a protocol that enables communication and asset transfer between different blockchains in the Cosmos ecosystem. * [IBC Overview](https://docs.cosmos.network/v0.45/ibc/overview.html) #### EVM (Ethereum Virtual Machine) The EVM is the runtime environment for smart contracts on Ethereum and EVM-compatible blockchains like ENI. It allows developers to write and deploy smart contracts using Solidity. * **Solidity**: Solidity is the most widely used programming language for writing smart contracts on the EVM. It is a statically typed language influenced by JavaScript, Python, and C++. * [Solidity Documentation](https://docs.soliditylang.org/en/v0.8.25/) * **Hardhat**: Hardhat is a development environment for compiling, deploying, testing, and debugging Ethereum software. It is highly extensible and integrates well with other tools. * [Hardhat Documentation](https://hardhat.org/hardhat-runner/docs/getting-started) * **Foundry**: Foundry is a toolkit for Ethereum application development that provides a comprehensive set of tools for testing and deploying smart contracts. * [Foundry Documentation](https://github.com/foundry-rs/foundry) # Getting Started ### System Requirements Before setting up an ENI node, ensure your system meets the following minimum requirements: #### Hardware Specifications | Component | Minimum Requirement | Recommended Configuration | Notes | | ----------- | ------------------- | ------------------------- | ---------------------------------------------------------- | | **CPU** | 8 cores | 16 cores | Modern processor (Intel Xeon/Core i7/i9 or AMD Epyc/Ryzen) | | **Memory** | 32GB | 64GB | DDR4 or higher | | **Storage** | 300GB NVMe SSD | 500GB NVMe SSD | High IOPS required; SATA SSD not recommended | | **Network** | 1Gbps | 2Gbps | Low-latency connection is critical | #### Basic System Setup Start with a fresh installation of **Debian 12**, **Ubuntu 20.04 LTS** (or higher). Then, update the system and install the necessary packages: ```bash sudo apt update && sudo apt upgrade -y sudo apt install make gcc git jq chrony curl lz4 wget tar build-essential -y ``` > **Tip:** Ensure your system clock is synchronized (via `chrony` or `ntpd`) and your timezone is set to **UTC** to avoid potential issues with block validation, IBC transfers, etc. *** ### Rapid deployment Eni has a default configuration of four nodes for single-machine deployment, which can be used for rapid deployment and startup of the eni chain. If implementing commercialized deployment, please skip rapid deployment and start with custom deployment or automated setup scripts below. #### Download the source code **git clone** Clone the go-eni project code from the eni code repository using the git tool. ```shell git clone https://github.com/eni-chain/go-eni.git ``` #### One-click deployment After downloading the code, enter the project directory go-eni. Then execute the following command to deploy and start a four-node eni blockchain on one machine with one click. ```shell cd go-eni git checkout main make start4-node ``` The make start-4-node command will automatically perform the following operations: * Compile the go-eni project code, create the go-eni/build directory, and place the generated eni executable file in the go-eni/build directory. * Read node1\~ node4 in the default configuration directory of go-eni/eni-nodes, and start the four nodes node1\~ node4 according to the default configuration. \ After the command execution is completed, if the following information is printed, it indicates that the chain compile deployment has started successfully. ```solidity Starting 4 eni nodes... nohup ./build/enid start --home=./eni-nodes/node1 &> ./build/node1.log & nohup ./build/enid start --home=./eni-nodes/node2 &> ./build/node2.log & nohup ./build/enid start --home=./eni-nodes/node3 &> ./build/node3.log & nohup ./build/enid start --home=./eni-nodes/node4 &> ./build/node4.log & Done starting 4 eni nodes. ``` \ After startup, the log files of the node will be printed in the go-eni/build directory in real time. You can enter go-eni/build to view the log files of node1\~ node4 and observe the operation of the chain and node. 
% cd build
% ls
enid        node1.log        node2.log        node3.log        node4.log
% tail -f node1.log 
6:27PM INF Time Commit end time=2025-04-17T18:27:48+08:00 module=server spend time=0
6:27PM INF Update fastMempool end block height=86 elapsedTime=0 module=mempool start time="Apr 17 18:27:48.572351" tx len=0
6:27PM INF committed state block_app_hash=FEADB503B8F5AA1D92C2E7D78DB10BD2F452ABD9E1EC1407E0937EC81C12A457 elapsed time=18826 height=86 module=state time now="Apr 17 18:27:48.572384"
6:27PM INF finalized block execute time elapsed=0.36 function elapsed =93.148 height=86 module=state time now="Apr 17 18:27:48.609816"
......
#### One-click close Execute the following command to shut down the service with one click. 
# return the upper directory "go-eni" from "build"
cd ..
# stop 4 node
make stop4-node
After the command is executed, if the following information is printed, it indicates that the service has been successfully shut down. ```shell Stopping 4 eni nodes... Done stopping 4 eni nodes. ``` After the service is shut down, it can be restarted by using the one-click deployment command make Start4-node. After startup, the chain still runs based on the last data. For example, if it was shut down when the block height was 88 last time, after this startup, the block height will start from 88.If you want to restart a chain from scratch, you need to clear the data from the last run and redeploy it with one click. ```shell # clear the node data make reset-multi-node # build and start 4 node make start4-node ``` ### Custom Deployment If developers are not satisfied with rapid deployment based on default configuration and default Port Number, they can generate custom configurations and specify port deployment to start a chain. #### Download the source code **git clone** Clone the go-eni project code from the eni code repository using the git tool. ```shell git clone https://github.com/eni-chain/go-eni.git ``` #### Configuration generation Enter the go-eni project directory and execute the following command to generate a custom configuration for the four nodes. The information such as the founder account and validator account in the configuration will be randomly generated. Because the default configuration already exists in the go-eni/eni-nodes directory, it is necessary to delete the default configuration directory before executing the custom configuration command. ```shell cd go-eni make build #delete default config for 4 node rm -rf eni-nodes # Generate custom configuration. The current script supports 3 parameters. # -1. Number of consensus nodes created (default 4); # -2. Number of Staking accounts (default 4), which requires that the number of staking accounts must be greater than the number of consensus nodes; # -3. Whether it is a single-machine deployment script (default true). # Generate the multi-machine deployment configuration. After the configuration is generated, the persistent_peers ip of config.yaml needs to be modified manually. For details, please refer to the configuration Settings below ./generate_nodefile.sh 4 4 false # Node peer id query command. Different configuration directories need to be specified on different nodes. For example, node2 needs to specify --home=./eni-nodes/node2 ./build/enid comet show-node-id --home=./eni-nodes/node1 ``` After the command is executed, a new custom configuration will be generated in the go-eni/eni-nodes directory, as shown in the following figure.
Here we need to focus on three documents: * node\_key is the private key we use for network communication. * priv\_validator\_key is the private key used during the consensus period. * Keyring-test/validator1.info is the key file for collecting gas fee and block reward (there is no key by default, you can export the private key by the following command: ```sql echo y | ./enid keys export validator1 --unarmored-hex --unsafe --home ../eni-nodes/node1 897c2fc636602de4e1ca89409ebd006edb927ec8bfa5aabd26ec94e51c0bd4d1 ``` #### Configuration settings After the custom configuration is generated, some configuration fields can be modified according to one's own needs. **app.toml configuration** The automatically generated app.toml file is missing EniDB Configuration and evm Configuration, so we need to manually append its content to the end of the app.toml file. ```shell cat >> eni-nodes/node1/config/app.toml <# log in to the go-eni directory of node 1 and execute the following command % nohup ./build/enid start --home=./eni-nodes/node1 &> ./build/node1.log & # log in to the go-eni directory of node 2 and execute the following command % nohup ./build/enid start --home=./eni-nodes/node2 &> ./build/node2.log & # log in to the go-eni directory of node 3 and execute the following command % nohup ./build/enid start --home=./eni-nodes/node3 &> ./build/node3.log & # log in to the go-eni directory of node 4 and execute the following command % nohup ./build/enid start --home=./eni-nodes/node4 &> ./build/node4.log & ### Full Node Deployment Full nodes are asynchronous nodes that do not participate in the consensus of the chain and only synchronize blocks. If full nodes are not deployed, this chapter process can be skipped. #### Copy configuration Copy a configuration from any consensus node. ```shell cp rf eni-nodes/node4 eni-nodes/node5 ``` #### Modify config.toml Modify the identity nickname moniker of the full node to avoid having the same name as other nodes. 
moniker = "node5"
#### Modify app.toml (optional modification, can be skipped) Modify the database type in app.toml and enable historical data storage. 
[state-store]
# DBBackend defines the backend database used for state-store.
# Supported backends: pebbledb, rocksdb, sqlite
# defaults to pebbledb (recommended)
ss-backend = "pebbledb"

ss-keep-last-version = true
#### Delete nodes and validator key files Non-consensus nodes must delete node\_key and priv\_validator\_key files, otherwise they will interfere with consensus. After deletion, full nodes will regenerate their own node\_key and priv\_validator\_key files. ```shell rm -rf eni-nodes/node5/config/node_key.json rm -rf eni-nodes/node5/config/priv_validator_key.json ``` #### Start the full node After the configuration file is set up, compile the go-eni project and start the full node. ```shell make build nohup ./build/enid start --home=./eni-nodes/node5 &> ./build/node.log & ``` ### **Automated setup scripts (development/testing)** In addition to one-click quick deployment and custom deployment, we also provide script automation deployment. This option is ideal when you want to quickly start a node without delving into manual configuration. ```shell git clone https://github.com/eni-chain/go-eni.git cd go-eni make build python3 scripts/run-node.py ``` This script will guide you to choose: * **Network:** (mainnet, testnet or local) * **Database backend:** (recommended to use `eni-db` ) * **Basic configuration options** *** ### Advanced Synchronization Options Choose one of the following synchronization methods based on your operational needs: #### State Sync Configuration (Non-Archive Nodes) State sync allows your node to catch up quickly by retrieving a recent snapshot from trusted peers instead of replaying all historical blocks. **Steps** **Edit the `[statesync]` section:** In `~/.eni/config/config.toml`, update or add the following persistent peers: ```toml p2p.state-sync-0.eniac-1.eniac.network:26656, ``` **Automate Trust Parameter Configuration:** Use the following script to dynamically set the trust height and hash based on the provided RPC endpoint:
Click to expand ```` ```bash #!/bin/bash # Check if an RPC URL or IP:PORT is provided if [ -z "$1" ]; then echo "Usage: $0 " exit 1 fi RPCADDR=$1 CONFIG_FILE="$HOME/.eni/config/config.toml" # Fetch the current height and latest block hash from /status STATUS_DATA=$(curl -s "$RPCADDR/status" | jq -r '.sync_info.latest_block_height + " " + .sync_info.latest_block_hash') CURRENT_HEIGHT=$(echo "$STATUS_DATA" | cut -d' ' -f1) LATEST_HASH=$(echo "$STATUS_DATA" | cut -d' ' -f2) if [ -z "$CURRENT_HEIGHT" ] || [ -z "$LATEST_HASH" ]; then echo "Error: Could not fetch current height or latest block hash from $RPCADDR" exit 1 fi # Adjust the current height for safety ADJUSTED_HEIGHT=$((CURRENT_HEIGHT - 9000)) ROUNDED_HEIGHT=$(( (ADJUSTED_HEIGHT / 10000) * 10000 + 1 )) TRUST_HEIGHT=$ROUNDED_HEIGHT # Fetch the trust hash for the calculated trust height BLOCK_DATA=$(curl -s "$RPCADDR/block?height=$TRUST_HEIGHT" | jq -r '.block_id.hash') TRUST_HASH=$BLOCK_DATA if [ -z "$TRUST_HASH" ]; then echo "Error: Could not fetch trust hash for height $TRUST_HEIGHT from $RPCADDR" exit 1 fi # Update the config.toml file if [ -f "$CONFIG_FILE" ]; then sed -i "s/^enable = .*/enable = true/" "$CONFIG_FILE" sed -i "s/^use-p2p = .*/use-p2p = true/" "$CONFIG_FILE" sed -i "s/^trust-height = .*/trust-height = $TRUST_HEIGHT/" "$CONFIG_FILE" sed -i "s/^trust-hash = .*/trust-hash = \"$TRUST_HASH\"/" "$CONFIG_FILE" echo "Updated $CONFIG_FILE with the following values:" echo " trust-height = $TRUST_HEIGHT" echo " trust-hash = $TRUST_HASH" else echo "Error: Config file $CONFIG_FILE not found." exit 1 fi ``` ````
**Usage:** ```bash chmod +x script.sh ./script.sh ``` *Ensure the `[statesync]` section already includes the persistent peers listed above.* *** ### Mempool Configuration Tuning To optimize transaction processing and resource management, it’s recommended to update the mempool settings in the `config.toml` file as follows: ```toml ####################################################### ### Mempool Configuration Options ### ####################################################### [mempool] # Broadcast transactions to other nodes broadcast = true # Maximum number of transactions in the mempool size = 5000 # Limit the total size of all transactions in the mempool max-txs-bytes = 10737418240 # Cache size (for filtering duplicate transactions) cache-size = 10000 # Do not remove invalid transactions from the cache keep-invalid-txs-in-cache = false # Maximum size of a single transaction max-tx-bytes = 2048576 # Maximum size of transaction batches sent to peers max-batch-bytes = 0 # Time-to-live duration for transactions in the mempool ttl-duration = "3s" # Maximum number of blocks a transaction can remain in the mempool ttl-num-blocks = 5 tx-notify-threshold = 0 check-tx-error-blacklist-enabled = false check-tx-error-threshold = 0 pending-size = 5000 max-pending-txs-bytes = 1073741824 pending-ttl-duration = "3s" pending-ttl-num-blocks = 5 ``` > **Suggestion:** Adjust these parameters if you encounter performance or resource issues. *** ### Set Up Service with systemd Setting up a systemd service ensures your node starts automatically on boot and restarts if it crashes. ```bash sudo tee /etc/systemd/system/enid.service > /dev/null << EOF [Unit] Description=ENI Node After=network-online.target [Service] User=$USER ExecStart=$(which enid) start Restart=always RestartSec=3 LimitNOFILE=65535 [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable enid sudo systemctl start enid ``` > **Note:** Confirm that the `User` field suits your environment. Update it accordingly if running under a different user. *** ### Validation and Troubleshooting #### Validate Your Setup Run the following commands to confirm the node’s status: ```bash # Check sync status enid status | jq .SyncInfo # View live logs journalctl -u enid -f -o cat ``` Your node is correctly set up when: * Sync status shows `"catching_up": false` * Logs indicate blocks are being processed #### Common Troubleshooting Tips **Sync Issues** * Verify sufficient disk space. * Ensure a stable network connection. * Confirm the system time is correctly synchronized. * Use state sync for rapid initial sync (note: not applicable for archive nodes). **Performance Issues** * Monitor system resources (CPU, memory, I/O). * Evaluate disk performance and network bandwidth. * Adjust mempool and persistent peer settings if necessary. **Network Connectivity** * Confirm firewall rules allow required ports (e.g., 26656, 26657, 9090). * Check that DNS resolution is functioning. * View system logs and node info via RPC \[localhost:26657/net\_info] to verify peer connections. *** ### Next Steps Once your node is up and running, consider the following: 1. **Monitoring and Alerts:** Set up tools to monitor node health and performance. 2. **Security Best Practices:** Harden your server (firewall, SSH keys, etc.). 3. **Backup Procedures:** Regularly back up your configuration and data directories. Additional documentation can be found at: * Advanced Configuration and Monitoring Guide * Node Operators Guide * Validators Guide # Node Operators Guide This guide covers the detailed operational aspects of running an ENI node, including configuration management, maintenance procedures, and best practices for stable and efficient operation. ### Configuration Management #### Directory Structure The configuration for an ENI node is stored in the `~/.eni/config/` directory: ```bash ~/.eni/config/ ├── app.toml # Application configuration (gas fees, API settings, pruning, etc.) ├── client.toml # CLI and client-related settings ├── config.toml # Core Tendermint settings (network, consensus, and RPC) ├── genesis.json # Genesis file for the chain, defining the initial state ├── node_key.json # Unique node identity key for peer-to-peer (P2P) networking └── priv_validator_key.json # Validator private signing key (if running as a validator) ``` #### Key Configuration Parameters **Network Settings (config.toml)** ```toml [p2p] # Public IP for other nodes to reach you external_address = "your-public-ip:26656" # Local address to listen for incoming P2P connections laddr = "tcp://0.0.0.0:26656" # Allowed number of peers max_num_inbound_peers = 40 max_num_outbound_peers = 20 # Network bandwidth limits to prevent congestion send_rate = 20480000 # 20MB/s recv_rate = 20480000 # 20MB/s [rpc] # RPC listening address laddr = "tcp://0.0.0.0:26657" # Maximum concurrent connections max_open_connections = 900 # Transaction confirmation timeout timeout_broadcast_tx_commit = "10s" ``` **Application Settings (app.toml)** ```toml # Minimum gas prices [to prevent spam transactions] minimum-gas-prices = "0.01ueni" [api] # Enable API server enable = true max-open-connections = 1000 [state-commit] # Use ENI-DB for improved performance sc-enable = true [state-store] # Enable state store for historical queries ss-enable = true # Keep 100,000 blocks for querying # 0 = "keep all" ss-keep-recent = 100000 ``` ### Database Management #### Database Types ENI supports two database backends: 1. **ENI-DB (Recommended)** * Optimized for performance and sync time * Reduced resource usage * Suitable for all nodes 2. **Traditional IAVL DB** * Standard Cosmos SDK database * More extensively tested #### ENI-DB Configuration ```toml [state-commit] sc-enable = true sc-async-commit-buffer = 100 sc-keep-recent = 1 # Keep only the latest state for performance sc-snapshot-interval = 10000 # State snapshot every 10,000 blocks [state-store] ss-enable = true ss-backend = "pebbledb" # Default, required ss-async-write-buffer = 100 ss-keep-recent = 100000 # Keep the most recent 100,000 blocks ss-prune-interval = 600 # Pruning cleanup interval ``` Setting a very small \[more frequent] pruning interval may cause conflicts with automatic snapshots. A very large \[less frequent] pruning interval means longer total pruning time, which could lead to missed blocks and extended resync times. #### Database Maintenance The database is generally stable and can run without intervention, but occasional attention may be required: ```bash # Check database size du -sh ~/.eni/data/ # Confirm the correct file paths based on your setup before proceeding # Before performing database cleanup, ensure you back up critical files: # - `node_key.json`: Preserves node identity for maintaining peer connections. # - `priv_validator_key.json`: Validator critical; losing this risks double-signing. # - `config.toml` and `app.toml`: Retain node-specific configuration. # - `genesis.json`: Required for proper chain initialization. # Compact the database to optimize storage (only if needed) find ~/.eni/data/ -mindepth 1 ! -name 'priv_validator_state.json' -delete && rm -rf ~/.eni/wasm # Back up the database cp -r ~/.eni/data/ ~/eni-backup-$(date +%Y%m%d)/ ``` ### Service Management #### Systemd Commands ```bash # Check service status systemctl status enid # Start service systemctl start enid # Stop service systemctl stop enid # Restart service systemctl restart enid # View logs in real-time journalctl -fu enid -o cat ``` #### Log Management Enable log rotation to prevent logs from consuming excessive disk space: ```bash sudo tee /etc/logrotate.d/eni > /dev/null << EOF /var/log/eni/*.log { daily rotate 14 compress delaycompress notifempty create 0640 eni eni sharedscripts postrotate systemctl reload enid endscript } EOF ``` ### Update Procedures #### Minor Updates For minor updates that do not break consensus: ```bash # Stop the node sudo systemctl stop enid # Update the binary cd eni-chain git fetch --all git checkout [new-version] make install # Restart the node sudo systemctl restart enid ``` #### Major Updates For major upgrades introducing state-breaking changes: 1. Wait for the specified upgrade block height \[visible in the upgrade proposal’s 'plan'] 2. The node will stop automatically. 3. Update/replace the binary 4. Restart the node. ```bash # After the node stops cd eni-chain git pull git checkout [new-version] make install sudo systemctl restart enid ``` *Tip - Build the upgrade before the halt height so it can be quickly swapped in, minimizing downtime.* ### Performance Optimization The effectiveness of performance optimizations may vary depending on system hardware, workload, and network conditions. Research and test any changes in a controlled environment before implementation to ensure compatibility with your specific configuration and requirements. Always back up critical data before making modifications. #### Memory Management (sysctl Tuning) Optimizing memory management settings can improve performance and stability, especially for high-load nodes. These settings control swap usage and the handling of dirty pages in RAM. ```bash vm.swappiness = 1 # Reduce swapping to disk, ensuring RAM is used effectively before relying on slower swap space vm.dirty_background_ratio = 3 # Percentage of system memory that can be filled with "dirty" pages before background writing starts vm.dirty_ratio = 10 # Maximum percentage of system memory that can be filled with "dirty" pages before triggering a full flush vm.dirty_expire_centisecs = 300 # Time before dirty data is written to disk (in hundredths of a second) vm.dirty_writeback_centisecs = 100 # Frequency at which "dirty" pages are written to disk (in hundredths of a second) ``` #### Network Stack Optimization Tuning the network stack can improve packet handling efficiency and throughput, particularly for nodes handling many peers and high transaction volumes. ```bash net.core.somaxconn = 32768 # Maximum number of queued connections net.core.netdev_max_backlog = 32768 # Number of queued packets allowed before dropping incoming packets net.ipv4.tcp_max_syn_backlog = 16384 # Number of outstanding SYN requests (half-open connections) allowed before dropping new ones net.core.rmem_max = 16777216 # Receive buffer size for network sockets net.core.wmem_max = 16777216 # Send buffer size for network sockets ``` #### Storage Optimization Optimizing storage settings can significantly reduce write latency and improve database performance, especially for nodes using NVMe SSDs. ```bash echo "none" > /sys/block/nvme0n1/queue/scheduler # Disable I/O scheduler to reduce latency blockdev --setra 4096 /dev/nvme0n1 # Read-ahead value to optimize sequential reads ``` ### Backup and Recovery #### Regular Backups Automate backups to prevent data loss: ```bash #!/bin/bash BACKUP_DIR="/backup/eni" DATE=$(date +%Y%m%d) # Stop the service systemctl stop enid # Create the backup tar czf $BACKUP_DIR/eni-backup-$DATE.tar.gz ~/.eni/ # Restart the service systemctl start enid ``` #### Recovery Procedure Restore from a backup in case of corruption or accidental deletion: ```bash # Stop the node systemctl stop enid # Remove corrupted data rm -rf ~/.eni/data/ # Restore from backup tar xzf eni-backup-[date].tar.gz -C / # Restart the node systemctl start enid ``` ### Troubleshooting #### Common Issues and Solutions 1. **Synchronization Issues** * Check available disk space (`df -h`) * Ensure proper peer connections (`enid net info`) * Verify firewall settings (port 26656 open) 2. **Performance Issues** * Monitor system resources (`htop` or `iotop`) * Check disk I/O performance (`iostat`) * Analyze network traffic (`iftop`) 3. **Database Issues** * Run a database integrity check with: ```bash enid debug dump-db | grep -i error ``` If errors are detected, consider restoring from a recent backup. * Consider pruning excessive historical data by adjusting `ss-keep-recent` in `app.toml`, or run: ```bash enid unsafe-reset-all --home=$HOME/.eni --keep-addr-book ``` Alternatively, manually delete old state snapshots to free up space: ```bash rm -rf ~/.eni/data/snapshots/* ``` #### Diagnostic Commands ```bash # Check sync status enid status | jq .SyncInfo # View peer count enid net info | jq '.n_peers' # Check validator status enid query staking validator $(enid keys show -a $VALIDATOR_KEY) # View recent blocks enid query blocks recent ``` ### Security Considerations * Use a firewall and rate limiting to prevent attacks * Keep the system and node software updated * Secure SSH access with key-based authentication * Protect validator keys with offline storage or a hardware security module (HSM) For more in-depth system and configuration guidance, refer to the *\[Advanced Configuration and Monitoring Guide]*(./advanced-config-monitoring). # Validator Operations Guide This comprehensive guide explains how to operate an ENI validator node. We will cover the full lifecycle of a validator, from initial setup to ongoing operations and maintenance. Understanding these concepts is critical for maintaining reliable and secure validator operations. ### Understanding Validator Responsibilities Validators in the ENI network perform several key functions. As a validator, you are responsible for: * Participating in consensus by proposing and validating blocks * Maintaining high uptime and performance to avoid penalties * Providing accurate asset pricing oracle data * Managing delegator relationships and maintaining transparent operations * Participating in governance and network upgrades ### Initial Setup #### Key Management Validator security begins with proper key management. Your validator requires several distinct keys: ```bash # Validator Consensus Key - Used for signing blocks enid tendermint show-validator # Operator Key - Used for managing validator operations enid keys add operator # Oracle Key - Used for price submissions enid keys add oracle ``` These keys serve different purposes and should be managed with appropriate security measures. The consensus key, stored in `priv_validator_key.json`, is particularly critical as it is used to sign blocks. #### Hardware Security Module (HSM) Integration For production validators, using an HSM is strongly recommended. Here’s how to configure an HSM with your validator:
HSM Configuration Steps ```` ```bash # Install required libraries sudo apt-get install opensc pkcs11-utils # Configure YubiHSM2 yubihsm-connector -d # Generate a key in the HSM yubihsm-shell # Configure enid to use the HSM tee "$HOME/.eni/config/priv_validator_config.json" << EOF { "chain_id": "eni-chain", "key_type": "yubihsm", "state_file": "$HOME/.eni/data/priv_validator_state.json", "hsm_serial": "YOUR_HSM_SERIAL", "hsm_key_id": "YOUR_KEY_ID" } EOF ``` ````
### Oracle Price Feeder Setup As an ENI validator, you must run a price feeder to provide oracle data. This is critical for network operations. First, install the price feeder: ```bash cd eni-chain make install-price-feeder ``` Create a configuration file for your price feeder:
Price Feeder Configuration ```` ```toml gas_adjustment = 1.5 gas_prices = "0.01ueni" enable_server = true enable_voter = true provider_timeout = "500ms" [server] listen_addr = "0.0.0.0:7171" read_timeout = "20s" verbose_cors = true write_timeout = "20s" [keyring] backend = "file" dir = "/home/eni/.eni" [rpc] grpc_endpoint = "localhost:9090" rpc_timeout = "500ms" tmrpc_endpoint = "http://localhost:26657" [telemetry] enable_hostname = true enable_hostname_label = true enable_service_label = true prometheus_retention = 120 service_name = "price-feeder" [[provider_endpoints]] name = "binance" rest = "https://api1.binance.com" websocket = "stream.binance.com:9443" ``` ````
Start the price feeder as a service: ```bash sudo tee /etc/systemd/system/price-feeder.service << EOF [Unit] Description=ENI Price Feeder After=network-online.target [Service] User=$USER ExecStart=$(which price-feeder) /path/to/config.toml Restart=always RestartSec=3 LimitNOFILE=65535 [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable price-feeder sudo systemctl start price-feeder ``` ### Monitoring and Alerts #### Validator-Specific Metrics In addition to basic node monitoring, validators should track additional metrics: ```bash # Check validator status enid query staking validator $(enid keys show -a $VALIDATOR_KEY) # Monitor signing status enid query slashing signing-info $(enid tendermint show-validator) # Check current delegations enid query staking delegations-to $(enid keys show -a $VALIDATOR_KEY) ``` #### Alert Configuration Set up critical alerts for validator operations. Below are basic Prometheus alert rules:
Validator Alert Rules ```` ```yaml groups: - name: validator_alerts rules: - alert: ValidatorMissedBlocks expr: increase(tendermint_consensus_validator_missed_blocks[1h]) > 0 labels: severity: critical annotations: summary: 'Validator missed blocks' - alert: ValidatorJailed expr: tendermint_consensus_validator_status == 0 labels: severity: critical annotations: summary: 'Validator has been jailed' - alert: OraclePriceFeedDelay expr: time() - eni_oracle_price_timestamp > 300 labels: severity: critical annotations: summary: 'Oracle price feed delayed' ``` ````
### Security Practices #### Network Security Implement a sentry node architecture to protect your validator: ```bash # Validator node config.toml [p2p] pex = false persistent_peers = "sentry_node_id@sentry_node_ip:26656" private_peer_ids = "" addr_book_strict = false # Sentry node config.toml [p2p] pex = true private_peer_ids = "validator_node_id" addr_book_strict = true ``` #### Key Management Practices Implement a secure key backup procedure:
Key Backup Script ```` ```bash #!/bin/bash # Create an encrypted backup of validator keys BACKUP_DIR="/secure/validator/backup" DATE=$(date +%Y%m%d) # Backup validator key tar czf - $HOME/.eni/config/priv_validator_key.json | \ gpg --symmetric --cipher-algo AES256 \ -o $BACKUP_DIR/validator_key_$DATE.tar.gz.gpg # Backup keyring tar czf - $HOME/.eni/keyring-file | \ gpg --symmetric --cipher-algo AES256 \ -o $BACKUP_DIR/keyring_$DATE.tar.gz.gpg # Create SHA256 checksums sha256sum $BACKUP_DIR/*.gpg > $BACKUP_DIR/checksums_$DATE.txt ``` ````
### Maintenance Procedures #### Scheduled Maintenance When performing scheduled maintenance: ```bash # Notify delegators (recommended at least 24 hours in advance) # Consider posting to: # - On-chain governance forum # - Social media channels # - Validator website # Gracefully stop the validator sudo systemctl stop enid # Perform maintenance tasks # Restart services sudo systemctl start enid sudo systemctl start price-feeder ``` #### Emergency Procedures Create an emergency response plan:
Emergency Response Procedures ```` ```bash # 1. If double-signing is detected: sudo systemctl stop enid # Check priv_validator_state.json # Contact team and delegators # 2. If node is stuck: enid status # Check for consensus failure journalctl -u enid -n 100 # Attempt a safe restart sudo systemctl restart enid # 3. If oracle feed fails: systemctl status price-feeder # Check price-feeder logs journalctl -u price-feeder -n 100 # Restart if necessary sudo systemctl restart price-feeder ``` ````
### Governance Participation As a validator, you have a responsibility to participate in governance. Monitor and vote on proposals: ```bash # List active proposals enid query gov proposals --status voting_period # Vote on a proposal enid tx gov vote 1 yes \ --from operator \ --chain-id eni-chain \ --gas auto \ --gas-prices 0.01ueni ``` ### Validator Economics Understanding validator economics is critical for long-term success: * **Commission Rate Strategy**: Set competitive rates while ensuring operational sustainability * **Delegation Management**: Maintain good delegator relationships through transparent communication * **Reward Distribution**: Rewards are distributed in real-time as blocks are produced * **Penalty Risks**: Understand and mitigate penalty risks through proper operations ### Recovery Procedures #### Validator Recovery If you need to recover your validator on a new machine: ```bash # 1. Set up a new machine with Eni node # 2. Copy secure backup files # 3. Restore validator key gpg -d validator_key_backup.tar.gz.gpg | tar xzf - # 4. Restore keyring gpg -d keyring_backup.tar.gz.gpg | tar xzf - # 5. Start services sudo systemctl start enid sudo systemctl start price-feeder ``` This guide provides the foundation for operating an ENI validator. Keep in mind that validator operations require ongoing attention to security, performance, and network participation. Stay engaged with the ENI community and keep informed about network developments. # Advanced Configuration & Monitoring This guide covers advanced configuration options and comprehensive monitoring setups for ENI nodes. We will explore performance tuning, monitoring infrastructure, and alerting systems. ### Performance Tuning #### Memory Management The following settings optimize memory usage and disk I/O patterns. Add these to `/etc/sysctl.conf`: ```bash # Minimize swapping vm.swappiness = 1 # Control disk write behavior vm.dirty_background_ratio = 3 vm.dirty_ratio = 10 vm.dirty_expire_centisecs = 300 vm.dirty_writeback_centisecs = 100 ``` Apply the changes: ```bash sudo sysctl -p ``` #### Network Stack Optimization These settings improve network performance. Add to `/etc/sysctl.conf`: ```bash # Increase connection handling capacity net.core.somaxconn = 32768 net.core.netdev_max_backlog = 32768 net.ipv4.tcp_max_syn_backlog = 16384 # Optimize buffer sizes net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 87380 16777216 ``` #### Storage Configuration For NVMe drives, optimize I/O scheduling: Storage Optimization Commands ```bash # Set IO scheduler echo "none" > /sys/block/nvme0n1/queue/scheduler # Set read-ahead buffer blockdev --setra 4096 /dev/nvme0n1 # Set IO priority in systemd service sudo tee -a /etc/systemd/system/enid.service << EOF [Service] IOSchedulingClass=realtime IOSchedulingPriority=2 EOF # Configure disk mount options sudo tee -a /etc/fstab << EOF /dev/nvme0n1p1 /data ext4 defaults,noatime,nosuid,nodev,noexec,commit=60 0 0 EOF ``` ### Monitoring Setup #### Prometheus Configuration First, install Prometheus: ```bash wget https://github.com/prometheus/prometheus/releases/download/v2.42.0/prometheus-2.42.0.linux-amd64.tar.gz tar xvf prometheus-2.42.0.linux-amd64.tar.gz ``` Create a Prometheus configuration: ```yaml global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'eni_node' static_configs: - targets: ['localhost:26660'] metrics_path: /metrics ``` #### Grafana Dashboard Setup Install and configure Grafana: ```bash sudo apt-get install -y apt-transport-https software-properties-common sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main" sudo apt-get update && sudo apt-get install grafana ```
Example Grafana Dashboard JSON ```json { "annotations": { "list": [ { "builtIn": 1, "datasource": "-- Grafana --", "enable": true, "hide": true, "iconColor": "rgba(0, 211, 255, 1)", "name": "Annotations & Alerts", "type": "dashboard" } ] }, "editable": true, "gnetId": null, "graphTooltip": 0, "id": 1, "links": [], "panels": [ { "alerting": {}, "aliasColors": {}, "bars": false, "dashLength": 10, "dashes": false, "datasource": null, "fieldConfig": { "defaults": { "custom": {} }, "overrides": [] }, "fill": 1, "fillGradient": 0, "gridPos": { "h": 8, "w": 12, "x": 0, "y": 0 }, "hiddenSeries": false, "id": 2, "legend": { "avg": false, "current": false, "max": false, "min": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "nullPointMode": "null", "options": { "alertThreshold": true }, "percentage": false, "pluginVersion": "7.2.0", "pointradius": 2, "points": false, "renderer": "flot", "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "tendermint_consensus_height", "interval": "", "legendFormat": "", "refId": "A" } ], "thresholds": [], "timeRegions": [], "title": "Block Height", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } } ], "schemaVersion": 26, "style": "dark", "tags": [], "templating": { "list": [] }, "time": { "from": "now-6h", "to": "now" }, "timepicker": {}, "timezone": "", "title": "Eni Node Metrics", "uid": "eni_metrics", "version": 1 } ```
#### Alert Configuration Set up alerting with Alertmanager: ```bash wget https://github.com/prometheus/alertmanager/releases/download/v0.25.0/alertmanager-0.25.0.linux-amd64.tar.gz tar xvf alertmanager-0.25.0.linux-amd64.tar.gz ``` Create alerting rules: ```yaml groups: - name: eni_alerts rules: - alert: NodeDown expr: up == 0 for: 5m labels: severity: critical annotations: summary: 'Node {{ $labels.instance }} down' - alert: BlockProductionSlow expr: rate(tendermint_consensus_height[5m]) < 0.1 for: 5m labels: severity: warning annotations: summary: 'Block production is slow on {{ $labels.instance }}' ``` ### Log Management #### Loki Setup Install and configure Loki for log aggregation: ```bash wget https://github.com/grafana/loki/releases/download/v2.8.0/loki-linux-amd64.zip unzip loki-linux-amd64.zip ``` Configure Promtail to send logs: ```yaml server: http_listen_port: 9080 positions: filename: /tmp/positions.yaml clients: - url: http://localhost:3100/loki/api/v1/push scrape_configs: - job_name: eni_logs static_configs: - targets: - localhost labels: job: enid_logs __path__: /var/log/enid/*.log ``` #### Log Rotation Configure logrotate to manage log files: ```bash sudo tee /etc/logrotate.d/eni << EOF /var/log/eni/*.log { daily rotate 14 compress delaycompress notifempty create 0640 eni eni sharedscripts postrotate systemctl reload enid endscript } EOF ``` ### Advanced Security Configuration #### Network Security Configure UFW firewall rules: ```bash sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 26656/tcp comment 'ENI P2P' sudo ufw allow 26657/tcp comment 'ENI RPC' sudo ufw allow 9090/tcp comment 'ENI gRPC' sudo ufw enable ``` #### Rate Limiting Configure nginx as a reverse proxy with rate limiting: ```nginx http { limit_req_zone $binary_remote_addr zone=eni_rpc:10m rate=10r/s; server { listen 26657; location / { limit_req zone=eni_rpc burst=20 nodelay; proxy_pass http://localhost:26657; } } } ``` ### Backup and Recovery #### Automated Backup Script Create a comprehensive backup script:
Backup Script ```bash #!/bin/bash BACKUP_DIR="/backup/eni" DATE=$(date +%Y%m%d) NODE_HOME="/root/.eni" # Create backup directory mkdir -p $BACKUP_DIR # Stop service systemctl stop enid # Backup configuration tar czf $BACKUP_DIR/eni-config-$DATE.tar.gz $NODE_HOME/config # Backup data directory tar czf $BACKUP_DIR/eni-data-$DATE.tar.gz $NODE_HOME/data # Backup key files tar czf $BACKUP_DIR/eni-keys-$DATE.tar.gz $NODE_HOME/keyring-file # Start service systemctl start enid # Remove backups older than 7 days find $BACKUP_DIR -type f -mtime +7 -name '*.tar.gz' -delete # Log backup completion echo "Backup completed successfully on $(date)" >> $BACKUP_DIR/backup.log ```
### Performance Monitoring #### Resource Usage Tracking Install and configure node\_exporter: ```bash wget https://github.com/prometheus/node_exporter/releases/download/v1.5.0/node_exporter-1.5.0.linux-amd64.tar.gz tar xvf node_exporter-1.5.0.linux-amd64.tar.gz ``` Add to Prometheus configuration: ```yaml scrape_configs: - job_name: 'node' static_configs: - targets: ['localhost:9100'] ``` #### Performance Benchmarking Create a benchmarking script to test node performance: Benchmarking Script ```bash #!/bin/bash # Test RPC endpoint response time curl -s -w "\nResponse time: %{time_total}s\n" -o /dev/null http://localhost:26657/status # Test P2P connectivity enid net_info | jq '.result.n_peers' # Test transaction processing enid tx bank send \ $(enid keys show -a test1) \ $(enid keys show -a test2) \ 1000000ueni \ --chain-id $CHAIN_ID \ --fees 5000ueni \ -y ``` This guide provides advanced configuration options and monitoring setup instructions. For specific customizations or additional metrics, consult the ENI technical community. # Technical Reference This guide serves as a comprehensive reference for ENI node operators and validators, providing detailed command syntax, configuration parameters, and troubleshooting procedures. For API documentation, refer to our API documentation section. ### Command Line Interface Reference The `enid` binary provides extensive functionality to manage your ENI node. Understanding these commands is critical for effective node operation and troubleshooting. #### Node Management Commands These commands help you control and monitor node operations: ```bash # Start the node enid start [flags] # Display node status enid status # Display validator consensus key enid tendermint show-validator # Query node information enid query node info ``` #### Key Management Proper key management is essential for security. These commands help you manage keys effectively: ```bash # Create a new key enid keys add [flags] # List all keys enid keys list # Delete a key enid keys delete # Export a key (encrypted) enid keys export # Import a key enid keys import # Display key address enid keys show -a ``` #### Transaction Commands These commands allow you to interact with the blockchain: ```bash # Send tokens enid tx bank send ueni [flags] # Delegate tokens enid tx staking delegate ueni --from # Withdraw rewards enid tx distribution withdraw-rewards --from # Edit validator enid tx staking edit-validator [flags] --from ``` ### Configuration Parameters Understanding configuration parameters is crucial for optimizing node performance and security. #### App.toml Parameters The `app.toml` file controls application-specific settings:
Complete app.toml Configuration ```` ```toml # Minimum gas prices for accepting transactions minimum-gas-prices = "0.01ueni" # API Configuration [api] enable = true swagger = true address = "tcp://0.0.0.0:1317" max-open-connections = 1000 # State Sync Configuration [state-sync] snapshot-interval = 1000 snapshot-keep-recent = 2 # Mempool Management [mempool] size = 5000 max-txs-bytes = 1073741824 cache-size = 10000 # State Store Configuration [state-store] ss-enable = true ss-backend = "pebbledb" ss-keep-recent = 100000 ss-prune-interval = 600 ``` ````
#### Config.toml Parameters The `config.toml` file controls the core consensus engine and networking:
Complete config.toml Configuration ```` ```toml # P2P Configuration [p2p] laddr = "tcp://0.0.0.0:26656" external_address = "" seeds = "" persistent_peers = "" upnp = false max_num_inbound_peers = 40 max_num_outbound_peers = 10 allowed_pools = "" max_packet_msg_payload_size = 10240 handshake_timeout = "20s" dial_timeout = "3s" # RPC Configuration [rpc] laddr = "tcp://0.0.0.0:26657" cors_allowed_origins = [] cors_allowed_methods = ["HEAD", "GET", "POST"] cors_allowed_headers = ["Origin", "Accept", "Content-Type", "X-Requested-With", "X-Server-Time"] max_open_connections = 900 timeout_broadcast_tx_commit = "10s" # Consensus Configuration [consensus] wal_file = "data/cs.wal/wal" timeout_propose = "3s" timeout_propose_delta = "500ms" timeout_prevote = "1s" timeout_prevote_delta = "500ms" timeout_precommit = "1s" timeout_precommit_delta = "500ms" timeout_commit = "1s" double_sign_check_height = 0 ``` ````
### Error Codes and Troubleshooting #### Common Error Codes Below are the most common errors you may encounter and their solutions: **Consensus Errors** When facing consensus errors, quick and appropriate action is critical: ``` Error: "Consensus Failure - Height Halted" Solution: Check for network upgrades or chain halts Command: enid status | jq .sync_info Error: "Private Validator File Not Found" Solution: Restore validator key or check file permissions Location: ~/.eni/config/priv_validator_key.json Error: "Duplicate Signature" Solution: Stop the node immediately - potential double-signing risk Action: Check for validator operations on other machines ``` **Network Errors** Network errors may prevent your node from participating in consensus: ``` Error: "Dial TCP Connection Refused" Solution: Check network connectivity and firewall rules Commands: - netstat -tulpn | grep enid - ufw status Error: "No Peers Available" Solution: Verify peer connections and network configuration Commands: - enid net_info - curl localhost:26657/net_info ``` **Database Errors** Database corruption may require immediate attention: ``` Error: "Database Corrupted" Solution: Reset the database or restore from backup Commands: - enid tendermint unsafe-reset-all - cp -r backup/data ~/.eni/ ``` #### Diagnostic Commands These commands help you investigate issues and monitor the node: ```bash # Check node synchronization enid status | jq '.sync_info' # View peer connections enid net_info | jq '.result.peers[] | {node_info: {id: .node_info.id, moniker: .node_info.moniker}}' # Check validator status enid query staking validator $(enid tendermint show-validator) # Monitor logs in real-time journalctl -u enid -f -o cat # View system resource usage top -p $(pgrep enid) ``` ### Network Parameters Understanding network parameters helps you operate your node effectively. #### Chain Parameters These parameters define the network's behavior: ``` Block Time: Target 1 second Maximum Validators: 100 Unbonding Period: 21 days Punishment Conditions: - Downtime: 0.01% - Double Signing: 5% - Oracle Miss: 0.01% Minimum Self-Delegation: 1 ENI Maximum Commission Rate: 20% Maximum Commission Change Rate: 1% per day ``` #### Port Configuration Understanding port usage is crucial for network configuration: ``` 26656: P2P Communication 26657: RPC Interface 1317: REST API 9090: gRPC 26660: Prometheus Metrics ``` ### File Locations Knowing the purpose and location of key files aids in maintenance and troubleshooting: ``` ~/.eni/ ├── config/ │ ├── app.toml # Application configuration │ ├── client.toml # Client configuration │ ├── config.toml # Tendermint configuration │ ├── genesis.json # Chain genesis file │ ├── node_key.json # Node identity key │ └── priv_validator_key.json # Validator signing key ├── data/ │ ├── application.db # Application state │ ├── blockstore.db # Block data │ ├── cs.wal/ # Consensus write-ahead log │ ├── evidence.db # Evidence of misbehavior │ ├── state.db # Tendermint state │ └── tx_index.db # Transaction index └── keyring-file/ # Local key storage ``` This reference guide provides essential technical information for operating ENI nodes and validators. For API documentation and other detailed specifications, refer to the corresponding sections in our documentation set. # Overview **Reference Overview** Welcome to the Reference section of the ENI documentation. This section provides key technical resources for interacting with the ENI network. **enid** **enid** is a command-line tool for interacting with the ENI network. It allows you to manage nodes, query blockchain data, and process transactions, providing the essential tools needed to operate within the network. **API Reference** The API Reference contains detailed documentation for programmatically interacting with the ENI network via REST and gRPC APIs. You will find endpoints for querying data, submitting transactions, and interacting with both the Cosmos and EVM layers. * **Cosmos Endpoints**: APIs that provide core Cosmos functionality, such as staking, governance, and chain queries. * **EVM Endpoints**: Detailed APIs for interacting with Ethereum-compatible smart contracts deployed on the ENI network. **EVM Precompiled Contracts** EVM Precompiled Contracts are built-in contracts on the ENI EVM, offering optimized functionality for specific operations. # enid ## Command Line Interface Reference `enid` is a command line interface for interacting with the ENI blockchain. It is a powerful tool that allows you to interact with the ENI blockchain from the command line. This documentation provides a reference for the `enid` command line interface. ### Common Commands #### `enid` ```ansi Launch the eni application Usage: enid [command] Available commands: add-genesis-account Add a genesis account to genesis.json add-wasm-genesis-message Wasm genesis subcommand blocktest Run EF block tests collect-gentxs Collect genesis transactions and output genesis.json file compact Fully compact the application database (only for levelDB) config Create or query application CLI configuration file debug Tools for helping to debug the application ethreplay Replay EVM transactions export Export state to JSON gentx Generate genesis transactions with self-delegation help Help about any command init Initialize private validator, p2p, genesis, and application configuration files keys Manage application keys latest_version Print the latest version of the application database migrate Migrate genesis to the specified target version prune Prune application history state by keeping recent heights and deleting old heights query Query subcommands rollback Roll back cosmos-sdk and tendermint state by one height start Run a full node status Query the status of a remote node tendermint Tendermint subcommands tools A set of useful tools for the eni chain tx Transaction subcommands validate-genesis Validate the genesis file in the default location or the path provided version Print the application binary version information Flags: -h, --help Help information for enid --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error Use "enid [command] --help" to obtain more information about a command. ``` # CLI # enid add-genesis-account #### `enid add-genesis-account` ```ansi Add a genesis account to genesis.json. The provided account must specify either an account address or key name, along with an initial list of tokens. If a key name is given, the address will be looked up in the local Keybase. The initial token list must contain valid denominations. If using keyring-backend test, you can optionally provide vesting parameters for the account. An association between the eni address and the eth address will also be created here. Usage: enid add-genesis-account [address_or_key_name] [coin][,[coin]] [flags] Flags: --height int Query state at a specific height (this may fail if the node is pruning state) -h, --help Help information for add-genesis-account --home string Application home directory (default "~/.eni") --keyring-backend string Choose the keyring backend (os|file|kwallet|pass|test) (default "os") --node string : to the Tendermint RPC interface for this chain (default "tcp://localhost:26657") -o, --output string Output format (text|json) (default "text") --vesting-amount string Amount of tokens for the vesting account --vesting-end-time int Scheduled end time for the vesting account (unix epoch) --vesting-start-time int Scheduled start time for the vesting account (unix epoch) Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid blocktest #### `enid blocktest` ```ansi Run EF block tests Usage: enid blocktest [flags] Flags: --block-test string Path to the block test JSON file --chain-id string Chain ID (default "eni-chain") -h, --help Help information for blocktest --home string Database home directory (default "~/.eni") --test-name string Name of the individual test Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid collect-gentxs #### `enid collect-gentxs` ```ansi Collect genesis transactions and output the genesis.json file Usage: enid collect-gentxs [flags] Flags: --gentx-dir string Override the default "gentx" directory from which to collect and execute genesis transactions; default is [--home]/config/gentx/ -h, --help Help information for collect-gentxs --home string Application home directory (default "~/.eni") Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid compact #### `enid compact` ```ansi Fully compact the application database (only when it is levelDB) Usage: enid compact [flags] Flags: -h, --help Help information for compact --home string Node's home directory (default "~/.eni") Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid config #### `enid config` ```ansi Create or query the application CLI configuration file Usage: enid config [value] [flags] Flags: -h, --help Help information for config Global Flags: --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid debug #### `enid debug` ```ansi Debugging tools for the application Usage: enid debug [flags] enid debug [command] Available Commands: addr Convert addresses between hexadecimal and bech32 dump-iavl Dump IAVL data at a specific height pubkey Decode a public key from proto JSON raw-bytes Convert raw bytes output (e.g., [10 21 13 255]) to hexadecimal Flags: -h, --help Help information for debug Global Flags: --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error Use "enid debug [command] --help" for more information about a command. ``` # enid export #### `enid export` ```ansi Export the state as JSON Usage: enid export [flags] Flags: --chain-id string Chain ID --for-zero-height Export state starting from height zero (perform preprocessing) --height int Export state from a specific height (-1 for latest height) (default -1) -h, --help Help information for export --home string Application home directory (default "~/.eni") --jail-allowed-addrs strings Comma-separated list of jailed validator operator addresses for unjailing Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid gentx #### `enid gentx` ```ansi Generate a genesis transaction that creates a validator with self-delegation, signed by the key referenced by the given name in the keyring. Optionally, you can provide a node ID and Bech32 consensus public key. If omitted, they will be retrieved from the priv_validator.json file. The following default parameters are included: Delegation Amount: 100000000ueni Commission Rate: 0.1 Commission Max Rate: 0.2 Commission Max Change Rate: 0.01 Minimum Self-Delegation: 1 Example: $ gentx my-key-name 1000000stake --home=/path/to/home/dir --keyring-backend=os --chain-id=test-chain-1 \ --moniker="myvalidator" \ --commission-max-change-rate=0.01 \ --commission-max-rate=1.0 \ --commission-rate=0.07 \ --details="..." \ --security-contact="..." \ --website="..." Usage: enid gentx [key_name] [amount] [flags] Flags: -a, --account-number uint Account number of the signing account (offline mode only) --amount string Amount of bonded coins -b, --broadcast-mode string Transaction broadcast mode (sync|async|block) (default "sync") --chain-id string Network chain ID --commission-max-change-rate string Maximum commission change rate percentage (daily) --commission-rate string Initial commission rate percentage --details string (optional) Details of the validator --dry-run Ignore the --gas flag and simulate the transaction without broadcasting (when enabled, local Keybase is inaccessible) --fee-account string Fee account to pay for the transaction fees, instead of deducting from the signer --fees string Pay transaction fees; e.g., 10uatom --from string Name or address of the private key to use for signing --gas string Gas limit set for each transaction; set to "auto" to automatically calculate sufficient gas (default 200000) --gas-adjustment float Adjustment factor multiplied by the estimated value returned from tx simulation; ignored if gas limit is manually set (default 1) --gas-prices string Decimal format of gas prices to determine transaction fees (e.g., 0.1uatom) --generate-only Build an unsigned transaction and write it to STDOUT (when enabled, only access local Keybase when a key name is provided) -h, --help Help information for gentx --home string Application home directory (default "~/.eni") --identity string (optional) Identity signature (e.g., UPort or Keybase) --ip string Public IP of the node (default "192.168.0.160") --keyring-backend string Choose the backend for the keyring (os|file|kwallet|pass|test|memory) (default "os") --keyring-dir string Client keyring directory; if omitted, the default "home" directory will be used --ledger Use connected Ledger device --min-self-delegation string Minimum self-delegation required by the validator --moniker string (optional) Alias for the validator --node string : to this chain's tendermint rpc interface (default "tcp://localhost:26657") --node-id string Node's NodeID --note string Add a note to the transaction description (formerly --memo) --offline Offline mode (no online functionality allowed) -o, --output string Output format (text|json) (default "json") --output-document string Write the genesis transaction JSON document to the given file, instead of the default location --p2p-port string Public IP port of the node (default "26656") --pubkey string Protobuf JSON-encoded public key of the validator --security-contact string (optional) Security contact email for the validator -s, --sequence uint Sequence number of the signing account (offline mode only) --sign-mode string Choose the signing mode (direct|amino-json), which is an advanced feature --timeout-height uint Set the block timeout height to prevent the transaction from being committed after exceeding a certain height --website string (optional) Website of the validator -y, --yes Skip the transaction broadcast prompt confirmation Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid help #### `enid help` ```ansi Provides help for any command in the application. Simply type enid help [command path] for full details. Usage: enid help [command] [flags] Flags: -h, --help Help information for help Global Flags: --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid init #### `enid init` ```ansi Initialize the configuration files for the validator and node. Usage: enid init [moniker] [flags] Flags: --chain-id string Chain ID for the genesis file; if left empty, will use 'eni' -h, --help Help information for init --home string Home directory of the node (default "~/.eni") -o, --overwrite Overwrite the genesis.json file --recover Provide a seed phrase to recover existing keys instead of creating new ones Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid keys #### `enid keys` ```ansi Keyring management commands. These keys can be in any format supported by the Tendermint cryptography library and can be used by light clients, full nodes, or any other applications that require private key signing. The keyring supports the following backends: os Uses the operating system's default credential store. file Uses an encrypted file keystore in the application configuration directory. A password will be requested each time this keyring is accessed, which may lead to repeated password prompts within a single command. kwallet Uses KDE Wallet Manager as a credential management application. pass Uses the pass command line tool to store and retrieve keys. test Unsafely stores keys to disk. It will not prompt for a password to unlock; should only be used for testing purposes. The kwallet and pass backends rely on external tools. For more information, refer to their respective documentation: KWallet https://github.com/KDE/kwallet pass https://www.passwordstore.org/ The pass backend requires GnuPG: https://gnupg.org/ Usage: enid keys [command] Available Commands: add Add an encrypted private key (newly generated or recovered) and save it to delete Delete the specified key export Export the private key import Import a private key into the local keystore list List all keys mnemonic Generate a BIP39 mnemonic from some input entropy parse Parse an address from hex to bech32 and vice versa show Retrieve key information by name or address Flags: -h, --help Help information for keys --home string Application home directory (default "~/.eni") --keyring-backend string Choose the backend for the keyring (os|file|test) (default "os") --keyring-dir string Client keyring directory; if omitted, the default "home" directory will be used --output string Output format (text|json) (default "text") Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error Use "enid keys [command] --help" for more information about a command. ``` # enid keys delete ```ansi Delete keys from the Keybase backend. Note that removing offline or ledger keys will remove only the public key references stored locally, i.e. private keys stored in a ledger device cannot be deleted with the CLI. Usage: enid keys delete ... [flags] Flags: -f, --force Remove the key unconditionally without asking for the passphrase. Deprecated. -h, --help help for delete -y, --yes Skip confirmation prompt when deleting offline or ledger key references Global Flags: --home string The application home directory (default "~/.eni") --keyring-backend string Select keyring's backend (os|file|test) (default "os") --keyring-dir string The client Keyring directory; if omitted, the default 'home' directory will be used --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --output string Output format (text|json) (default "text") --trace print out full stack trace on errors ``` # enid keys add ```ansi Derive a new private key and encrypt to disk. Optionally specify a BIP39 mnemonic, a BIP39 passphrase to further secure the mnemonic, and a bip32 HD path to derive a specific account. The key will be stored under the given name and encrypted with the given password. The only input that is required is the encryption password. If run with -i, it will prompt the user for BIP44 path, BIP39 mnemonic, and passphrase. The flag --recover allows one to recover a key from a seed passphrase. If run with --dry-run, a key would be generated (or recovered) but not stored to the local keystore. Use the --pubkey flag to add arbitrary public keys to the keystore for constructing multisig transactions. You can create and store a multisig key by passing the list of key names stored in a keyring and the minimum number of signatures required through --multisig-threshold. The keys are sorted by address, unless the flag --nosort is set. Example: keys add mymultisig --multisig "keyname1,keyname2,keyname3" --multisig-threshold 2 Usage: enid keys add [flags] Flags: --account uint32 Account number for HD derivation --algo string Key signing algorithm to generate keys for (default "secp256k1") --coin-type uint32 coin type number for HD derivation (default 118) --dry-run Perform action, but don't add key to local keystore --hd-path string Manual HD Path derivation (overrides BIP44 config) -h, --help help for add --index uint32 Address index number for HD derivation -i, --interactive Interactively prompt user for BIP39 passphrase and mnemonic --ledger Store a local reference to a private key on a Ledger device --multisig strings List of key names stored in keyring to construct a public legacy multisig key --multisig-threshold int K out of N required signatures. For use in conjunction with --multisig (default 1) --no-backup Don't print out seed phrase (if others are watching the terminal) --nosort Keys passed to --multisig are taken in the order they're supplied --pubkey string Parse a public key in JSON format and saves key info to file. --recover Provide seed phrase to recover existing key instead of creating Global Flags: --home string The application home directory (default "~/.eni") --keyring-backend string Select keyring's backend (os|file|test) (default "os") --keyring-dir string The client Keyring directory; if omitted, the default 'home' directory will be used --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --output string Output format (text|json) (default "text") --trace print out full stack trace on errors ``` # enid keys export ```ansi Export a private key from the local keyring in ASCII-armored encrypted format. When both the --unarmored-hex and --unsafe flags are selected, cryptographic private key material is exported in an INSECURE fashion that is designed to allow users to import their keys in hot wallets. This feature is for advanced users only that are confident about how to handle private keys work and are FULLY AWARE OF THE RISKS. If you are unsure, you may want to do some research and export your keys in ASCII-armored encrypted format. Usage: enid keys export [flags] Flags: -h, --help help for export --unarmored-hex Export unarmored hex privkey. Requires --unsafe. --unsafe Enable unsafe operations. This flag must be switched on along with all unsafe operation-specific options. Global Flags: --home string The application home directory (default "~/.eni") --keyring-backend string Select keyring's backend (os|file|test) (default "os") --keyring-dir string The client Keyring directory; if omitted, the default 'home' directory will be used --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --output string Output format (text|json) (default "text") --trace print out full stack trace on errors ``` # enid keys import ```ansi Import a ASCII armored private key into the local keybase. Usage: enid keys import [flags] Flags: -h, --help help for import Global Flags: --home string The application home directory (default "~/.eni") --keyring-backend string Select keyring's backend (os|file|test) (default "os") --keyring-dir string The client Keyring directory; if omitted, the default 'home' directory will be used --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --output string Output format (text|json) (default "text") --trace print out full stack trace on errors ``` # enid keys list ```ansi Return a list of all public keys stored by this key manager along with their associated name and address. Usage: enid keys list [flags] Flags: -h, --help help for list -n, --list-names List names only Global Flags: --home string The application home directory (default "~/.eni") --keyring-backend string Select keyring's backend (os|file|test) (default "os") --keyring-dir string The client Keyring directory; if omitted, the default 'home' directory will be used --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --output string Output format (text|json) (default "text") --trace print out full stack trace on errors ``` # enid keys mnemonic ```ansi Create a bip39 mnemonic, sometimes called a seed phrase, by reading from the system entropy. To pass your own entropy, use --unsafe-entropy Usage: enid keys mnemonic [flags] Flags: -h, --help help for mnemonic --unsafe-entropy Prompt the user to supply their own entropy, instead of relying on the system Global Flags: --home string The application home directory (default "~/.eni") --keyring-backend string Select keyring's backend (os|file|test) (default "os") --keyring-dir string The client Keyring directory; if omitted, the default 'home' directory will be used --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --output string Output format (text|json) (default "text") --trace print out full stack trace on errors ``` # enid keys parse ```ansi Convert and print to stdout key addresses and fingerprints from hexadecimal into bech32 cosmos prefixed format and vice versa. Usage: enid keys parse [flags] Flags: -h, --help help for parse Global Flags: --home string The application home directory (default "~/.eni") --keyring-backend string Select keyring's backend (os|file|test) (default "os") --keyring-dir string The client Keyring directory; if omitted, the default 'home' directory will be used --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --output string Output format (text|json) (default "text") --trace print out full stack trace on errors ``` # enid keys show ```ansi Display keys details. If multiple names or addresses are provided, then an ephemeral multisig key will be created under the name "multi" consisting of all the keys provided by name and multisig threshold. Usage: enid keys show [name_or_address [name_or_address...]] [flags] Flags: -a, --address Output the address only (overrides --output) --bech string The Bech32 prefix encoding for a key (acc|val|cons) (default "acc") -d, --device Output the address in a ledger device -h, --help help for show --multisig-threshold int K out of N required signatures (default 1) -p, --pubkey Output the public key only (overrides --output) Global Flags: --home string The application home directory (default "~/.eni") --keyring-backend string Select keyring's backend (os|file|test) (default "os") --keyring-dir string The client Keyring directory; if omitted, the default 'home' directory will be used --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --output string Output format (text|json) (default "text") --trace print out full stack trace on errors ``` # enid latest\_version #### `enid latest_version` ```ansi Prints the latest version of the application's database. Usage: enid latest_version [flags] Flags: -h, --help Help information for latest_version --home string Application home directory (default "~/.eni") Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid migrate #### `enid migrate` ```ansi Migrates the source genesis file to the target version and prints to STDOUT. Example: $ migrate v0.36 /path/to/genesis.json --chain-id=cosmoshub-3 --genesis-time=2019-04-22T17:00:00Z Usage: enid migrate [target-version] [genesis-file] [flags] Flags: --chain-id string Override the chain_id with this flag --genesis-time string Override the genesis_time with this flag -h, --help Help information for migrate Global Flags: --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid prune #### `enid prune` ```ansi Prunes the application's historical state by keeping recent heights and deleting older ones. Pruning options are provided via the `--pruning` flag or `--pruning-keep-recent`. For the `--pruning` flag, the options are as follows: - default: Keeps the most recent 362880 states - nothing: Saves all historical states; nothing will be deleted (i.e., archive node) - everything: Keeps only the most recent 2 states - custom: Allows manual specification of pruning options via `pruning-keep-recent`. In addition to pruning options, the database home directory and backend type should be specified using the `--home` and `--app-db-backend` flags. Valid app-db-backend types include `goleveldb`, `cleveldb`, `rocksdb`, `boltdb`, and `badgerdb`. Usage: enid prune [flags] Example: prune --home './' --app-db-backend 'goleveldb' --pruning 'custom' --pruning-keep-recent 100 --pruning-keep-every 10 --pruning-interval 10 Flags: --app-db-backend string Database type for the application and snapshot database --chain-id string Chain ID -h, --help Help information for prune --home string Database home directory --pruning string Pruning strategy (default|nothing|everything|custom) (default "default") --pruning-interval uint Height interval to delete pruned heights on disk (ignored if pruning is not 'custom'), This option is retained for compatibility with full pruning options (default 10) --pruning-keep-every uint Offset heights retained on disk after 'keep-every' (ignored if pruning is not 'custom'), This option is retained for compatibility with full pruning options --pruning-keep-recent uint Number of recent heights to keep on disk (ignored if pruning is not 'custom') Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid query #### `enid query` ```ansi Query subcommand Usage: enid query [flags] enid query [command] Aliases: query, q Available Commands: accesscontrol Query commands for the access control module account Query an account by address auth Query commands for the authentication module authz Query commands for the authorization module bank Query commands for the bank module block Get the validator data for the block at a given height dex Query commands for the decentralized exchange module distribution Query commands for the distribution module epoch Query commands for the epoch module evidence Query evidence by hash or all submitted evidence (pagination) evm Query commands for the Ethereum Virtual Machine module feegrant Query commands for the fee grant module gov Query commands for the governance module ibc Query commands for the inter-blockchain communication module ibc-transfer Subcommand to query alternative token transfers in inter-blockchain communication mint Query commands for the mint module oracle Query commands for the oracle module params Query commands for the parameters module slashing Query commands for the slashing module staking Query commands for the staking module tendermint-validator-set Query the complete Tendermint validator set at a given height tokenfactory Query commands for the token factory module tx Query transactions by hash, "/" combination, or by comma-separated signatures in a submitted block txs Query paginated transactions that match a set of events upgrade Query commands for the upgrade module wasm Query commands for the WebAssembly module Flags: --chain-id string Network chain ID -h, --help Help information for query Global Flags: --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error Use "enid query [command] --help" for more information about a command. ``` # enid query accesscontrol ```ansi Querying commands for the accesscontrol module Usage: enid query accesscontrol [flags] enid query accesscontrol [command] Available Commands: list-resource-dependency-mapping List all resource dependency mappings list-wasm-dependency-mapping List all wasm contract dependency mappings params Get the params for the x/accesscontrol module resource-dependency-mapping Get the resource dependency mapping for a specific message key wasm-dependency-mapping Get the wasm contract dependency mapping for a specific contract address Flags: -h, --help help for accesscontrol Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query accesscontrol [command] --help" for more information about a command. ``` # enid query upgrade ```ansi Querying commands for the upgrade module Usage: enid query upgrade [command] Available Commands: applied block header for height at which a completed upgrade was applied module_versions get the list of module versions plan get upgrade plan (if one exists) Flags: -h, --help help for upgrade Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query upgrade [command] --help" for more information about a command. ``` # enid query account ```ansi Query for account by address Usage: enid query account [address] [flags] Flags: --height int Use a specific height to query state at (this can error if the node is pruning state) -h, --help help for account --node string : to Tendermint RPC interface for this chain (default "tcp://localhost:26657") -o, --output string Output format (text|json) (default "text") Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors ``` # enid query auth ```ansi Querying commands for the auth module Usage: enid query auth [flags] enid query auth [command] Available Commands: account Query for account by address accounts Query all the accounts next-account-number Query the next account number params Query the current auth parameters Flags: -h, --help help for auth Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query auth [command] --help" for more information about a command. ``` # enid query bank ```ansi Querying commands for the bank module Usage: enid query bank [flags] enid query bank [command] Available Commands: balances Query for account balances by address denom-metadata Query the client metadata for coin denominations total Query the total supply of coins of the chain Flags: -h, --help help for bank Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query bank [command] --help" for more information about a command. ``` # enid query block ```ansi Get verified data for a the block at given height Usage: enid query block [height] [flags] Flags: -h, --help help for block -n, --node string Node to connect to (default "tcp://localhost:26657") Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors ``` # enid query authz ```ansi Querying commands for the authz module Usage: enid query authz [flags] enid query authz [command] Available Commands: grants query grants for a granter-grantee pair and optionally a msg-type-url grants-by-grantee query authorization grants granted to a grantee grants-by-granter query authorization grants granted by granter Flags: -h, --help help for authz Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query authz [command] --help" for more information about a command. ``` # enid query distribution ```ansi Querying commands for the distribution module Usage: enid query distribution [flags] enid query distribution [command] Available Commands: commission Query distribution validator commission community-pool Query the amount of coins in the community pool params Query distribution params rewards Query all distribution delegator rewards or rewards from a particular validator slashes Query distribution validator slashes validator-outstanding-rewards Query distribution outstanding (un-withdrawn) rewards for a validator and all their delegations Flags: -h, --help help for distribution Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query distribution [command] --help" for more information about a command. ``` # enid query epoch ```ansi Querying commands for the epoch module Usage: enid query epoch [flags] enid query epoch [command] Available Commands: epoch gets the current epoch params shows the parameters of the module Flags: -h, --help help for epoch Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query epoch [command] --help" for more information about a command. ``` # enid query evidence ```ansi ``` # enid query evm ```ansi Querying commands for the evm module Usage: enid query evm [flags] enid query evm [command] Available Commands: erc20 get hex payload for the given inputs erc20-payload get hex payload for the given inputs erc721-payload get hex payload for the given inputs evm-addr gets evm address (0x...) by Eni address (eni...) if account has association set payload get hex payload for the given inputs pointer get pointer address of the specified type (one of [NATIVE, CW20, CW721, ERC20, ERC721]) and pointee pointer-version Query for the current pointer version and stored code ID (if applicable) eni-addr gets eni address (eni...) by EVM address (0x...) if account has association set Flags: -h, --help help for evm Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query evm [command] --help" for more information about a command. ``` # enid query feegrant ```ansi Querying commands for the feegrant module Usage: enid query feegrant [flags] enid query feegrant [command] Available Commands: grant Query details of a single grant grants-by-grantee Query all grants of a grantee grants-by-granter Query all grants by a granter Flags: -h, --help help for feegrant Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query feegrant [command] --help" for more information about a command. ``` # enid query ibc-transfer ```ansi IBC fungible token transfer query subcommands Usage: enid query ibc-transfer [command] Available Commands: denom-hash Query the denom hash info from a given denom trace denom-trace Query the denom trace info from a given trace hash or ibc denom denom-traces Query the trace info for all token denominations escrow-address Get the escrow address for a channel params Query the current ibc-transfer parameters Flags: -h, --help help for ibc-transfer Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query ibc-transfer [command] --help" for more information about a command. ``` # enid query gov ```ansi Querying commands for the governance module Usage: enid query gov [flags] enid query gov [command] Available Commands: deposit Query details of a deposit deposits Query deposits on a proposal param Query the parameters (voting|tallying|deposit) of the governance process params Query the parameters of the governance process proposal Query details of a single proposal proposals Query proposals with optional filters proposer Query the proposer of a governance proposal tally Get the tally of a proposal vote vote Query details of a single vote votes Query votes on a proposal Flags: -h, --help help for gov Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query gov [command] --help" for more information about a command. ``` # enid query ibc ```ansi Querying commands for the IBC module Usage: enid query ibc [flags] enid query ibc [command] Available Commands: channel IBC channel query subcommands client IBC client query subcommands connection IBC connection query subcommands Flags: -h, --help help for ibc Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query ibc [command] --help" for more information about a command. ``` # enid query mint ```ansi Querying commands for the minting module Usage: enid query mint [flags] enid query mint [command] Available Commands: minter Query the most recent minting state params Query the current minting parameters Flags: -h, --help help for mint Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query mint [command] --help" for more information about a command. ``` # enid query oracle ```ansi Querying commands for the oracle module Usage: enid query oracle [flags] enid query oracle [command] Available Commands: actives Query the active list of Eni assets recognized by the oracle exchange-rates Query the current Eni exchange rate w.r.t an asset feeder Query the oracle feeder delegate account params Query the current Oracle params price-snapshot-history Query the history for oracle price snapshots twaps Query the time weighted average prices for denoms with price snapshot data vote-penalty-counter Query the # of the miss count and abstain count vote-targets Query the current Oracle vote targets Flags: -h, --help help for oracle Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query oracle [command] --help" for more information about a command. ``` # enid query params ```ansi Querying commands for the params module Usage: enid query params [flags] enid query params [command] Available Commands: blockparams Query for block params cosmosgasparams Query for cosmos gas params feesparams Query for fee params subspace Query for raw parameters by subspace and key Flags: -h, --help help for params Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query params [command] --help" for more information about a command. ``` # enid query slashing ```ansi Querying commands for the slashing module Usage: enid query slashing [flags] enid query slashing [command] Available Commands: params Query the current slashing parameters signing-info Query a validator's signing information signing-infos Query signing information of all validators Flags: -h, --help help for slashing Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query slashing [command] --help" for more information about a command. ``` # enid query staking ```ansi Querying commands for the staking module Usage: enid query staking [flags] enid query staking [command] Available Commands: delegation Query a delegation based on address and validator address delegations Query all delegations made by one delegator delegations-to Query all delegations made to one validator hex-address Query validator that matches the Tendermint hex address representation of a validator historical-info Query historical info at given height params Query the current staking parameters information pool Query the current staking pool values redelegation Query a redelegation record based on delegator and a source and destination validator address redelegations Query all redelegations records for one delegator redelegations-from Query all outgoing redelegatations from a validator unbonding-delegation Query an unbonding-delegation record based on delegator and validator address unbonding-delegations Query all unbonding-delegations records for one delegator unbonding-delegations-from Query all unbonding delegatations from a validator validator Query a validator validators Query for all validators Flags: -h, --help help for staking Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query staking [command] --help" for more information about a command. ``` # enid query tendermint-validator-set ```ansi Get the full tendermint validator set at given height Usage: enid query tendermint-validator-set [height] [flags] Flags: -h, --help help for tendermint-validator-set --keyring-backend string Select keyring's backend (os|file|kwallet|pass|test) (default "os") --limit int Query number of results returned per page (default 100) -n, --node string Node to connect to (default "tcp://localhost:26657") --page int Query a specific page of paginated results (default 1) Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors ``` # enid query tokenfactory ```ansi Querying commands for the tokenfactory module Usage: enid query tokenfactory [flags] enid query tokenfactory [command] Available Commands: denom-authority-metadata Get the authority metadata for a specific denom denoms-from-creator Returns a list of all tokens created by a specific creator address params Get the params for the x/tokenfactory module Flags: -h, --help help for tokenfactory Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors Use "enid query tokenfactory [command] --help" for more information about a command. ``` # enid query tx ```ansi Example: $ query tx $ query tx --type=acc_seq / $ query tx --type=signature , Usage: enid query tx --type=[hash|acc_seq|signature] [hash|acc_seq|signature] [flags] Flags: --height int Use a specific height to query state at (this can error if the node is pruning state) -h, --help help for tx --node string : to Tendermint RPC interface for this chain (default "tcp://localhost:26657") -o, --output string Output format (text|json) (default "text") --type string The type to be used when querying tx, can be one of "hash", "acc_seq", "signature" (default "hash") Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors ``` # enid query txs ```ansi Search for transactions that match the exact given events where results are paginated. Each event takes the form of '{eventType}.{eventAttribute}={value}'. Please refer to each module's documentation for the full set of events to query for. Each module documents its respective events under 'xx_events.md'. Example: $ query txs --events 'message.sender=cosmos1...&message.action=withdraw_delegator_reward' --page 1 --limit 30 Usage: enid query txs [flags] Flags: --events string list of transaction events in the form of {eventType}.{eventAttribute}={value} --height int Use a specific height to query state at (this can error if the node is pruning state) -h, --help help for txs --limit int Query number of transactions results per page returned (default 30) --node string : to Tendermint RPC interface for this chain (default "tcp://localhost:26657") -o, --output string Output format (text|json) (default "text") --page int Query a specific page of paginated results (default 1) Global Flags: --chain-id string The network chain ID --home string directory for config and data (default "~/.eni") --log_format string The logging format (json|plain) --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) --trace print out full stack trace on errors ``` # enid rollback #### `enid rollback` ```ansi Performs a state rollback to recover from an incorrect application state when Tendermint has persisted an incorrect application hash and can no longer continue. The rollback will overwrite the state at height n with the state at height n - 1. The application will also roll back to height n - 1. No blocks will be deleted; therefore, transactions from block n will be re-executed upon restarting Tendermint. Usage: enid rollback [flags] Flags: --chain-id string Chain ID from the genesis file; if left empty, eni will be used (default "eni-chain") --hard Deletes the last block and the state -h, --help Help information for rollback --home string Application home directory (default "~/.eni") Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid start #### `enid start` ```ansi Runs a full node application with or without Tendermint. By default, the application runs alongside Tendermint. Pruning options can be provided via the `--pruning` flag or through `--pruning-keep-recent`, `--pruning-keep-every`, and `--pruning-interval`. For the `--pruning` options, the following are available: - default: Keeps the most recent 100 states, plus one every 500 states; prunes every 10 blocks. - nothing: Saves all historical states without deleting any (i.e., an archival node). - everything: Deletes all saved states, only keeping current and previous states; prunes every 10 blocks. - custom: Allows manual specification of pruning options using `--pruning-keep-recent`, `--pruning-keep-every`, and `--pruning-interval`. The node stop configuration exists in two flags: `--halt-height` and `--halt-time`. During the ABCI submit phase, the node will check if the current block height is greater than or equal to the halt height, or if the current block time is greater than or equal to the halt time. If either condition is met, the node will attempt to shut down gracefully, and the block will not be submitted. Additionally, the node will not be able to submit subsequent blocks. For analysis and benchmarking, CPU profiling can be enabled with the `--cpu-profile` flag, which accepts the path for the generated pprof file. The node can be started in "gRPC-only" mode, where only gRPC and JSON HTTP API services are enabled, bypassing Tendermint. This mode can be used to query old data after an on-chain upgrade. Note that when this mode is enabled, gRPC will automatically be activated. Usage: enid start [flags] Flags: --abci string Specify the abci transport (socket | grpc) (default "socket") --address string Listening address (default "tcp://0.0.0.0:26658") --archival-arweave-index-db-full-path string Full local path to LevelDB for indexing Arweave data --archival-arweave-node-url string URL of the Arweave node storing archival data --archival-db-type string Type of archival database. Valid options: arweave --archival-version int Version of application data stored in the archival database before this version --chain-id string Chain ID --compaction-interval uint Time interval to enforce LevelDB compaction. 0 means no forced compaction. --concurrency-workers int Number of worker threads to process concurrent transactions (default 20) --consensus.create-empty-blocks Set to false to only generate blocks when there are transactions or AppHash changes (default true) --consensus.create-empty-blocks-interval string The potential interval between empty blocks (default "0s") --consensus.double-sign-check-height int Number of blocks to backtrack to check for existing consensus votes before joining consensus --consensus.gossip-tx-key-only Set to false to propagate the whole data rather than just the key (default true) --cpu-profile string Enable CPU profiling and write to the provided file --db-backend string Database backend: goleveldb | cleveldb | boltdb | rocksdb | badgerdb (default "goleveldb") --db-dir string Database directory (default "data") --genesis-hash bytesHex Optional SHA-256 hash of the genesis file --grpc-only Start the node in gRPC-only query mode (do not start Tendermint process) --grpc-web.address string gRPC-Web server listening address (default "0.0.0.0:9091") --grpc-web.enable Define whether to enable the gRPC-Web server. (Note: gRPC must also be enabled.) (default true) --grpc.address string gRPC server listening address (default "0.0.0.0:9090") --grpc.enable Define whether to enable the gRPC server (default true) --halt-height uint Gracefully stop the chain and shut down the node at this block height --halt-time uint Minimum block time (in Unix seconds) to gracefully stop the chain and shut down the node -h, --help Help information for start --home string Application home directory (default "~/.eni") --iavl-disable-fastnode Enable fast node for IAVL tree (default true) --inter-block-cache Enable inter-block caching (default true) --inv-check-period uint Assert registered invariants every N blocks --min-retain-blocks uint Minimum block height offset for pruning Tendermint blocks during ABCI submission --minimum-gas-prices string Minimum gas price to accept transactions; any fees in a transaction must meet this minimum requirement (e.g., 0.01photino;0.0001stake) --mode string Node mode (full | validator | seed) (default "full") --moniker string Node name (default "MacBook-Pro-2.local") --num-orphan-per-file int Number of orphans stored per file if stored separately (default 100000) --orphan-dir string Storage directory for orphan files if stored separately (default "~/.eni/orphans") --p2p.laddr string Listening address for nodes. (0.0.0.0:0 means any interface, any port) (default "tcp://0.0.0.0:26656") --p2p.persistent-peers string Comma-separated list of ID@host:port persistent peers --p2p.pex Enable/disable peer exchange (default true) --p2p.private-peer-ids string Comma-separated list of private peer IDs --p2p.unconditional-peer-ids string Comma-separated list of unconditional peer IDs --p2p.upnp Enable/disable UPNP port forwarding --priv-validator-laddr string Listening socket address for connections from external priv-validator processes --profile Enable profiling in the application --proxy-app string Proxy application address, or one of: 'kvstore', 'persistent_kvstore', 'e2e', or 'noop' for local testing. (default "tcp://127.0.0.1:26658") --pruning string Pruning strategy (default|nothing|everything|custom) (default "default") --pruning-interval uint Height interval to delete pruned heights on disk (ignored if pruning is not 'custom') --pruning-keep-every uint Offset heights retained on disk after 'keep-every' (ignored if pruning is not 'custom') --pruning-keep-recent uint Number of recent heights to keep on disk (ignored if pruning is not 'custom') --rpc.laddr string RPC listening address. Requires a port (default "tcp://127.0.0.1:26657") --rpc.pprof-laddr string pprof listening address (https://golang.org/pkg/net/http/pprof) --rpc.unsafe Enable unsafe rpc methods --separate-orphan-storage Whether to store orphans outside the main application levelDB --separate-orphan-versions-to-keep int Number of versions to retain if orphans are stored separately (default 2) --state-sync.snapshot-interval uint State sync snapshot interval --state-sync.snapshot-keep-recent uint32 Number of state sync snapshots to keep (default 2) --trace Provide the full stack trace on errors in ABCI logs --trace-store string Enable KVStore tracing to an output file --tracing Enable tracing in the application --transport string Transport protocol: socket, grpc (default "socket") --unsafe-skip-upgrades ints Skip a set of upgrade heights to continue using an old binary --with-tendermint Embed Tendermint in-process to run abci applications (default true) --x-crisis-skip-assert-invariants Skip x/crisis invariant checks on startup Global Flags: --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) ``` # enid status #### `enid status` ```ansi Queries the status of a remote node. Usage: enid status [flags] Flags: -h, --help Help information for status -n, --node string The node to connect to (default "tcp://localhost:26657") Global Flags: --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid tendermint #### `enid tendermint` ```ansi Tendermint subcommands Usage: enid tendermint [command] Available commands: debug A utility to kill or monitor the Tendermint process while aggregating debug data gen-node-key Generate a new node key gen-validator Generate a new validator key pair inspect Run a inspect server to investigate Tendermint state key-migrate Run database key migration light Run a light client proxy server to validate Tendermint rpc reindex-event Reindex events to the event storage backend replay Replay messages from WAL replay-console Replay WAL messages in the console reset A set of commands to conveniently reset tendermint-related data show-address Show this node's tendermint validator consensus address show-node-id Show this node's ID show-validator Show this node's tendermint validator info snapshot Take a DBSync snapshot at a given height unsafe-reset-all Remove all tendermint data, including signed state version Print the version of the tendermint library Flags: -h, --help Help information for tendermint Global Flags: --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error Use "enid tendermint [command] --help" for more information about a command. ``` # enid tools #### `enid tools` ```ansi A set of useful tools for the ENI chain. Usage: enid tools [command] Available commands: scan-tx Tool for scanning lost transactions Flags: -h, --help Help information for tools Global Flags: --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error Use "enid tools [command] --help" for more information about a command. ``` # enid tx #### `enid tx` ```ansi Transaction subcommands Usage: enid tx [flags] enid tx [command] Available commands: accesscontrol Access control transaction subcommand authz Authorization transaction subcommand bank Bank transaction subcommand broadcast Broadcast offline generated transactions crisis Crisis transaction subcommand decode Decode a binary encoded transaction string dex Dex transaction subcommand distribution Distribution transaction subcommand encode Encode offline generated transactions epoch Epoch transaction subcommand evidence Evidence transaction subcommand evm EVM transaction subcommand feegrant Fee grant transaction subcommand gov Governance transaction subcommand ibc IBC transaction subcommand ibc-transfer IBC fungible token transfer transaction subcommand multisign Generate multi-signatures for offline generated transactions oracle Oracle transaction subcommand sign Sign offline generated transactions sign-batch Sign a batch of transaction files slashing Slashing transaction subcommand staking Staking transaction subcommand tokenfactory Token factory transaction subcommand validate-signatures Validate transaction signatures vesting Vesting transaction subcommand wasm Wasm transaction subcommand Flags: --chain-id string Network chain ID -h, --help Help information for tx Global Flags: --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error Additional Help Topics: enid tx upgrade Upgrade transaction subcommand Use "enid tx [command] --help" for more information about a command. ``` # enid validate-genesis #### `enid validate-genesis` ```ansi Validate the genesis file at the default location or a location passed as a parameter. Usage: enid validate-genesis [file] [flags] Flags: -h, --help Help information for validate-genesis Global Flags: --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ``` # enid version #### `enid version` ```ansi Print the application binary version information. Usage: enid version [flags] Flags: -h, --help Help information for version --long Print detailed version information -o, --output string Output format (text|json) (default "text") Global Flags: --home string Directory for configuration and data (default "~/.eni") --log_format string Log format (json|plain) --log_level string Log level (trace|debug|info|warn|error|fatal|panic) --trace Print the full stack trace on error ```