Ethrex Launches Hegotá Testnet for Ethereum Privacy EIPs

Hegotá privacy testnet faucet

A public test network running EIP-8141 frame transactions together with EIP-8250 keyed nonces, EIP-8272 recent roots and EIP-7805 inclusion lists, on ethrex . Test ETH has no value.

What this chain enables

Together they are what a shielded pool needs from the base layer: a proof authorising a spend, the pool paying for it, concurrent spends, a fresh root to prove against, and an inclusion guarantee. Everything else is Glamsterdam. Each EIP is explained at length, with how they lean on each other, in the EIP guide .

The hash under each number is the ethereum/EIPs commit this chain implements. These drafts move often and the chain does not follow them live: what runs here is the text at those commits ( git show <commit>:EIPS/eip-<n>.md ), and a spec change only reaches the chain through a relaunch. The network spec records the pins, the fork schedule and what is being tested.

Connect

Sending transactions here

Ordinary transactions work normally. The ETH above is plain ETH: point any wallet or library at the RPC endpoint with the chain ID above and send transfers, deploy contracts, call them.

Frame transactions are a different matter. EIP-8141 is a draft, so no wallet and no released version of the common libraries can encode or sign one; a wallet asked to send one simply has no representation for it. Submitting one means building the envelope yourself and handing the signed bytes to eth_sendRawTransaction . The ethrex repository carries reference submitters that do exactly that, and the node offers ethrex_simulateFrameTransaction to dry-run the bytes before you send them.

Send one

Take the submitters from the hegota-testnet branch:

git clone --branch hegota-testnet --depth 1 https://github.com/lambdaclass/ethrex cd ethrex/scripts/hegota-testnet && pip install eth-keys eth-hash[pycryptodome]

Only this branch speaks the wire format this chain runs: nested fees, a per-frame [execution, state] pair, keyed nonces and recent-root references. Released libraries, and rex for now, encode an older envelope and are rejected on decode (see the first error below).

Self-verified transfer: a VERIFY frame approving execution and payment,

then a SENDER frame that moves the value. Prints the sig hash, the tx hash,

and the mined receipt with its per-frame receipts. python3 frametx_submit.py https://rpc1.privacy.ethrex.xyz <YOUR_PRIVATE_KEY_HEX> 0xRecipientAddress 1000000000

A sponsored transfer, where a second account pays: python3 frametx_sponsor_submit.py https://rpc1.privacy.ethrex.xyz <SENDER_KEY> <PAYER_KEY> 0xRecipientAddress 1000000000

Dry-run any raw 0x06 payload against the node before submitting it: curl -s https://rpc1.privacy.ethrex.xyz -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"ethrex_simulateFrameTransaction","params":["0x06…"]}'

Decode a mined one, frame by frame: curl -s https://rpc1.privacy.ethrex.xyz -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["<TX_HASH>"]}'

The receipt carries frameReceipts , one per frame, each with its own status , gasUsed and stateGasUsed . The explorer renders the same breakdown. frametx.py next to the submitters is the encoder itself; build any frame shape from it.

Common errors

Error decoding field 'frames' … Error decoding field 'limits' of type (u64, u64): MalformedData

The encoder predates two-dimensional gas and is sending a frame's gas as one scalar. This chain accepts only the [execution, state] pair. The sibling Error decoding field 'fees' means the fees are flat where this chain expects one nested [max_priority_fee, max_fee, max_fee_per_blob_gas] list; a released rex produces exactly that.

A frame reverts having used exactly its execution budget, with stateGasUsed: 0x0

Missing state budget, not execution. Raising the frame's limits.execution will not help; raise its limits.state . A transfer to an address that does not exist yet needs 183,600 of it, the account-creation charge.

Invalid frame transaction signature

The layout is v ‖ r ‖ s with v a bare recovery id, 0 or 1 — not the 27 / 28 form ecrecover takes. r and s must also be canonical and low-s.

Frame transaction prefix gas budget (frames + sig cost) exceeds MAX_VERIFY_GAS

The validation prefix is bounded, at 500,000 here. Move work out of the prefix, or lower the prefix frames' limits.execution . The signature-verification variant means the signatures alone already exceed it — use fewer.

Building one

The envelope is a type byte followed by a 9-field RLP list:

0x06 || rlp([chain_id, nonce_keys, nonce_seq, sender, frames, signatures, fees, blob_hashes, recent_root_references]) nonce_keys = [0] # the legacy account nonce; or 1..16 strictly increasing keys (EIP-8250) frame = [mode, flags, target, [execution, state], value, data] fees = [max_priority_fee, max_fee, max_fee_per_blob_gas] signature = [scheme, signer, msg, signature] # scheme 1 = secp256k1 recent_root_references = [] # or [source_id, slot, root] tuples (EIP-8272) sig_hash = keccak256(0x06 || rlp(envelope)) # empty-msg signature bytes elided

The smallest useful transaction is therefore two frames: a VERIFY frame targeting the sender with flags = 0x03 , then a SENDER frame carrying the actual call. flags bits 0 and 1 are the APPROVE scope; bit 2 marks an atomic batch, which must be terminated by a following non-batch frame.

A frame's two budgets are independent: execution pays for running code, state pays for state growth. Execution gas cannot cover state growth, so a frame that writes new state with state: 0 halts on that write and burns its whole execution budget — which looks exactly like an execution limit set too low. Check stateGasUsed on the receipt: if it is 0x0 , the missing budget is the state one. Unused state gas is refunded.

