Hegotá devnet faucet

A public test network running the frame-transaction family of EIPs on ethrex. Test ETH has no value. New to these EIPs? Start with the illustrated guide to the stack.

What this devnet enables

EIP-8141	Frame transactions: a new type `0x06` whose payload is a list of frames, each executed with its own target, gas limit and mode, with payment authorised by an `APPROVE` in a validation prefix.
EIP-8250	Keyed nonces: a transaction picks its own nonce domains, so one shared sender address stops being a throughput bottleneck. Useful for privacy pools and relayers.
EIP-8272	Recent roots: a transaction declares verified `(source_id, slot, root)` commitments in its signed envelope, readable from execution without touching another account's mutable storage.
EIP-7906	Transaction assertions: a trailing read-only `POST_TX` frame inspects the whole transaction's effects and can revert the body if an invariant broke.
EIP-7805	FOCIL: each slot a committee publishes inclusion lists that the next block must satisfy, so a builder cannot quietly censor a transaction. The only feature here that the consensus layer implements too.
EIP-8312	UTXO frames: a one-shot payment object that is created once and spent once, leaving a single spent bit rather than a permanent account. A full create-and-spend cycle costs less than one ordinary transfer to a new account. Activates on its own timestamp, separately from the rest.

Inherited from Amsterdam

EIP-7928	Block-level access lists.
EIP-8037	Two-dimensional gas: state growth is priced separately from execution, so a transfer to a fresh account costs far more than 21,000 gas.
EIP-8038	Amsterdam repricing of the access, storage and access-list constants.
EIP-7843	A beacon slot number available to execution.
EIP-8282	Builder deposits and exits via predeploys.

Connect

Chain ID: 3151908 (0x301824)
RPC: https://rpc1.hegota.ethrex.xyz
Explorer: https://dora.hegota.ethrex.xyz

Budget more gas than you expect. Under EIP-8038 a plain transfer that creates an account is far more expensive than the historical 21 000, closer to 210 000 on this chain, because account creation is charged as state growth. Estimate gas rather than hardcoding it; tooling with a baked-in 21 000 will fail here, and it will fail specifically when paying someone new.

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 introduces a new transaction type, 0x06, whose envelope carries a list of frames rather than a single to/value/data. It is a draft, so no wallet and no released version of the common libraries can encode or sign one yet; a wallet asked to send one simply has no representation for it. Submitting one today 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 same is true of the extensions on this network: keyed nonces, recent-root references and POST_TX assertion frames are all fields inside that envelope, so they are reachable only through the same route.

Building one

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

0x06 || rlp([chain_id, nonce_keys, nonce_seq, sender, frames, signatures,
             max_priority_fee, max_fee, max_fee_per_blob_gas, blob_hashes,
             recent_root_references])

frame     = [mode, flags, target, gas_limit, value, data]
signature = [scheme, signer, msg, signature]      # scheme 1 = secp256k1
sig_hash  = keccak256(0x06 || rlp(envelope))      # empty-msg signature bytes elided

mode 0	`DEFAULT`, called by the entry point.
mode 1	`VERIFY`, static; where authorisation happens. A frame targeting `tx.sender` with `flags = 0x03` runs the default code path, checks the outer signature and executes `APPROVE` for both execution and payment. Without an `APPROVE` the transaction has no payer and is invalid.
mode 2	`SENDER`, executes with `tx.sender` as the caller.
mode 3	`POST_TX`, the read-only assertion suffix of EIP-7906. Reverting one reverts the transaction body while the transaction itself stays included with a failed status.

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.

The signature is not in EVM form. Each entry is 65 bytes of v ‖ r ‖ s where v is the bare recovery id, 0 or 1, not 27/28. Anything above 1 is rejected, and it is the single most common reason a hand-built frame transaction is refused.