Puffer Preconf

Puffer Preconf (by @puffer_finance) is a preconfirmation AVS on @eigencloud, enabling the speed and composability needed for rollups! 🚀

[Puffer Preconf @puffer_preconf]

https://t.co/3D4lZS3vnx

[Puffer Preconf @puffer_preconf]

🧩 Preconf Series #8: Roadmap

Puffer Preconf is rolling out in phases, moving from initial launch to a fully slashable security model.

🟢 Phase 1: Gateway Delegation
@gattacahq serves as the first production gateway, enabling ~100ms execution preconfs for OP Stack rollups. Validators can opt in through @eigencloud, delegate to the gateway, and earn ETH-denominated rewards, with reward forfeiture for missed proposals.

🟡 Phase 2: Multiple Gateways
More gateway providers come online, improving redundancy, competition, and service quality. Enhanced lookahead helps gateways coordinate more predictably and reduce gaps between handoffs.

⚪ Phase 3: Full Slashing
The complete slashing model goes live, with 1 ETH penalties for liveness failures and 1,000 ETH penalties for malicious MEV extraction. Slashed funds are redistributed to affected parties, not burned.

Puffer Preconf gets stronger with every phase. 🐡

[Puffer Preconf @puffer_preconf]

Dedicated execution gives each application the environment it needs.

Puffer Preconf gives that environment fast, credible execution guarantees before Ethereum settlement.

Apps get their own performance profile without being cut off from Ethereum’s liquidity, state, or security. 🐡

[Puffer UniFi 🐡⛓️ @puffer_unifi]

📖 Glossary: Dedicated Execution

Dedicated execution means an app gets its own execution environment, designed around its own needs.

In a traditional rollup, every application shares the same execution environment. Trading, gaming, payments, social apps, and AI agents all compete for the same blockspace and performance profile.

But not every application needs the same thing.

Some need low latency. Others need high throughput. Others need specialized execution environments.

UniFi based appchains are designed differently.

They give applications dedicated execution without turning them into isolated chains. Through synchronous composability, appchains can remain connected to Ethereum L1 liquidity, state, and coordination.

Dedicated execution for apps.

Ethereum liquidity and composability for the ecosystem. 🐡

[Puffer Preconf @puffer_preconf]

Shared truth makes atomicity possible. Puffer Preconf makes it usable in real time.

Ethereum L1 provides the canonical data. Preconfs provide execution certainty before settlement.

Together, UniFi based appchains stay fast, atomic, and Ethereum aligned. 🐡

[Puffer UniFi 🐡⛓️ @puffer_unifi]

⚛️ Synchronous Composability on UniFi #5 - Atomicity Requires Shared Truth

Synchronous composability depends on where the data lives.

For a rollup, data availability means making transaction data available so others can verify what happened. UniFi chooses Ethereum L1 DA, which means this data is posted to Ethereum itself through blobs, not to an external DA layer.

Why L1 DA? 👇

1️⃣ Atomicity requires a shared truth

All chains in the interaction need to agree on what happened. With L1 DA, every participant can verify against Ethereum as the same canonical source.

2️⃣ Proof-generated bridging depends on L1 DA

UniFi provers re-execute rollup state transitions by reading transaction data from Ethereum blobs.

3️⃣ Signal Service reads from L1

Signal Service passes L1 state to UniFi appchains within the same Ethereum slot.

4️⃣ Based sequencing is L1-native

UniFi uses Ethereum validators to sequence L1 and L2, so the data being sequenced should remain verifiable by Ethereum.

5️⃣ Ethereum alignment

L1 DA keeps UniFi appchains anchored to Ethereum’s data availability, sequencing, settlement, and verification.

Alt DA can offer higher throughput and lower cost per byte, but it adds another dependency to the critical path.

For UniFi, that means appchains stay atomic and Ethereum-aligned. For users and builders, it means scaling without isolated trust assumptions.

Shared truth for real synchronous composability. 🐡

[Puffer Preconf @puffer_preconf]

