Joining the og-evm Network: External Validator Guide

How to run a full node and become a validator on og-evm from your own infrastructure. You do not need access to the operators' AWS account, only the published values in the Network Information table below.

Note

og-evm is a single-binary Cosmos-EVM chain (evmd runs CometBFT consensus and the EVM in one process). There is no separate consensus/execution client, no JWT, no fixed deposit. Your consensus key comes from priv_validator_key.json via evmd comet show-validator.

Part A: Run a full node

Network Information

Detail	Value
Cosmos chain-id	`og-evm-testnet-1`
EVM chain-id	`262144` (`0x40000`)
Token	base denom `ogwei`; display `OGETH` ("OG Ether"), 18 decimals (1 OGETH = 10^18 ogwei)
Address prefix	bech32 `og` (Cosmos addresses look like `og1...`)
Binary	`evmd`, built from `OpenGradient/og-evm` at `ee09f5f0` (ask operators for the current commit)
Genesis	obtain `genesis.json` from operators (not publicly served yet)
Genesis SHA256	`c4d873dfe2253e303fe690995aa6df02bf808edf5395cc9061edd6bcd589b705`
Persistent peer (sentry)	`17f6e31a181960b80854c2245246ec415dd8e13a@100.49.228.101:26656`
EVM JSON-RPC	`http://ogevm-rpc-236722263.us-east-1.elb.amazonaws.com` (HTTP, no TLS yet)
Faucet	none public; ask operators to fund your address

Warning

The chain is pre-production. Endpoints, the sentry peer, and the genesis hash all change on a full rebuild or reset. Confirm the current values with the operators before you start. If your node logs a genesis-hash mismatch after an operator deploy, see Part C.

1. Minimum requirements

Resource	Recommended
CPU / RAM	4 vCPU / 8 to 16 GiB
Disk	200 GiB SSD (gp3-class), grows with history
Network	stable public IP or outbound to the sentry on `:26656`
OS	Linux x86_64

2. Install the binary

Build at the published commit. It must match the network binary, or your node will fork and crash:

git clone https://github.com/OpenGradient/og-evm && cd og-evm
git checkout <published-commit>     # e.g. ee09f5f0
make install                        # puts `evmd` on your PATH
evmd version                        # confirm it prints <published-commit>

3. Initialize the node

export MONIKER="<your-moniker>"
evmd init "$MONIKER" --chain-id og-evm-testnet-1 --default-denom ogwei
# creates ~/.evmd/config/{config.toml,app.toml,genesis.json,node_key.json,priv_validator_key.json}

4. Download and verify genesis

# Place the operator-provided genesis.json, then verify it:
cp /path/to/network/genesis.json ~/.evmd/config/genesis.json
echo "c4d873dfe2253e303fe690995aa6df02bf808edf5395cc9061edd6bcd589b705  $HOME/.evmd/config/genesis.json" \
  | sha256sum -c -
# Expected: OK

Caution

Do not start the node if the checksum does not match. A wrong genesis means a different chain, and you will never peer.

5. Configure peers

PERSISTENT_PEERS="17f6e31a181960b80854c2245246ec415dd8e13a@100.49.228.101:26656"
sed -i.bak -e "s|^persistent_peers *=.*|persistent_peers = \"$PERSISTENT_PEERS\"|" \
  ~/.evmd/config/config.toml

Note

You peer with the sentry, not with the validators directly (their IPs are private). If operators publish more public peers or seeds, add them comma-separated.

6. Configure gas and pruning (app.toml)

# Set a minimum gas price you'll accept. The chain's base fee is near 0 when idle and rises under load:
sed -i.bak -e "s|^minimum-gas-prices *=.*|minimum-gas-prices = \"0ogwei\"|" ~/.evmd/config/app.toml
# Optional: custom pruning to bound disk
sed -i.bak -e "s|^pruning *=.*|pruning = \"custom\"|" ~/.evmd/config/app.toml

7. Run as a service

sudo tee /etc/systemd/system/evmd.service >/dev/null <<EOF
[Unit]
Description=og-evm node
After=network-online.target
[Service]
User=$USER
ExecStart=$(command -v evmd) start --home $HOME/.evmd
Restart=on-failure
RestartSec=3
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload && sudo systemctl enable --now evmd

8. Start and verify sync

journalctl -u evmd -f                       # watch logs
curl -s localhost:26657/status | jq '.result.sync_info'   # catching_up: false when synced
curl -s localhost:26657/net_info | jq '.result.n_peers'   # >= 1 (the sentry)

9. State sync (optional, skips the genesis replay)

State sync fetches a recent snapshot instead of replaying every block, so a node catches up in minutes. Use it only after the chain has history, and only if the operators run nodes that serve snapshots on a reachable CometBFT RPC.

Note

The public RPC URL above is the EVM JSON-RPC (port 8545), not the CometBFT RPC (port 26657). State sync needs a CometBFT RPC endpoint that serves snapshots. Ask the operators for one before you start.

