The most dangerous configuration value in a blockchain ecosystem is the one that looks like a label and is actually part of a signature. This post is about the file EmpoorioChain created after discovering it had three of them in circulation.
What was found
On 27 August 2026 an inventory of the ecosystem's code, configuration and documentation found:
- Three EVM chain ids pointing at EmpoorioChain: 2026 (correct), 1337 in six places, 9911 in five. A fourth, 27777, was found later in a core document that had escaped the first sweep.
- Six declared RPC hosts, of which one resolved.
- An SS58 prefix of 42 (the generic Substrate development prefix) in the runtime and 2026 in the chain spec.
The chain id is not cosmetic. Under EIP-155 it is inside every signed EVM transaction. A wallet configured with 1337 produces signatures this chain rejects — and, worse, signatures valid on any local Hardhat or Ganache network, because 1337 is their default. Replay protection between chains simply stops existing. A wallet configured with 9911 cannot sign for EmpoorioChain at all.
The registry
docs/RED.json — Registro Único de Red — holds, with a version and a verification date:
evm.chain_id: 2026, with its source (DefaultChainId: u64 = 2026in the runtime), the list of incorrect ids found in circulation with where and why each is dangerous, and the verified state of the EVM RPC surface.substrate: SS58 prefix 2026 (divergence resolved by decision on 27 August; registry submission pending), symbol DMS, 18 decimals.hosts: every host that resolves, with IP, TLS status and what it serves — and a rule: only these may appear in code, configuration or documentation as endpoints; a host that does not resolve is not cited, not even as an example. A list of hosts that resolve but serve nothing is kept separately.mainnet:existe: false, with a note.testnet_viva: genesis hash, spec and transaction versions, total supply, validator count and the validator note (two, same AS, zero tolerance).
The rule
Nobody writes these values by hand. They are read from here. The official website, the Eoonia SDK, the Rust SDK and the documentation generators consume the file; a value that diverges is a build failure, not a typo waiting to be found.
The check
python3 scripts/verificar_red.py
reads the file, queries a live node, and fails if they disagree. It caught its own bug along the way: the script computed the EVM chain-id storage key from a pallet named EVMChainId, but the pallet is EvmChainId in construct_runtime!, so the check produced a false red. Corrected — with the note left in the file so the next person understands the trap.
The historical entry
RED.json also records what used to be true, labelled as history. From 27 August to the deployment of runtime 208 on 4 September, the EVM RPC surface returned Method not found for every eth_* call. Three documents were still stating that on 5 September — one of them telling a prospective exchange that EVM integration was impossible. The registry's entry now says RESOLVED, with the verification, and the three documents were corrected against it.
Based on RED.json v1.2.0 and its embedded commentary.