🧩 Preconf Series #7: Security Properties

Preconfirmations only matter if users can trust the promise behind them. Puffer Preconf security is built around three pillars:

🪙 Economic Security
Slashable commitments backed by 2.02M+ restaked ETH through @eigencloud, turning execution promises into economic accountability.

🟢 Liveness Guarantees
Ethereum L1 liveness plus gateway redundancy keep preconfs available even if one service path fails.

🌐 Neutrality
Permissionless access and transparent on-chain registries. No token gating. No closed operator set.

Together, these properties give L2s preconfs that are economically backed, highly available, and open by design. 🐡

[Puffer Preconf @puffer_preconf]

🧩 Preconf Series #6: Rewards Distribution

Fast execution needs aligned incentives. Puffer Preconf rewards are designed to give participating validators more consistent incentives while addressing two common problems: volatile fees and infrequent payouts.

The model does this through five key pieces 👇

💸 Preconf Fees
Users pay for execution preconfs, creating the core reward stream for participating validators.

🌊 MEV Smoothing
Fees can be volatile, so rewards are smoothed over time to make validator income more stable and predictable.

Ξ ETH Payouts
Rewards are paid in ETH, keeping payouts liquid, simple, and native to Ethereum.

📈 Competitive Earnings
Validators can earn additional rewards on top of traditional PBS economics by participating in the preconf process.

🤝 L2 Operator Share
Revenue is shared with rollup/appchain owners too, helping make based rollup economics viable for L2 teams.

Puffer Preconf turns speed into fees, and fees into aligned participation.

[Puffer Preconf @puffer_preconf]

Sync composability cannot be delivered by one bridge, one sequencer, or one proving system. It requires a stack where each layer solves a different part of the problem.

Real-time proving handles L2→L1. Signal Service handles L1→L2. Shared sequencing handles L2→L2.

Puffer Preconf sits across all three, adding the timing and execution guarantees that turn each path from theoretically possible to practically credible. Signed commitments. Slashable collateral. State at confirmation equals state at execution.

Without Preconf, the stack has gaps. With Preconf, the stack is complete. 🐡

[Puffer UniFi 🐡⛓️ @puffer_unifi]

⚛️ Synchronous Composability on UniFi #4 - The Synchronous Composability Stack

Synchronous composability matters because it is what allows Ethereum to scale without losing the property that made it powerful: applications that can interact as part of one shared execution flow.

However, synchronous composability cannot be achieved by one bridge, one sequencer, or one proving system. It requires a full stack where each layer solves a different part of atomic interaction across execution environments.

On UniFi, that stack has four layers:

👉 Real-time proving enables the L2 → L1 path. TEE provers re-execute the rollup state transition, the L1 contract verifies it on-chain, and withdrawals can be released because the state was verified.

👉 Signal Service enables the L1 → L2 path. It lets UniFi appchains access L1 state within the same Ethereum slot, without relying on third-party messaging, off-chain verifiers, or RPC nodes to poison.

👉 Based sequencing + Puffer Preconf adds timing and execution guarantees. Signal Service makes L1 ↔ L2 operations possible, but Preconf makes them credible through signed commitments backed by slashable collateral.

👉 Shared sequencing across UniFi appchains enables the L2 → L2 path, where appchains can coordinate execution through the same Ethereum-aligned sequencing root.

This is the key point:

Sync composability is not a single feature.

It is a stack for atomic execution across Ethereum, L2s, and UniFi appchains. 🐡

[Puffer Preconf @puffer_preconf]

Every Puffer Promax execution environment is powered by Puffer Preconf underneath.

That matters because institutions do not just need a chain they control. They need execution certainty they can underwrite.

Sub-10ms signed preconfirmations. The state at confirmation is the exact state that executes.

Gateways post slashable collateral before touching a single slot. Break a commitment, lose collateral. Users are compensated onchain, and the next gateway steps in within two slots.

Real-time L1 withdrawals through proof-generated bridging.