SNAP_RPC="<cometbft-rpc-with-snapshots>:26657"
LATEST=$(curl -s $SNAP_RPC/block | jq -r .result.block.header.height)
TRUST_HEIGHT=$((LATEST - 2000))
TRUST_HASH=$(curl -s "$SNAP_RPC/block?height=$TRUST_HEIGHT" | jq -r .result.block_id.hash)

# Stop the node, back up priv_validator_state.json, then reset:
sudo systemctl stop evmd
cp ~/.evmd/data/priv_validator_state.json /tmp/pvs.backup
evmd comet unsafe-reset-all --home ~/.evmd --keep-addr-book

# Patch the [statesync] block (rpc_servers needs TWO entries; the same node twice is fine):
sed -i.bak \
  -e "s|^enable *=.*|enable = true|" \
  -e "s|^rpc_servers *=.*|rpc_servers = \"$SNAP_RPC,$SNAP_RPC\"|" \
  -e "s|^trust_height *=.*|trust_height = $TRUST_HEIGHT|" \
  -e "s|^trust_hash *=.*|trust_hash = \"$TRUST_HASH\"|" \
  ~/.evmd/config/config.toml

mv /tmp/pvs.backup ~/.evmd/data/priv_validator_state.json
sudo systemctl start evmd
journalctl -u evmd -f      # watch for "Discovering snapshots" then "Applied snapshot chunk"

Caution

Back up and restore priv_validator_state.json around the reset so a validator never double-signs. Once the node is caught up, set enable = false in [statesync] again so a future restart does not re-trigger state sync.

Part B: Become a validator

Note

You can only join the active set after the chain is live (the genesis set is fixed at genesis) and your node is fully synced (catching_up: false).

1. Create an operator key

evmd keys add <KEY_NAME> --keyring-backend test   # default key type is eth_secp256k1
evmd keys show <KEY_NAME> -a --keyring-backend test     # your address (give this to operators)

2. Get funded

There is no public faucet. Send your address from step 1 to the operators and ask them to transfer OGETH from the network faucet. Confirm it arrived:

RPC=http://ogevm-rpc-236722263.us-east-1.elb.amazonaws.com
cast balance $(evmd keys show <KEY_NAME> -a --keyring-backend test) --rpc-url $RPC --ether

3. Get your consensus pubkey

evmd comet show-validator     # prints the {"@type":"...","key":"..."} consensus pubkey

4. Create the validator

evmd tx staking create-validator <(cat <<EOF
{
  "pubkey": $(evmd comet show-validator),
  "amount": "<stake>ogwei",
  "moniker": "$MONIKER",
  "commission-rate": "0.10",
  "commission-max-rate": "0.20",
  "commission-max-change-rate": "0.01",
  "min-self-delegation": "1"
}
EOF
) \
  --chain-id og-evm-testnet-1 \
  --from <KEY_NAME> --keyring-backend test \
  --gas auto --gas-adjustment 1.4 --fees 2000000ogwei \
  -y

Verification:

curl -s localhost:26657/status | jq '.result.validator_info.voting_power'   # > 0 once bonded

5. Secure your validator

Warning

Double-signing is slashed and tombstones the validator permanently. Never run two nodes with the same priv_validator_key.json. After any restart or upgrade, wait until the node is fully caught up before it signs.

Back up ~/.evmd/config/priv_validator_key.json and node_key.json offline (encrypted).
Front your validator with your own sentry node, and keep the validator's P2P off the public internet.
Firewall: expose only :26656 (P2P) on the sentry, and keep :26657 (RPC) and :8545 (EVM) private.

6. Maintenance

# Unjail after downtime (once resynced):
evmd tx slashing unjail --from <KEY_NAME> --chain-id og-evm-testnet-1 --keyring-backend test -y
# Binary upgrade: stop evmd, install the announced commit, start. For governance or halt-height
# upgrades, follow the announced height.

Part C: When the operators deploy

There are two very different operator actions. Know which one happened:

Action	What changes	Your response
Rolling image upgrade	new `evmd` image; chain, genesis, and your stake unchanged	upgrade your binary to the announced commit within the window; if it's a halt-height upgrade, follow the height
Full rebuild / chain reset	brand-new genesis, new validator set, new endpoints and sentry IP	treat it as a new chain (below)

After a reset:

evmd comet unsafe-reset-all --home ~/.evmd --keep-addr-book   # wipes blocks, keeps keys
# drop in the NEW genesis.json (verify the NEW sha256), update persistent_peers, restart, resync.
# re-run Part B (create-validator). Your old validator does not carry over.

Note

A reset is not announced as a version bump; it changes the genesis hash. If your node logs wrong Genesis hash or won't peer after an operator deploy, assume a reset.

BornPsych/external_validator.md

Select an option

No results found

Select an option

No results found

Joining the og-evm Network: External Validator Guide

Part A: Run a full node

Network Information

1. Minimum requirements

2. Install the binary

3. Initialize the node

4. Download and verify genesis

5. Configure peers

6. Configure gas and pruning (app.toml)

7. Run as a service

8. Start and verify sync

9. State sync (optional, skips the genesis replay)

Part B: Become a validator

1. Create an operator key

2. Get funded

3. Get your consensus pubkey

4. Create the validator

5. Secure your validator

6. Maintenance

Part C: When the operators deploy