For everyone / How it works
The trust model
A description of the mechanism without the trust model is marketing. This page states what a user of Pickle relies on, and names the three properties the chain would need before it could call itself anything more.
What a user relies on
One computer, run by one team, decides what happens on the chain and in what order. If it is honest and switched on, everything works. If it went wrong it could put its own actions first, leave yours out, or stop entirely, and nothing on the network would stop it. What it cannot do is lie about the past without being caught: a copy of every block goes to Ethereum, and anyone can replay it and see the difference. Being caught is not the same as being prevented, and nothing acts on it automatically.
A user relies on the operator's honesty, plus the fact that the data needed to check it is public. One sequencer orders every transaction and can reorder or censor. There is no forced-inclusion path from Ethereum. There are no fraud or validity proofs; correctness is checked by re-execution, and any replica that finds a divergence between the published data and the committed block hash halts, but nothing on-chain arbitrates the divergence. What makes that meaningful is the data: everything needed to rebuild the chain is on Ethereum or committed to from Ethereum.
A single sequencer holds ordering and liveness; its key is held in an on-chain registry and can be rotated, effective the next block. There is no forced-inclusion queue on the L1. Correctness is re-execution: replicas derive from inbox events and payloads, and a hash mismatch is terminal for the replica and unarbitrated on-chain. A signed mini-block that a later block contradicted would be evidence, and the design records that evidence; it does not yet act on it. The batcher and messenger keys are distinct, enforced at startup, and the messenger cannot forge or replay because message identifiers are derived from the originating event and recorded once finalised.
Ordering, liveness, correctness, data, bridge
| Property | Who or what |
|---|---|
| Ordering | one sequencerit can reorder and it can censor. There is no forced-inclusion path from Ethereum |
| Liveness | the sequencer'sif it stops, mini-blocks stop and the chain halts for new execution; replicas keep serving derived history |
| Correctness | checked by re-executionno fraud or validity proofs. A replica detects a divergence and halts; nothing on-chain arbitrates it |
| Data | on Ethereum, or committed to from iteverything needed to rebuild the chain is public |
| Bridge | a trusted messenger keyit cannot forge or replay a message, but it can delay |
- Ordering. One sequencer orders every transaction. It can reorder and it can censor. There is no forced-inclusion path by which a transaction refused by the sequencer can be included from Ethereum.
- Liveness. If the sequencer stops, mini-blocks stop and the chain halts for new execution. Replicas continue to serve derived history. The sequencer key is held in an on-chain registry and can be rotated, effective the next block.
- Correctness. There are no fraud or validity proofs. Correctness is checked by re-execution: any replica can detect a divergence between the published data and the committed block hash, and halts when it does. Nothing on-chain arbitrates such a divergence. A signed mini-block that a later block contradicted would be evidence, and the design records that evidence; it does not yet act on it.
- Data. Everything needed to rebuild the chain is on Ethereum or committed to from Ethereum. This is the property that makes the previous point meaningful.
- Bridge. The bridge messenger is a trusted key. It cannot forge or replay a message, because identifiers are derived from the originating event and recorded once finalised, but it can delay. Batcher and messenger keys are distinct, enforced at startup.
The keys
- The sequencer key signs mini-blocks and is the operator's identity. It lives in an on-chain registry and rotates with one block's notice.
- The batcher key is the only address the Ethereum inbox accepts appends from. A compromised batcher could stop posting, which stalls settlement, but cannot forge a payload a replica would accept: the hash would not match.
- The messenger key finalises bridge transfers in both directions. It can delay; it cannot invent a message the contracts never issued or replay one already processed.
What decentralisation would require
Pickle does not use the word decentralised of itself
The specific properties that would have to hold before it could are these: sequencer redundancy and rotation, so that no single operator's liveness is the chain's liveness; a forced-inclusion path from Ethereum, so that no single operator can censor; and a challenge or proof path, so that a divergence a replica detects is arbitrated rather than merely reported.
Until all three hold, a user relies on the operator's honesty plus the public data needed to check it. The governance page lists the attack resistances the design does have, and their limit.