>AgentChain

Genesis Specification

The genesis block is the foundation of the AgentChain network. It defines the initial state, consensus rules, and EVM fork schedule. This document provides a fully annotated genesis.json with explanations for every field.

Complete genesis.json

{
  "config": {
    "chainId": 7331,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "istanbulBlock": 0,
    "berlinBlock": 0,
    "randomx": {}
  },
  "difficulty": "0x100",
  "gasLimit": "0x1C9C380",
  "alloc": {}
}

Field-by-Field Explanation

config

The config object defines the chain's consensus rules and fork schedule.

chainId: 7331

The unique identifier for the AgentChain network. This value is embedded in every signed transaction (per EIP-155) to prevent replay attacks across different chains. Wallets and RPC clients use this value to verify they are connected to the correct network.

"chainId": 7331

Fork Schedule

Each *Block field specifies the block number at which a particular Ethereum protocol upgrade activates.

"homesteadBlock": 0,
"eip150Block": 0,
"eip155Block": 0,
"eip158Block": 0,
"byzantiumBlock": 0,
"constantinopleBlock": 0,
"petersburgBlock": 0,
"istanbulBlock": 0,
"berlinBlock": 0

| Fork | Block | Key Changes | |------|-------|-------------| | Homestead | 0 | Removes canary contracts, changes difficulty adjustment, enables DELEGATECALL | | EIP-150 (Tangerine Whistle) | 0 | Reprices IO-heavy opcodes to mitigate DoS attacks | | EIP-155 (Spurious Dragon) | 0 | Replay protection via chain ID in transaction signatures | | EIP-158 (Spurious Dragon) | 0 | State trie clearing, empty account removal | | Byzantium | 0 | REVERT opcode, STATICCALL, precompiles for pairing and modexp | | Constantinople | 0 | CREATE2, EXTCODEHASH, bitwise shifting opcodes, net gas metering | | Petersburg | 0 | Removes EIP-1283 (reentrancy fix for SSTORE net metering) | | Istanbul | 0 | CHAINID opcode, SELFBALANCE, repriced SSTORE, Blake2 precompile | | Berlin | 0 | EIP-2929 (cold/warm storage access costs), EIP-2930 (access lists) |

randomx:

An empty randomx object signals to Geth that this chain uses RandomX Proof-of-Work consensus (AgentChain's custom RandomACR variant). No additional configuration is needed — the custom RandomACR parameters (modified scratchpad sizes, instruction frequencies, and salt) are compiled into the node binary.

"randomx": {}

difficulty: "0x100"

The genesis block difficulty is set to 256 (hexadecimal 0x100). This is the starting difficulty for the very first block.

"difficulty": "0x100"

This value serves as both the initial mining difficulty and the minimum difficulty floor enforced by the custom difficulty algorithm. The lower starting difficulty works because the difficulty algorithm adjusts by 1/256 per block (faster than Ethereum's 1/2048), allowing the network to converge quickly on the 6-second block time target even from this low starting value. As more miners join, the difficulty will ramp up rapidly.

gasLimit: "0x1C9C380"

The genesis gas limit is 30,000,000 (hexadecimal 0x1C9C380). This defines the initial maximum amount of gas that can be consumed by all transactions in a single block.

"gasLimit": "0x1C9C380"

This starting value of 30M sits in the middle of the protocol's enforced range. Miners can vote to adjust the gas limit up or down by a small fraction per block, within a floor of 10,000,000 and a ceiling of 60,000,000. The genesis value sets the starting point, and the network converges on a limit that matches demand.

alloc:

The alloc field defines the initial token distribution. An empty object means zero premine — no addresses receive any CRD at genesis.

"alloc": {}

Every single CRD token in circulation must be earned through mining. This is a deliberate design choice to ensure fair distribution without any insider advantage.

If a premine were desired, addresses and balances would be specified like this (not used in AgentChain):

"alloc": {
  "0x0000000000000000000000000000000000000001": {
    "balance": "1000000000000000000"
  }
}

Why All Fork Blocks Are Set to 0

Setting every fork activation block to 0 means all protocol upgrades — from Homestead through Berlin — are active from the very first block. This approach has several advantages:

  1. No legacy code paths. The chain never operates under old rules, eliminating edge cases where different blocks follow different consensus rules.
  2. Full feature set from day one. Smart contracts deployed on block 1 can use every opcode available in the Berlin EVM, including CREATE2, CHAINID, SELFBALANCE, and access lists.
  3. Simpler client configuration. There is no need to plan or coordinate hard forks for features that are already battle-tested on Ethereum mainnet.
  4. Predictable behavior. Developers and agents know exactly which opcodes and precompiles are available at every block height.

Why No London, Shanghai, or Cancun Blocks

The genesis deliberately omits the following fork activations:

| Omitted Fork | Key Feature | Reason for Exclusion | |--------------|-------------|---------------------| | London | EIP-1559 (base fee, fee burning) | AgentChain uses a simple first-price fee model. No base fee, no fee burning. The BASEFEE opcode is not available. | | Shanghai | EIP-3855 (PUSH0), EIP-3860 (initcode limit) | These are post-Merge features. PUSH0 is not available; use PUSH1 0x00 instead. | | Cancun | EIP-1153 (transient storage), EIP-4844 (blobs) | These features assume proof-of-stake infrastructure. TSTORE/TLOAD opcodes are not available. |

By stopping at Berlin, AgentChain maintains a clean, well-understood EVM without the complexity introduced by the proof-of-stake transition and its associated protocol changes.

Initializing a Node with the Genesis

To start an AgentChain node, first save the genesis configuration to a file and then initialize the Geth data directory.

Step 1: Save the Genesis File

Save the JSON above to a file named genesis.json.

Step 2: Initialize the Data Directory

geth init --datadir ./agentchain-data genesis.json

This creates the initial blockchain database with the genesis block. You should see output confirming that the genesis block was written successfully:

INFO [xx-xx|xx:xx:xx.xxx] Successfully wrote genesis state

Step 3: Start the Node

geth --datadir ./agentchain-data \
  --networkid 7331 \
  --port 30303 \
  --http \
  --http.port 8545 \
  --http.api eth,net,web3,miner,txpool,admin,debug,agent \
  --mine \
  --miner.etherbase 0xYOUR_ADDRESS_HERE

Note: The agent namespace provides a key-free wallet API for AI agents. The personal namespace is intentionally excluded from HTTP — see Security Architecture.

Step 4: Verify the Genesis

After the node starts, confirm the genesis is correct by querying the chain ID:

curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

Expected response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x1ca3"
}

The hex value 0x1ca3 equals 7331 in decimal, confirming the correct chain ID.

Modifying the Genesis

If you need to create a testnet or development fork of AgentChain, you can modify the genesis file. Important considerations:

  • Change the chain ID to avoid transaction replay between networks.
  • Adjust the difficulty if you want faster or slower block times during testing.
  • Add allocations to pre-fund test accounts.
  • Every node on the same network must use an identical genesis file. Any mismatch will cause peers to reject each other's blocks.