For developers / Start here

Pickle Chain for developers

Live

An Ethereum Layer 2 that executes your transaction immediately, hands back a signed preconfirmation, and seals an ordinary Ethereum-shaped block around it. Gas is paid in ETH. Everything here is Phase 0, and Phase 0 is a single-operator testnet.

What it is

Pickle runs a custom Rust sequencer with revm pinned to Cancun. When you send a transaction it executes at once - eth_sendRawTransaction blocks until the result exists rather than returning a promise of one - and a receipt is available within the mini-block scheduling target of about 10 ms. An Ethereum-shaped block wrapping those mini-blocks is sealed at a scheduling target of about 250 ms, and that block is what wallets and explorers treat as a confirmation.

The chain is ordinary from a tooling point of view in the ways that matter most: chain ID 78270, ETH for gas, a 30,000,000 block gas limit, standard JSON-RPC, and Cancun-shaped block headers. forge, ethers, viem and MetaMask all work against it. It is unusual in ways that matter too, and those have their own page rather than a paragraph here.

What it is not

Phase 0 is a single-operator testnet

  • One sequencer orders every transaction and can reorder or censor. If it halts, the chain halts for new execution.
  • The bridge messenger is a trusted key.
  • There is no forced inclusion, and there are no fraud or validity proofs. An independent replica can re-derive the chain from Ethereum and the data-availability layer and detect a divergence, but nothing arbitrates one yet.
  • Development keys are in use throughout, and they are published keys.
  • Test coins and test PKL have no monetary value and are not redeemable for anything.
  • Chain state may be reset without notice during Phase 0, which deletes balances, contracts and history.

Pickle does not describe itself as decentralised, and this documentation publishes no throughput figure. The two cadence numbers above are scheduling targets - intervals the block producer aims for - and not latency guarantees or a claim about throughput. The sealer skips a late tick rather than catching up.

It is also not fully EVM-equivalent, and the gaps are published as their own page rather than left for you to find at runtime. The short version: state reads ignore the block parameter, there is no archive, and error.data is never populated, so your library cannot decode a custom error.

The shape of it

A transaction passes through three tiers, and knowing which one you are observing is most of what makes this chain legible:

  • Execution - immediate, synchronous with your RPC call. A revert is known here.
  • Preconfirmation - a mini-block, signed by the sequencer, at a ~10 ms scheduling target. Your receipt exists, and its blockNumber is still null.
  • Confirmation - an EVM block, at a ~250 ms scheduling target. Now blockNumber and blockHash are populated.

Finality is a fourth and separate event: it happens after the containing batch settles on Ethereum. This site uses the word for nothing else.

Your first call

The endpoint is public and CORS is open, so this works from a terminal or from a browser page on any origin:

bash
curl -s https://rpc.picklechain.xyz \
  -X POST -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

# {"jsonrpc":"2.0","id":1,"result":"0x131be"}

0x131be is 78270. Nothing above needs a key, an account or a header: the endpoint is open, and CORS is set at the edge so a browser page on any origin can call it too.

Where to go next

The contracts and the APIs are not here yet

They are written and deliberately unpublished: a reference to a contract nobody can call, with no address to call it at, costs a reader time and gives nothing back. They arrive when the testnet is publicly live. Until then the code is the reference.