Institutions control the environment. Puffer Preconf makes every commitment inside it credible. 🐡

[Puffer UniFi 🐡⛓️ @puffer_unifi]

The next wave of institutional adoption won’t run on one-size-fits-all chains.

It needs custom execution environments with control, privacy, compliance, and market design built in.

@AmirOnchain explains the vision behind Puffer UniFi’s institutional rollups. 👇

[Puffer Preconf @puffer_preconf]

📖 Glossary: Gateway

A gateway in Puffer Preconf is an operator that receives delegated block proposal rights from Ethereum validators via the lookahead mechanism and uses those rights to order rollup transactions and issue signed slashable execution preconfirmations to users, committing that the state at confirmation is the exact state that will execute and settle on Ethereum.

Gateways post slashable collateral before touching a single slot, and if they break a commitment, collateral is slashed on-chain and affected users are compensated automatically. If a gateway fails or goes offline, automatic failover occurs in under two slots with no manual intervention.

The gateway architecture is what enables Puffer Preconf's win-win revenue model: gateways route sequencing fees to validators, gateways, and appchain owners, turning based sequencing from a decentralization mechanism into a compounding economic flywheel.

[Puffer Preconf @puffer_preconf]

Fast confirmations should be slashable, not trusted.

Most rollups ask users to trust a centralized sequencer for fast confirmations. Puffer Preconf changes that: preconfirmations arrive before L1 settlement, backed by validator-aligned collateral and enforceable commitments.

Break the commitment, risk the collateral.

Fast rollup UX with real accountability. 🐡

[Puffer Preconf @puffer_preconf]

Puffer Preconf inherits based sequencing. Ethereum validators order the chain, gateways receive delegation via the lookahead, and slashable execution commitments are issued on top of that inherited ordering.

The centralized sequencer is replaced by based sequencing, with Puffer Preconf serving as the execution certainty layer.

Decentralization and speed from the same architecture. 🐡

[Puffer UniFi 🐡⛓️ @puffer_unifi]

Puffer UniFi Eliminates the Centralized Sequencer Trade Off. 🐡

Most rollups rely on centralized sequencers for a fast UX, but that concentrates control over ordering, inclusion, and confirmations in a single operator.

UniFi removes the need for a standalone rollup sequencer through based sequencing. Ethereum validators order the chain instead.

@puffer_preconf adds sub-100ms slashable execution guarantees on top, delivering speed without centralized sequencer risk.

[Puffer Preconf @puffer_preconf]

Signal Service solves L1→L2. Puffer Preconf solves what comes after.

Same-slot L1 access lets apps read fresh data and act without third-party bridges. Signal Service delivers the data.

Puffer Preconf ensures execution is backed by slashable collateral.

No third-party bridge dependency. No execution uncertainty. Both are needed for synchronous composability that’s trustworthy, not just fast. 🐡

[Puffer UniFi 🐡⛓️ @puffer_unifi]

📖 Glossary: Signal Service

Signal Service lets UniFi appchains access and use Ethereum L1 data within the same slot, without relying on third party bridges.

Without Signal Service, L2 apps accessing L1 state depend on bridges with off chain verifiers reading RPC nodes that can be manipulated. Signal Service removes that dependency. L1 signals are registered, imported into L2, and used immediately. Verification happens through contract calls, not trusted intermediaries.

This enables same slot deposits, fresh L1 oracle reads, and the L1 to L2 leg of synchronous composability on UniFi.

Signal Service handles L1 to L2. Proof generated bridging handles L2 to L1. Based sequencing adds timing and execution guarantees across both. 🐡

[Puffer Preconf @puffer_preconf]

Fast UX with a centralized sequencer: the sequencer promises. You trust.

Fast UX with Puffer Preconf: the gateway commits. Slashable collateral enforces.

The state confirmed to the user is the state that executes. Break that commitment and lose collateral. No exceptions.

That is the difference between speed and guaranteed speed. 🐡

