Hegotá privacy testnet faucet

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.

Chain ID

8141 (0x1fcd)

RPC

https://rpc1.privacy.ethrex.xyz

Explorer

dora.privacy.ethrex.xyz

Bundle

faucet.privacy.ethrex.xyz/artifacts

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.

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, recent roots in a verifier frame. 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.

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

0x06 || rlp([chain_id, nonce_keys, nonce_seq, sender, frames, signatures, fees, blob_hashes])
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
sig_hash   = keccak256(0x06 || rlp(envelope))     # empty-msg signature bytes elided
# recent roots (EIP-8272): a leading VERIFY frame to 0x…8272, flags 0, state 0,
#   data = (source_id ‖ uint64_be(slot) ‖ root) × 1..16

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.

Read the changelog before syncing: a relaunch means a fresh genesis, and a database from the previous chain has to be wiped.

# 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.

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.

Newest first. Every relaunch, and every change a node operator or transaction builder has to act on, gets an entry here with the date it took effect. The exact rule set and pins are in the network spec.