Stateless Plasma Privacy

Use a stateless Plasma architecture to enable private token transfers where transaction data stays with users client-side, only commitments are posted on-chain, and validity is proven via zero-knowledge proofs. This provides strong transaction-graph privacy with L2 scalability, at the cost of moving data-availability responsibility to users.

Works best when

  • High transaction volume with privacy requirements.
  • Users can manage their own transaction data (institutional clients with infrastructure).
  • Minimal L1 data footprint is critical for cost or privacy.

Avoid when

  • Users cannot reliably store or back up their own state.
  • Real-time settlement finality is required (Plasma exits have delay).
  • Complex smart-contract logic is needed (stateless model limits programmability).

I2I vs I2U — context differences

Institution to institution

I2I

Institutions already run reliable off-chain infrastructure, so data custody is a known cost. The value of stateless Plasma at I2I scale is minimal L1 footprint and no shared pool state, which avoids revealing portfolio sizes via gas patterns or commitment volumes. Forced exits via the L1 anchor let either counterparty settle unilaterally if the block producer stalls.

Institution to end user

I2U

End users cannot reliably custody their own data long-term. This pattern is only safe for user-facing deployments when paired with redundant self-hosted or trust-minimized Data Availability. Forced withdrawal is critical: the L1 anchor must accept unilateral exit proofs so a censoring block producer cannot freeze user funds.

Post-quantum exposure

Risk · medium
Vector
Depends on the proof system. FRI-based systems (e.g., Plonky2) are hash-based and already PQ-leaning; KZG-based systems inherit elliptic-curve exposure. BLS signature aggregation on block producers is classically broken by CRQC.
Mitigation
FRI or STARK-based transfer validity proofs plus hash-based or lattice-based signature aggregation on the block producer.

Visibility

Actor Sees
Counterparty
  • amounts
  • identities
Chain
  • block_commitments
  • sender_lists
Regulator
  • full_tx with user-provided viewing material
Public
  • block_commitments

Components

  • L1 anchor contract: stores block commitments (Merkle roots of transaction hashes) and handles deposits, withdrawals, and forced exits.
  • Block producer: aggregates transactions, collects signatures, and posts the block commitment to L1. Stateless with respect to transaction contents.
  • Client-side prover: users generate ZK balance and transfer proofs locally (e.g., recursive FRI-based proofs).
  • User-held Data Availability: users custody their own note and transfer history. Optional trust-minimized DA layer for redundancy.
  • Forced-exit mechanism: L1 contract accepts exit proofs independently of the block producer, bypassing liveness failure.

Protocol

  1. user Deposit an ERC-20 to the L1 anchor contract, which credits a balance commitment on L2.
  2. user Generate a zero-knowledge proof of a valid transfer client-side; send the proof and an encrypted note to the recipient.
  3. operator The block producer collects signatures and proofs, builds a Merkle tree of the new state, and verifies correctness.
  4. operator The block producer posts the state root to L1 as a minimal block commitment.
  5. user The recipient stores the received note locally and can spend it in future transactions.
  6. user To exit, generate an exit proof showing ownership and initiate L1 withdrawal (subject to a challenge period).
  7. contract If the block producer stalls, any user can initiate forced exit against the L1 anchor using their own locally held proofs.

Guarantees & threat model

Guarantees:

  • Transaction amounts, sender, and receiver are hidden from chain observers; only commitments and per-block sender lists are visible.
  • zero-knowledge proofs ensure no double-spend or inflation without revealing transaction details.
  • Users control their own data; no operator can freeze specific balances if forced exit is implemented.
  • Funds are secured by L1; users can always exit with a valid proof.

Threat model:

  • Soundness of the zero-knowledge proof system.
  • Correct implementation of the L1 anchor, especially the forced-exit path.
  • User data loss. A user who loses their local transaction history loses access to their funds; there is no protocol-level recovery.
  • Block producer liveness. A stalled producer halts new transactions; users can still exit unilaterally with their own proofs.
  • Network-layer metadata (timing, IP against the block producer) is out of scope for the pattern.

Trade-offs

  • User responsibility for data backup. Institutions can absorb this cost; individual users often cannot without additional infrastructure.
  • Exit delay. Plasma withdrawals have a challenge period (typically around 7 days) to allow fraud proofs.
  • Limited programmability. The stateless model restricts complex contract interactions compared with privacy rollups.
  • Block producer trust for liveness. Censorship is possible even if theft is not.
  • Client compute. Proof generation requires client-side resources, which is acceptable for institutions but may be demanding for end-user devices.

Example

  • Institution A deposits 1m stablecoin to the L1 anchor and receives a private balance commitment.
  • Institution A transfers 500k privately to Institution B, generates the proof locally, and sends an encrypted note.
  • The block producer includes the transaction in a block and posts only the Merkle root to L1.
  • Institution B receives the note, verifies the proof, and stores it locally.
  • On-chain observers see only that a deposit occurred and that a state root was updated; no amounts and no parties.
  • Institution B can later withdraw to any L1 address, breaking the link to the original depositor.

See also

Open-source implementations