[Puffer UniFi 🐡⛓️ @puffer_unifi]

⚙️ Based Appchains on UniFi #3 - Guaranteed Execution Before Settlement

Ethereum rollups made transactions faster by moving execution off L1. But in most rollups, that speed still depends on a centralized sequencer confirming transactions before they settle on Ethereum.

That creates a trade-off for builders: fast UX, but with an extra trust assumption in the middle of execution.

UniFi based appchains use Ethereum-aligned preconfirmations provided by @puffer_preconf to confirm the expected result of a transaction before it settles on Ethereum.

This means the state confirmed to the user is the exact state expected to be executed on the appchain and settled to Ethereum, backed by economic enforcement: slashing.

For builders, this means apps can give users faster feedback without relying only on trust in a centralized operator.

This matters most for apps where timing is critical: trading, payments, liquidations, games, and any experience where waiting for Ethereum settlement is too slow.

Fast confirmations. Economically backed execution. Settlement on Ethereum.

Built into every UniFi appchain from day one. 🐡

[Puffer Preconf @puffer_preconf]

📖 Glossary: Based Sequencing

Puffer Preconf’s sequencing model where Ethereum L1 validators order rollup transactions by delegating proposal rights to gateways through the lookahead mechanism.

This is what keeps execution aligned with Ethereum at the ordering layer.

@puffer_unifi uses based sequencing to remove the centralized sequencer and add timing and execution guarantees to L1 ↔ L2 interactions, turning synchronous composability from merely possible into trustworthy. 🐡

[Puffer Preconf @puffer_preconf]

Ordering. Validity enforcement. Execution certainty.

These are the three things Puffer Preconf adds to UniFi’s composability stack.

Ethereum validators coordinate ordering through based sequencing. Slashable gateway collateral enforces validity — the state at confirmation becomes the state at execution, enforced on-chain. Sub-100ms execution certainty before the block lands.

State access is Signal Service’s role: same-slot L1 state passing to UniFi appchains.

Together, the full stack delivers what synchronous composability actually requires. Not a soft promise. Not a fast bridge.

Coordinated, verifiable, enforceable execution. 🐡

[Puffer UniFi 🐡⛓️ @puffer_unifi]

⚛️ Synchronous Composability on UniFi #2 - More Than Speed

Synchronous composability is not just about making cross-chain interactions faster.

It is about making separate execution environments behave like one coordinated system, where transactions can resolve atomically within the same block.

This matters because speed alone does not solve fragmentation. A bridge can be fast and still be asynchronous. A message can arrive quickly and still depend on stale state, external verifiers, or a sequencer’s promise.

For true atomic execution, three things have to work together: ordering, state access, and validity enforcement.

👉 Ordering means transactions across environments need to be coordinated. If two chains rely on separate sequencers, there is no native guarantee that both sides land in the same block in the correct order.

👉 State access means one environment must be able to read another environment’s state within that block, instead of relying on stale data from a previous block.

👉 Validity enforcement means the result cannot depend on a sequencer’s soft promise. The state transitions have to be cryptographically verifiable.

UniFi is designed around this full problem: coordinated ordering, same-slot state access, and verifiable execution across Ethereum-aligned appchains. 🐡

[Puffer Preconf @puffer_preconf]

📖 Glossary: Revenue Sharing (Win-Win Model)

Sequencing rewards shared between Ethereum validators and appchain owners.

Previously, based sequencing meant ceding all fees to L1 validators. Appchain owners could participate in decentralized sequencing, but captured none of the revenue it generated.

Puffer preconf introduces a shared model through the gateway architecture. Validators delegate proposal rights to gateways. Gateways route sequencing revenue to both sides. Validators earn from appchain activity, while appchain owners capture priority fees, congestion fees, and define sequencing rules that shape how value flows through their execution environment.

The result: decentralization and revenue participation are no longer a trade-off.

More based appchain activity means more revenue for validators. More validator participation means stronger economic security for appchains.

Ethereum and based appchains win together. 🐡