Summary: Puffer Preconf is best understood as a gateway-mediated based-rollup preconfirmation control plane rather than as just another fast-confirmation add-on for L2s. Its primary materials split the system into EigenLayer-registered operators and validators, gateway operators that actually issue execution preconfirmations on delegated proposers’ behalf, a lookahead schedule that decides which gateway temporarily controls L2 state writes, and a fee-sharing layer that explicitly tries to keep some sequencing economics with the L2 instead of ceding everything to L1 proposers. The reusable mechanism insight is that Puffer turns preconfirmations into a bundle of distinct control surfaces — gateway delegation, lookahead scheduling, execution-state guarantees, restaked collateral, and revenue-sharing policy — while also revealing that the currently live phase is materially softer than the full-slashing end state emphasized in the broader pitch.
What it does:
Offers ~100ms execution preconfirmations for based rollups and OP-stack-style L2s through a gateway-operated service layer
Lets Ethereum validators and EigenLayer operators opt into an AVS and delegate preconfirmation service to gateways such as Gattaca
Uses a lookahead-driven gateway schedule so the selected gateway has temporary exclusive write access to L2 state for upcoming L1 slots
Positions execution preconfirmations, not just inclusion promises, as the core user guarantee so the promised execution outcome is meant to match the final state exactly
Splits preconf fees among L2 operators, validators, and gateways so based-rollup economics do not flow entirely to L1 proposers
Frames Commit-Boost compatibility and multi-gateway expansion as the path toward a broader neutral preconfirmation market
Key claims:
The intro docs say Puffer Preconf is an EigenLayer-based preconfirmation service that targets roughly 100ms confirmations for L2 rollups and is built around gateways issuing preconfs on behalf of Ethereum validators.
The protocol docs make the architectural split explicit: users send transactions to a gateway RPC, operators delegate validator rights to gateways, the gateway consults a lookahead window to determine upcoming delegated proposers, and RewardsManager / AVS contracts handle registration and reward distribution.
The docs emphasize execution preconfirmations rather than simple inclusion promises, which is analytically important because it makes state-locking and exact execution guarantees the product claim rather than merely faster mempool acknowledgement.
The protocol docs also make the control surface around temporary L2 write access explicit: whichever gateway is active in the lookahead gets the exclusive right to advance L2 state for its assigned slots and can therefore sell preconfirmation guarantees during that window.
The roadmap and validator guide reveal an important caveat beneath the headline security rhetoric: the currently described Phase 1 model does not yet slash validators and instead relies on gateway delegation plus reward forfeiture, with fuller slashing and wider gateway competition deferred to later phases.
The validator guide says Phase 1 is effectively single-gateway today, with Gattaca as the primary production gateway and validators trusting that gateway to perform honestly, which makes current centralization and delegation structure more important than the neutral long-run posture alone would suggest.
The repository README and docs repeatedly position the system as neutral and permissionless, explicitly rejecting token-gated participation and highlighting Commit-Boost integration, but the stronger analytical frame is that Puffer is trying to standardize a gateway-and-AVS market for based-rollup execution promises rather than merely ship a faster rollup UX feature.
Whitepaper: A UniFi litepaper is linked from the project repository, but the strongest materials reviewed in this pass were the official Puffer Preconf docs, roadmap, validator guide, and repository README collected in ../whitepapers/puffer-preconf-primary-sources-2026-05-11.md.
Reusable lens: when a project promises based fast confirmations, ask who controls the delegated gateway, the lookahead window, and the penalty path when execution promises fail.