Frames testnet faucet

A public test network running EIP-8141 frame transactions on ethrex. Test ETH has no value.

What this chain enables

EIP-8141 Frame transactions: a new type 0x06 whose payload is a list of frames, each executed with its own target, mode and two gas budgets, with payment authorised by an APPROVE in a validation prefix.

That is the only addition. Everything else is Amsterdam, so a failure here is a frame-transaction failure, which is what makes the chain useful to implementers.

Connect

Chain ID: 81410 (0x13e02)
RPC: https://rpc1.frames.ethrex.xyz
Explorer: dora.frames.ethrex.xyz
Bundle: faucet.frames.ethrex.xyz/artifacts

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 rex can build and send one directly.

Send one with rex

Install from the frames-testnet branch:

cargo install --force --locked --git https://github.com/lambdaclass/rex --branch frames-testnet

rex on main depends on the published ethrex crates, which encode a frame's gas budget as a single scalar and sign in the 27/28 form. This chain rejects both. The frames-testnet branch git-pins ethrex's frames-devnet-0, so it speaks the wire format this chain actually runs. Reinstall rather than reusing an older binary.

# Self-verified transfer: a VERIFY frame approving execution and payment,
# then a SENDER frame that moves the value.
rex frame send \
  --to 0xRecipientAddress \
  --value 1gwei \
  --private-key <YOUR_PRIVATE_KEY_HEX> \
  --rpc-url https://rpc1.frames.ethrex.xyz

# Preview the raw 0x06 bytes without submitting:
rex frame send --to 0x… --value 1gwei --private-key <KEY> --dry-run

# Decode a mined one, frame by frame:
rex frame inspect <TX_HASH> --rpc-url https://rpc1.frames.ethrex.xyz

--frame-gas-limit and --frame-state-gas-limit set the SENDER frame's two budgets. The state one defaults to 250,000, which covers a transfer to an address that does not exist yet; rex frame build --frames '[…]' reaches the modes and flags send does not expose.

Common errors

frame N uses the Scalar encoding, but this block requires Limits

The encoder predates two-dimensional gas and is sending slot 3 as a scalar. This chain accepts only the [execution, state] form — you are on a released rex rather than the branch above.

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

Missing state budget, not execution. Raising --frame-gas-limit will not help; raise --frame-state-gas-limit.

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 7-field RLP list:

0x06 || rlp([chain_id, nonce, sender, frames, signatures, fees, blob_hashes])

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

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.

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.

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.

Run a node

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

Execution --bootnodes

enode://e82b6eb2cc38fa49ece9aa92e414fa499201e6834f3e4143787dc6099b491de6867170d17b11ec108e0e6d86e01852801fb720926e154d0678461b2c5afaa713@181.104.27.112:36000
enode://593c0399f303725dd2bb38a17292fe93de3f510a4dbc1d4408a34b503dd1cb09e606b85f5cad14361b1f4d90076d27df9545d6b2932efd8ad389eb02121e5d4e@181.104.27.112:36007
enode://5c5c48b3487a36e7d6981b896ee84d94747f64194d06ad212596ef16690372c18829c252919f796d5da7f729d81e073e20a546ba96e140042fc54e08589f85a9@181.104.27.112:36014

Consensus --bootstrap-node

enr:-Ni4QKzKW92TwYe316945vQFtrLhudLroLhOSiZ7-jNu6ekDfB7e405rgQUKvQ4KjO3LVUciyua41RDPkOZFyRRTWOCGAaBJQrYuh2F0dG5ldHOIAAAAAAAADACDY2djBIRldGgykCCu1cyAAAA4__________-CaWSCdjSCaXCEtWgbcINuZmSEAAAAAIRxdWljgo1oiXNlY3AyNTZrMaECkXH1lLnl0NBwtcblSBDlczFdZ8bbhZoQlUuySvJhuXWIc3luY25ldHMPg3RjcIKNaIN1ZHCCjWk
enr:-Ni4QIXeRMDBk8AmtvkeoQ3NHAH_lToCsXta7FM6aAevSWZxfscH3A78l1qzXEjrwoiExqWi9YavCqvgaI_jJHuqyfiGAaBJQsFOh2F0dG5ldHOIAAAAAADAAACDY2djBIRldGgykCCu1cyAAAA4__________-CaWSCdjSCaXCEtWgbcINuZmSEAAAAAIRxdWljgo1viXNlY3AyNTZrMaECawFUqze34fkoeRkYdM9v4WHXbcS1ivpw6xv5XQV7_wSIc3luY25ldHMPg3RjcIKNb4N1ZHCCjXA
enr:-Ni4QImWs_pNZcBGi4GhUX5M8KcZNO6LU8pfJhLNGaaOND_IDIYfNvdw0xIavP2Tr8n-PNb42PLSBStcq2jMUa6W2uOGAaBJQsF2h2F0dG5ldHOIAAAAGAAAAACDY2djBIRldGgykCCu1cyAAAA4__________-CaWSCdjSCaXCEtWgbcINuZmSEAAAAAIRxdWljgo12iXNlY3AyNTZrMaEDook0zcGkpiqXCP50MtFE5bcHDoFWGaQpwAPJC99TVkeIc3luY25ldHMPg3RjcIKNdoN1ZHCCjXc

Sync from a checkpoint, not from genesis. Ask us for a beacon endpoint to pass to --checkpoint-sync-url. Started at genesis the consensus client stalls in payload-envelope backfill and leaves your execution client stranded a few blocks in. Check the execution client separately from the beacon node — a beacon node can sit at head while its execution client is still at genesis.

Become a validator

Validator entry is permissioned; everything else on this chain is not. Anyone may sync, peer and transact without asking.

To run one, contact us with the address you will deposit from and we will grant it a slot. Without that grant the deposit reverts with Not enough tokens.

Then: deposit 32 ETH with 0x01 withdrawal credentials, signed against genesis fork version 0x10000038. BLS 0x00 credentials are rejected. Have a validator client running before it activates, or it starts accruing missed-attestation penalties. Exiting is possible 256 epochs after activation, about 14 hours.