Run a node

Peers as published, also served as JSON at /bootnodes :

Execution --bootnodes

enode://68195ca1f7a5b6d1d19ba79372fa020fe1d6ba482951015491da2ead975a7dfda83794227b431f361feb06709cfeef103321e7cb14bf10124e48915c0b466c6c@57.129.136.74:32000

enode://cbc30bbc5d472aa30bfd6669f695496c1e1f0c1d8e03dc436c857d4deae2bbb0d8d651badd0c265a5827706531aed8826817feace79bacc2ee142b18e933c767@57.129.136.74:32007

enode://b29dc4c8bacace3994db668d0ee67aeb90f7fedb629c80521487f712183500b206942152baa5e989e7c7845079e71ba198cb8083ff3fe7342b11a20c52f559d2@57.129.136.74:32014

Consensus --boot-nodes

enr:-Oy4QJNvdqpTj2jcKQ4LDoZYktKKzk7e9YvXVSZqOh3XhY8sU75nnFSMyWXmkucl1qGg7zthxP0POdsP8YEReRBcw_ULh2F0dG5ldHOIAAAAMAAAAACDY2djgYCGY2xpZW500YpMaWdodGhvdXNlhTguMS4zhGV0aDKQJFYdn5AAADj__________4JpZIJ2NIJpcIQ5gYhKg25mZIQAAAAAhHF1aWOCeRuJc2VjcDI1NmsxoQNqnZvzB6IH06v5KdYiVq46xHMbKhMCq8ex9_JHvIUnHIhzeW5jbmV0cw-DdGNwgnkYg3VkcIJ5GA

enr:-Oy4QE9Aw-q2TNg1FV8fZSyNuLEtCYOPGUoV2kRSN-uNLbqjCfJrTbGR-JlvrdAKA8Y2FAWfRBzSWyK2PPaHozXnE_wdh2F0dG5ldHOIAAwAAAAAAACDY2djgYCGY2xpZW500YpMaWdodGhvdXNlhTguMS4zhGV0aDKQJFYdn5AAADj__________4JpZIJ2NIJpcIQ5gYhKg25mZIQAAAAAhHF1aWOCeSKJc2VjcDI1NmsxoQJ9wd23jUM1i6owEn3YvlpfO0Lw6PCuK3cRlZ8RNpVfg4hzeW5jbmV0cw-DdGNwgnkfg3VkcIJ5Hw

enr:-Oy4QF-0_4g7CpG9CbMuVfgTkoeyV1pjtyh9GIpzdreiCyd9PKM3yVx2ITrndI4nysgXimn_ftlM0pg_AdsoLW8rSSUTh2F0dG5ldHOIAAAwAAAAAACDY2djgYCGY2xpZW500YpMaWdodGhvdXNlhTguMS4zhGV0aDKQJFYdn5AAADj__________4JpZIJ2NIJpcIQ5gYhKg25mZIQAAAAAhHF1aWOCeSmJc2VjcDI1NmsxoQLiY7GY_bdflSKdntrJkVD_zNJCwoalcE2cN4EEaUP_fYhzeW5jbmV0cw-DdGNwgnkmg3VkcIJ5Jg

Execution layer, from the bundle's genesis.json and bootnodes.txt ethrex --network genesis.json \ --bootnodes "$(paste -sd, bootnodes.txt)" \ --nat.extip <your public IP> \ --syncmode full

Consensus layer, against the execution client's engine port lighthouse beacon_node \ --testnet-dir=. \ --execution-endpoint=http://127.0.0.1:8551 \ --jwt-secrets=<path to the jwtsecret your EL generated> \ --boot-nodes="$(paste -sd, bootnodes-cl.txt)"

--nat.extip is what the node advertises in discovery and in its ENR; --p2p.addr is only the bind address and is not a substitute. To confirm you are following the chain, compare a block hash against rpc1 at the same height, not just the height.

Become a validator

Validator entry is permissioned; everything else on this chain is not. Contact us with the address you will deposit from — not the withdrawal address, not the validator pubkey. We mint a deposit token to that address; ask for the 32 ETH stake at the same time, since it is beyond the faucet's drip. Without the token the deposit reverts with Not enough tokens ; with it, the deposit burns the token and works.

1. Choose execution-layer withdrawal credentials. 0x01 , 0x02 and 0x03 are allowed with a token; BLS 0x00 deposits are blocked outright. Top-ups to an existing validator ( 0xffff ) need no token.

2. Generate deposit data against this chain's genesis fork version, 0x10000038 . Signed against anything else, the execution transaction succeeds and the consensus layer rejects the deposit. With ethdo :

ethdo validator depositdata \ --validatoraccount=<wallet>/<account> \ --withdrawaladdress=<your 0x01 address> \ --depositvalue="32 Ether" \ --forkversion=0x10000038 \ --raw

3. Deposit 32 ETH from the granted address, with the calldata --raw printed. Let the tool estimate gas:

cast send --rpc-url https://rpc1.privacy.ethrex.xyz \ --private-key <DEPOSITOR_KEY> --value 32ether \ 0x00000000219ab540356cBB839Cbe05303d7705Fa <CALLDATA>

A successful deposit consumes exactly one token and emits the standard DepositEvent . Activation follows the protocol's queue, roughly an hour; watch the pubkey from your own beacon node or in the explorer , and run a validator client against your own node from "Run a node" before it activates, or it starts accruing missed-attestation penalties from its first active epoch.