Pickle Chain for developers

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 on the public testnet this reference documents, 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

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 public testnet answers at https://rpc.picklechain.xyz. The examples throughout write it as $RPC_URL, so the same command runs unchanged against a node of your own:

export RPC_URL=https://rpc.picklechain.xyz

curl -s "$RPC_URL" \
  -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. The call itself needs no key, no account and no header beyond a content type: the node authenticates nothing and answers anyone who can reach it. Test ETH comes from the faucet, one claim per address every 24 hours, and the state may be reset without notice.

Where to go next

• Network parameters - the constants, in one table.
• JSON-RPC reference - all 61 registered methods.
• Deviations from Ethereum - read this before you debug your client.
• History and retention - read this before you write an indexer.
• Real-world assets - the price layer: how to get the asset list and how to read a price.
• Application APIs - the first-party HTTP surfaces, which are a convenience and not the chain.
• Token list and address tags - how a token gets its logo and the verified mark, and a contract its label: a pull request.
• The explorer - the archive the node is not.
• The faucet - test ETH and test PKL, against a pasted address.