Running a Node
aetron-node is the blockchain client. It is a Substrate node with a Frontier layer bolted on, so one process serves both the Substrate JSON-RPC and the Ethereum JSON-RPC. It does not run AI work: inference and training happen on miners, and the node only carries the accounting and the proofs around them.
Do You Need One
Most people do not. The public endpoints answer the same RPC, and a miner or a gateway is perfectly happy pointed at them.
Run your own when you want no rate limits and no dependency on someone else's uptime, when you need archive state that public endpoints prune away, when you are indexing the chain, or when you are operating a validator.
Getting the Binary
The node is distributed as a prebuilt binary. The source tree is not public, so building it yourself is not an option, and the pages below assume you already have aetron-node on the machine.
Downloads are not published yet. github.com/aetronai/aetron-node is where releases will appear; until they do, operators get the binary directly from the team. Once a release exists, verify its checksum before running it, the same as any other node software.
Requirements
For a node that keeps up with the head, plan on a 4-core machine with fast NVMe. An archive node needs considerably more disk than a pruned one and keeps growing, so size it for where the chain will be rather than where it is.
The binary carries the runtime with it, so there is nothing else to install alongside it.
Chain Specs: Read This Before You Start
The node accepts --chain dev, --chain mainnet, --chain testnet, or a path to a JSON spec file.
The built-in mainnet and testnet specs do not match the live networks. They build a genesis from the current code, and the live chains were started from earlier ones, so the genesis hash comes out different and your node will simply never find a peer that agrees with it. This is the single most common way to waste an afternoon here.
The live genesis hashes are:
| Network | Genesis |
|---|---|
| Mainnet | 0xed62243b8824023257fe3d2887c2379dfcae9d55ec9727b9f56a6fde8283125d |
| Testnet | 0x2e45803a320dbf6c0d3fc8bdc6059107aca00e6f285961a394d103c0391e1074 |
Check any spec you are about to use against those, and check what your node actually joined:
curl -s https://entrypoint-mainnet.aetron.ai \
-H 'Content-Type: application/json' \
-d '{"id":1,"jsonrpc":"2.0","method":"chain_getBlockHash","params":[0]}'
So a node that is meant to follow a public network runs from a raw spec file, not from a built-in name. --chain dev is the exception and is exactly right for a throwaway local chain.
Running
Against testnet:
aetron-node \
--base-path /data/testnet \
--chain /path/to/aetron-testnet-raw.json \
--name my-node \
--bootnodes /dns/test-bootnode.aetron.ai/tcp/30333/ws/p2p/12D3KooWAYVm16woffAsg4V9nVTKHKiSWh9FdGMS4UsJiPRzUQ2i
Against mainnet, swap the spec and the bootnode:
--bootnodes /dns/bootnode.aetron.ai/tcp/30333/ws/p2p/12D3KooWSZxgehdVfTqQCU19VAngesXFTX9bQwf83wkw16jehxcP
Both bootnode entries speak WebSocket. If a node behind a home connection sits at zero peers with the right genesis, that transport is the usual suspect; adding a plain TCP peer alongside it is the quick way to tell whether the problem is the transport or the spec.
To expose RPC to something other than localhost:
--rpc-external --rpc-cors all --rpc-methods safe
--rpc-methods safe is what you want on anything reachable from outside. The unsafe set includes key insertion and peer management.
Ports
| Port | What | Flag |
|---|---|---|
| 30333 | libp2p, peer to peer | --port |
| 9944 | JSON-RPC, both Substrate and Ethereum | --rpc-port |
| 9615 | Prometheus metrics | --prometheus-port |
Running a second node on the same host means moving all three. The production explorer host does exactly that: mainnet on 30333/9944/9615 and testnet on 30334/9945/9616.
Pruning and Archive Mode
The current CLI has no --pruning flag. It was split in two:
--state-pruning archive --blocks-pruning archive
Without those, the node keeps a recent window of state and discards the rest, which is fine for following the head and useless for indexing history. An indexer, a block explorer, or anything that answers questions about old blocks needs both set to archive.
The Ethereum Layer
The Ethereum RPC is served from the same port as the Substrate RPC, so nothing extra needs enabling for eth_* calls to work. See EVM Compatibility for chain ids and the decimals difference.
The Frontier layer has its own flags, and the defaults are sensible:
| Flag | Default | What it does |
|---|---|---|
--frontier-backend-type | key-value | Storage backend for Ethereum data. sql suits heavy log queries. |
--max-past-logs | 10000 | Cap on rows returned by a log query. |
--fee-history-limit | 2048 | Depth of the fee history cache. |
--eth-log-block-cache, --eth-statuses-cache | 50 | LRU cache sizes for block data and transaction statuses. |
--execute-gas-limit-multiplier | 10 | Headroom for eth_call and eth_estimateGas against the block gas limit. |
--enable-dev-signer | off | Lets the node hold keys and sign transactions. Development only. |
--enable-dev-signer on a public node hands transaction signing to the node itself. Leave it off.
Subcommands
| Subcommand | What it does |
|---|---|
key | Generate and inspect keys, insert them into the keystore |
build-spec | Produce a chain spec, with --raw for the deployable form |
export-blocks, import-blocks | Move block data in and out of a node |
export-state | Dump state at a block into a spec |
check-block | Re-validate a single block |
revert | Roll the chain back by N blocks |
purge-chain | Delete the database for a base path |
chain-info | Print database metadata |
build-spec --chain <source> --raw is how a raw spec is produced from a running configuration, and it is the supported way to hand a matching spec to other operators.
A Local Development Chain
For a chain of your own that owes nothing to the public networks:
aetron-node --dev --base-path /tmp/aetron-dev
--dev gives you a single-node chain that produces blocks on its own. Alice is the sole Aura authority, so nothing else has to be running for the chain to move.
Who Holds What
Alice is sudo. Every privileged call on a dev chain, and there are a lot of them in this runtime, is signed by Alice: unpausing emission, flipping enforcement flags, setting the launch allowlist, registering schemas. In Polkadot.js Apps that is Developer → Sudo with Alice selected.
The genesis funds eight accounts:
| Account | Balance |
|---|---|
| Alice, Bob, Charlie | 1,000,000 AET each |
| Dave, Eve, Ferdie | 100,000 AET each |
Alith, 0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac | 100,000 AET |
Baltathar, 0x3Cd0A705a2DC65e5b1E1205896BaA2be8A07c6e0 | 100,000 AET |
The first six are the standard Substrate development accounts, derived from the seeds //Alice through //Ferdie. The last two are the equivalent Ethereum-style dev accounts, funded so that the EVM side has something to spend from the first block.
You can fund one more account at genesis without touching the spec, which is the convenient way to give your own wallet a balance:
AET_DEFAULT_TOKEN_WALLET=5Dt... aetron-node --dev --base-path /tmp/aetron-dev
A valid SS58 address there gets 1,000,000 AET. An invalid one is reported on stderr and skipped, so check the log if the balance does not show up.
The Obvious Warning
Every one of these keys is public. //Alice is in every Substrate tutorial on the internet, and the Alith and Baltathar private keys are equally well known. They exist so that a local chain is usable in thirty seconds, and they are worth exactly nothing anywhere else. Never fund a dev account on a public network, and never reuse one of these seeds for a real key.
Two more practical notes. A dev chain on --tmp disappears when the disk fills, so give it a real base path if you expect it to survive. And it has its own genesis, so a miner or gateway pointed at it needs network = "local" and its own configuration rather than the public defaults.
Validators
Block production uses Aura, with GRANDPA for finality. The node carries an --initial-consensus flag as a transitional switch, and the default is the right answer unless you have been told otherwise.
The validator set is not open at the moment: the base chain runs in a permissioned mode while the verification protocol is rolled out, and the transition to a stake-based set is described in Governance. Running a full node is open to anyone, producing blocks is not.
Checking That It Works
curl -s http://127.0.0.1:9944 \
-H 'Content-Type: application/json' \
-d '{"id":1,"jsonrpc":"2.0","method":"system_health","params":[]}'
isSyncing: false with a non-zero peers count means the node is caught up and connected. Zero peers with a healthy process almost always means the genesis does not match, which takes you back to the chain spec section above.