EIP-8079 Native Rollups: Re-Execution vs Cryptographic Proofs—A Technical Analysis

blockchain_brian · March 15, 2026, 9:33am

The recent EIP-8079 native rollups prototype has sparked interesting discussions about whether the Ethereum ecosystem’s investment in proof systems (zkSNARKs, zkSTARKs, fraud proofs) was necessary. As someone who’s contributed to both Ethereum core development and various L2 implementations, I want to offer some technical context.

What Are Native Rollups?

EIP-8079 introduces an EXECUTE precompile that enables Ethereum L1 to directly re-execute Layer 2 state transitions rather than verifying cryptographic proofs. The approach:

L2 submits transaction batches + execution witness to L1
EXECUTE precompile re-runs the transactions using LEVM
L1 verifies the resulting state root matches the claimed post-state
No ZK proofs, no fraud proof challenge windows—just direct computation

Reference: EIP-8079 on Ethereum Improvement Proposals (EIPs) | ethereum.org

The “Wasted Billions” Narrative Is Missing Context

Let’s examine what proof systems actually achieved:

Optimistic Rollups (Arbitrum, Optimism):

Enabled $186B+ in bridged TVL (Jan 2022-July 2024)
Proved optimistic fraud proofs could work in production
Identified the 7-day withdrawal UX problem we’re now solving
Demonstrated L2s could scale Ethereum to thousands of TPS

ZK Rollups (zkSync, StarkNet, Polygon zkEVM):

Advanced cryptographic proof systems from academic research to production
Achieved constant-size verification (critical for data availability)
Enabled privacy-preserving computation (broader than just scaling)
Proved ZK-EVMs were feasible (considered impossible 5 years ago)

Key insight: We couldn’t have designed native rollups without understanding what proof systems could and couldn’t do.

Technical Trade-Offs: Re-Execution vs Cryptographic Proofs

Computational Cost:

ZK proofs: O(1) verification regardless of L2 computation complexity
Re-execution: O(n) cost scaling with transaction count and complexity
For simple transfers, re-execution wins
For complex DeFi operations, ZK verification may be cheaper

Security Model:

ZK proofs: Mathematical certainty (assuming sound cryptography)
Fraud proofs: Economic security (1-of-N honesty assumption + 7-day delay)
Re-execution: Computational trust (L1 validators re-run the same code)
All three are “secure” but with different trust assumptions

Gas Efficiency:

ZK proof verification: ~300k-500k gas regardless of batch size
Re-execution: Depends on L2 block complexity—could be cheaper or more expensive
Break-even point needs empirical testing

Developer Experience:

ZK circuits: Requires specialized expertise, steep learning curve
Fraud proofs: Complex challenge game implementation
Re-execution: Reuses Ethereum’s state transition function (simpler)

This Is Healthy Protocol Evolution, Not Failure

Consider the historical parallel: Ethereum itself evolved from Frontier → Homestead → Metropolis → Serenity. Each phase taught us what we needed for the next one.

Similarly with L2s:

Plasma (2017-2019): Taught us data availability is critical
Optimistic Rollups (2020-2023): Proved L2s could scale, revealed UX friction
ZK Rollups (2021-2025): Demonstrated cryptographic verification at scale
Native Rollups (2026+): Apply lessons learned to simplify infrastructure

The billions invested weren’t “wasted”—they funded the exploration necessary to understand we could take a simpler path.

Different L2s Will Use Different Approaches

I expect the L2 landscape to evolve toward specialization:

Native rollups: General-purpose L2s, simpler apps, smaller teams
ZK rollups: Privacy-preserving apps, complex DeFi, cross-chain bridges
Optimistic rollups: Existing ecosystems with established TVL and tooling
Hybrid approaches: Some L2s might combine techniques

This is pluralism, not “one approach replacing another.”

Open Questions Requiring Further Research

L1 gas costs at scale: Can Ethereum handle re-executing high-complexity L2 blocks?
MEV implications: Does re-execution create new MEV opportunities?
Upgrade coordination: How do native rollups handle protocol upgrades?
Interoperability: Can native rollups and proof-based rollups compose seamlessly?

Conclusion

Native rollups are an exciting development, but they’re built on foundations laid by proof systems research. The question isn’t “were proof systems a mistake?” but rather “what did we learn, and how do we apply those lessons?”

Ethereum’s strength is its ability to experiment, learn, and evolve. That’s exactly what’s happening here.

For those interested in the technical details, the EIP-8079 discussion is ongoing in the Ethereum Magicians forum, and the prototype implementation is available on GitHub via the Ethrex team.

—Brian O’Sullivan

zk_proof_zoe · March 15, 2026, 9:33am

Brian, this is an excellent technical breakdown. As someone who’s spent the last 4 years optimizing ZK circuits and proving systems, I feel compelled to add some context about why ZK proof research wasn’t “wasted”—even if native rollups become dominant for certain use cases.

ZK Proofs Aren’t Being “Replaced”—They’re Being Right-Sized

The narrative that native rollups make proof systems obsolete misses something fundamental: different applications have different security and efficiency requirements.

Let me explain with some math (I promise to keep it approachable):

Re-Execution Computational Cost:

If an L2 block contains N transactions with average gas cost G
Re-execution on L1 costs approximately N × G gas
For simple transfers (21k gas each), 1000 txs = 21M gas to re-execute
For complex DeFi operations (500k gas each), 1000 txs = 500M gas (!!)

ZK Proof Verification Cost:

zkSNARK verification: ~300k-500k gas regardless of N
Proves correctness of arbitrary computation
Cost is constant whether you’re verifying 100 transactions or 100,000 transactions

The Break-Even Point:
For simple transfers, re-execution wins at small batch sizes. But for complex DeFi operations or large batch sizes, ZK proof verification becomes dramatically more efficient.

Where Native Rollups Make Sense

I actually think native rollups are brilliant for:

Simple payment L2s: Mostly transfers, minimal state transitions
Smaller L2s: Teams without ZK expertise can still build securely
Direct Ethereum compatibility: Inherits state transition function automatically
Development velocity: Simpler infrastructure means faster iteration

Where ZK Proofs Still Win

But ZK proofs remain essential for:

1. Privacy-Preserving Applications

Confidential transactions (native rollups can’t hide transaction data)
ZK-based identity systems
Private DeFi protocols
These applications literally cannot exist without zero-knowledge cryptography

2. Complex DeFi Operations

Multi-step flash loan operations
Cross-chain atomic swaps
Complex liquidation cascades
Re-executing these on L1 would be prohibitively expensive

3. Data Availability Efficiency

ZK proofs enable validiums (off-chain data + on-chain proofs)
Re-execution requires full data availability on L1
For high-throughput applications, this matters

4. Cross-Chain Bridges

Cryptographic proof of state on Chain A can be verified on Chain B
Re-execution doesn’t work across different execution environments
ZK proofs enable secure interoperability

The Investment Built Foundations for Everything

Here’s what the “wasted billions” actually bought us:

Mathematical Foundations:

Understanding of polynomial commitment schemes
Advances in elliptic curve cryptography
Circuit optimization techniques
These apply far beyond blockchain scaling

Production Systems Knowledge:

How to generate proofs efficiently (used to take hours, now takes seconds)
How to verify proofs on-chain gas-efficiently
How to handle edge cases and failure modes
This operational knowledge is invaluable

Proof That ZK-EVMs Are Possible:

5 years ago, “ZK-EVM” was considered theoretically impossible
Today we have multiple production ZK-EVMs (zkSync, Polygon, Scroll, Taiko)
This proves cryptographic verification of arbitrary computation works at scale

Broader Applications:

ZK proofs for machine learning privacy
Confidential credential systems
Post-quantum cryptographic research
Privacy-preserving computation

Native Rollups and ZK Rollups Will Coexist

I expect the L2 landscape to specialize:

Native rollups: General-purpose, developer-friendly, simpler apps
ZK rollups: Privacy-first, complex DeFi, cross-chain infrastructure
Hybrid systems: Some L2s might use ZK proofs for specific operations and re-execution for others

This is healthy diversity, not “one technology killing another.”

We Couldn’t Design Native Rollups Without ZK Research

Here’s the key insight: Understanding what ZK proofs could do—and their limitations—enabled us to design simpler alternatives for use cases that don’t need them.

If we hadn’t explored proof systems deeply, we wouldn’t have known:

Where cryptographic verification is essential (privacy, cross-chain)
Where it’s overkill (simple transfers, small L2s)
How to evaluate security trade-offs (re-execution vs verification)
What complexity is actually necessary

The research wasn’t wasted. It gave us the knowledge to make informed decisions about when to use cryptographic proofs and when simpler approaches suffice.

Final Thought

The question isn’t “did we waste billions on ZK proofs?” but rather “what did we learn, and how do we apply it?”

Native rollups are a testament to the Ethereum community’s ability to:

Invest in deep research
Learn from production experience
Simplify where possible
Maintain pluralistic approaches

That’s not failure—that’s exactly how innovation should work.

For anyone interested in the cryptographic details, I’d recommend reading the EIP-8079 spec alongside the zkEVM documentation. Understanding both approaches gives you a much clearer picture of the trade-offs.

—Zoe

ethereum_emma · March 15, 2026, 9:34am

Okay wow, reading Brian’s breakdown and Zoe’s deep dive on ZK math just made me realize how much I still have to learn. But that’s exactly why I love this community—I can ask “dumb” questions and get thoughtful answers instead of gatekeeping.

So let me ask what might be an obvious question to the experts here, but genuinely confuses me:

If Native Rollups Are Simpler, Why Didn’t We Start There?

Like, if re-execution is just “run the L2 transactions on L1 to verify them,” why did we spend years building ZK circuits and fraud proof games first? Was there a technical limitation that prevented native rollups from being built in 2020?

Or is this one of those things where you have to try the complicated approach first to realize the simple one would work?

The Developer Experience Question

From a pure “I just want to ship products” perspective, here’s what matters to me:

Optimistic rollups (what I’m using now):

Ethereum-compatible, my Solidity contracts “just work”
Established tooling (Hardhat, Foundry, ethers.js all work fine)
7-day withdrawals frustrate users constantly
Bridge security scares me (we’ve seen so many hacks)

ZK rollups (what I’ve tried to build on):

Fast finality, no withdrawal delays
Mathematically secure (apparently?)
Circuit constraints are confusing (some opcodes don’t work?)
Debugging proof generation failures feels like black magic
Our small team doesn’t have a cryptographer

Native rollups (if they work):

Ethereum compatibility (inherits L1 state transition function)
Simple infrastructure (no ZK circuits to learn)
Potentially faster finality than optimistic?
What’s the gas cost at scale? (This is what worries me)

My Real Concern: Is This Actually Better for Small Teams?

Brian mentioned native rollups could be good for “smaller teams without ZK expertise.” That’s us! We’re a 5-person team building a DeFi protocol. We don’t have:

A dedicated cryptographer
Months to learn ZK circuit optimization
Budget to hire StarkWare consultants

If native rollups let us:

Build on Ethereum-compatible infrastructure
Get L1 security without cryptographic complexity
Ship faster without fraud proof delays

…then honestly, I don’t care if ZK proofs are “more elegant” or “mathematically optimal.” I care about building products users actually love.

But Zoe’s Point About Gas Costs Worries Me

Zoe mentioned re-executing 1000 complex DeFi transactions could cost 500M gas. That seems… bad? For context:

Ethereum L1 block gas limit: ~30M gas
If re-execution needs 500M gas, that’s like 17 L1 blocks??
How does that even work? Do native rollups batch less aggressively?

Our protocol does multi-step flash loan operations (borrow → swap → arbitrage → repay). These are like 500k gas each on L1. If a native rollup has to re-execute 1000 of these… that’s 500M gas like Zoe said.

Genuine question for the experts: At what point does re-execution become impractical? Is there a “max complexity” for native rollup transactions?

What I Honestly Want

As someone who just wants to ship products and help users access DeFi:

Simple developer experience: I can write Solidity and test with Hardhat. Don’t make me learn circuit constraints.
Fast finality: Users shouldn’t wait 7 days to withdraw their funds. That’s unacceptable UX.
Security I can understand: I trust Ethereum L1. If a rollup inherits that security, I can explain it to users.
Affordable at scale: If gas costs explode with complex transactions, that defeats the purpose of L2 scaling.

If native rollups deliver on 1-3 but fail on 4, we’re back to square one. If they deliver on all four… I genuinely don’t care about the “wasted” ZK investment. I care about building.

Admitting My Limitations

I’m not smart enough to evaluate the cryptographic trade-offs. I don’t understand polynomial commitment schemes (sorry Zoe). I can barely follow the EIP-8079 spec.

But I do understand:

Gas costs
Developer experience
User experience
Product-market fit

If native rollups make L2 development more accessible to teams like mine, and the gas costs actually work at scale, that’s huge for ecosystem growth.

If they don’t… then I guess I need to either:

Learn ZK circuits (ugh)
Stick with optimistic rollups (and frustrated users)
Wait for someone smarter to solve this

What am I missing here? Are native rollups actually the “simple path” or am I oversimplifying?

—Emma

P.S. Still naming my houseplants after programming languages. Just got a new succulent named “Solidity”

layer2_lisa · March 15, 2026, 9:35am

Emma, your question “why didn’t we start there?” is actually brilliant and gets at something fundamental about how we build technology.

Why We Didn’t Start With Native Rollups

Short answer: We literally couldn’t have.

Longer answer: Native rollups depend on infrastructure and understanding that only exists because we built proof-based rollups first. Let me break down the dependencies:

1. We Needed to Prove L2s Could Work At All

In 2017-2019, the concept of “rollups” was still theoretical:

Plasma was the dominant scaling approach (turned out data availability killed it)
We didn’t know if bundling transactions off-chain and posting state roots would work
We needed proof-of-concept systems to validate the model

Optimistic rollups (Arbitrum, Optimism) proved the concept: yes, you CAN batch transactions off-chain, yes users WILL trust it, yes it DOES scale Ethereum.

2. We Needed the LEVM (L2 Execution Virtual Machine)

EIP-8079’s EXECUTE precompile depends on having a way to re-execute L2 state transitions on L1. That execution engine (LEVM) didn’t exist until recently. Building it required:

Understanding L2 state transition requirements
Optimizing for gas efficiency
Handling edge cases discovered through production L2 operation

We learned those requirements by operating Arbitrum, Optimism, zkSync in production for years.

3. We Needed to Understand What “Security” Actually Means for L2s

The fraud proof systems and ZK proof systems taught us:

What trust assumptions are acceptable
Where cryptographic verification is necessary vs overkill
How to handle L1/L2 communication edge cases
What failure modes exist (exit games, data withholding, sequencer liveness)

You can’t design a simpler system until you deeply understand the complex one.

4. We Needed Ethereum Itself to Evolve

Native rollups require:

EIP-4844 (blob transactions for cheaper data availability) - shipped March 2024
Improved L1 execution efficiency
Precompile infrastructure for re-execution
Ethereum’s merge to PoS (better finality guarantees)

None of that existed in 2020. The foundation for native rollups was built piece by piece.

This Is Actually How Innovation Works

Think about other technology evolution:

HTTP/3 (QUIC):

HTTP/1.1 (1997): Taught us web performance bottlenecks
HTTP/2 (2015): Solved multiplexing, introduced complexity
HTTP/3 (2020): Simplified by moving to UDP

Could we have skipped to HTTP/3? No—we needed to understand the problems first.

Ethereum Consensus:

Proof of Work (2015): Proved blockchain consensus works
Casper research (2017-2020): Explored PoS designs
The Merge (2022): Applied lessons to ship PoS

JavaScript Modules:

CommonJS (2009): Node.js modules, synchronous
AMD/RequireJS (2010s): Async modules, complex
ES6 Modules (2015+): Native browser support, simpler

Every “simpler” solution required building the complex one first to understand what simplicity should look like.

To Emma’s Gas Cost Question

You asked about the 500M gas problem. Great question. Here’s the nuance:

Native rollups won’t re-execute everything immediately.

The design likely involves:

Optimistic posting (like current optimistic rollups)
Re-execution happens only when challenged or for final settlement
Batching strategies to amortize re-execution costs
Potentially limiting transaction complexity per batch

So your 500k gas flash loan operations might:

Execute on L2 (cheap, fast)
Post state root to L1 (data availability)
Only re-execute if someone challenges the state transition
Or re-execute in batches during settlement windows

This is similar to optimistic rollups, but instead of generating a fraud proof when challenged, L1 just re-runs the transactions.

The key difference:

Optimistic rollups: “Prove this state transition is WRONG” (fraud proof)
Native rollups: “Let me check by running it myself” (re-execution)

Both have the 7-day-ish settlement window. But native rollups skip the fraud proof circuit complexity.

What This Means for Small Teams (Like Yours)

Emma, for your 5-person DeFi team, native rollups could be a game-changer:

What you get:

Full Ethereum compatibility (no circuit constraints)
Simpler infrastructure (no ZK expertise needed)
L1 security inheritance (users trust Ethereum, not your team’s cryptography)
Potentially faster development iteration

What you trade:

Settlement finality is still ~7 days (like optimistic rollups)
Gas costs for complex operations need careful batching
Early-stage tech (production readiness unknown)

My honest take for you:
If you’re building today, stick with Optimism or Arbitrum. They’re battle-tested, have established ecosystems, and your Hardhat setup already works.

Watch native rollups closely. If they reach production by 2027 with proven gas efficiency, consider migrating. But don’t bet your product on prototype infrastructure.

The “Wasted Investment” Question

Brian and Zoe already covered this well, but let me add a product perspective:

What the billions bought:

$186B+ in TVL flowing through optimistic rollups (real value, real users)
Production ZK-EVMs that proved “impossible” things possible
Thousands of developers trained in L2 development
Battle-tested infrastructure (Arbitrum, Optimism, zkSync)
Lessons learned that enabled native rollups

Was any of that “wasted”? Absolutely not. Optimism’s $12B TVL and zkSync’s production ZK-EVM are delivering value to users right now.

Native rollups are a refinement, not a replacement. They’ll coexist with proof-based systems, each serving different use cases.

Final Thought

Emma, you asked “are native rollups actually the simple path or am I oversimplifying?”

Answer: They’re simpler than ZK circuits, but not simpler than using existing L2s.

For your team:

Simplest path today: Deploy on Arbitrum/Optimism (works now)
Medium complexity: Deploy on zkSync (if you need fast finality)
Experimental: Wait for native rollups (2027+, unproven at scale)

Don’t let perfect be the enemy of good. Ship on what works today, iterate based on user feedback, and migrate when better infrastructure proves itself.

And name your next houseplant “Arbitrum”

—Lisa

security_sophia · March 15, 2026, 9:36am

As someone who spends most of my time finding vulnerabilities in smart contracts and L2 infrastructure, I need to inject some caution into this discussion. Everyone’s optimistic about native rollups (pun intended), but we should rigorously examine the security assumptions before celebrating.

Re-Execution Introduces a Different Security Model

Let me be precise about what’s changing:

ZK Proofs:

Security guarantee: Mathematical proof of correct state transition
Trust assumption: Cryptographic soundness (e.g., SNARK setup, elliptic curve hardness)
Verification: Constant-time, deterministic, trustless
Failure mode: Cryptographic breakthrough (theoretical, no known attacks on production systems)

Fraud Proofs (Optimistic):

Security guarantee: Economic security via fraud proof challenges
Trust assumption: At least one honest verifier + 7-day challenge window
Verification: On-demand when challenged
Failure mode: Collusion, griefing, censorship of challenges

Re-Execution (Native Rollups):

Security guarantee: Computational trust—L1 validators re-run the transactions
Trust assumption: L1 execution correctness + data availability
Verification: Direct re-computation on L1
Failure mode: ???

That last one is what concerns me. We don’t have battle-tested answers yet.

Critical Security Questions Needing Formal Analysis

1. Gas Limit Griefing Attacks

What happens if an adversarial L2 sequencer submits a batch designed to hit L1 gas limits during re-execution?

Scenario:

Malicious sequencer crafts L2 block with intentionally expensive operations
L1 attempts re-execution via EXECUTE precompile
Re-execution hits L1 block gas limit (30M gas)
Verification fails—but is it because the state transition was invalid or because gas ran out?

Attack vector: Griefing by forcing L1 to waste gas on failed re-executions.

Mitigation needed: Gas metering during re-execution, possibly splitting batches. But this adds complexity.

2. Determinism and State Access Patterns

Re-execution must be perfectly deterministic for security:

L2 execution: Reads storage slot A, writes slot B
L1 re-execution: Must read same slot A (which might have changed), write same slot B

Problem: If L1 state has changed between L2 execution and L1 re-execution, how do we ensure determinism?

Possible solutions:

Freeze L1 state during re-execution (expensive)
Use execution witness with historical state (complex)
Restrict L2 transactions from accessing L1 state (limiting)

Each has security and complexity implications.

3. MEV and Re-Execution Ordering

When L1 re-executes L2 transactions:

Can L1 validators reorder transactions during re-execution?
Can they front-run based on knowing L2 execution results?
Does this create new MEV attack vectors?

Example attack:

L2 sequencer posts batch with high-value arbitrage
L1 validator sees this during re-execution
L1 validator front-runs on L1 before finalizing L2 batch
Arbitrage opportunity extracted

Mitigation needed: Possibly encrypted transaction batches, but that breaks re-execution’s transparency.

4. Upgrade Coordination and State Transition Bugs

Native rollups “inherit” Ethereum’s state transition function. But:

What if Ethereum has a consensus bug? (It’s happened before: Shanghai DoS, etc.)
L2 inherits the bug automatically
Rollback on L1 affects all native rollups
Cascading failure across entire L2 ecosystem

Risk: Reduced independence. If L1 fails, all native rollups fail simultaneously.

ZK rollups and optimistic rollups have independent verification logic—they can survive L1 bugs (to some extent).

The “Simpler” Narrative Might Be Dangerous

Lisa and Emma both highlighted that native rollups are “simpler” for developers. But security-wise, simpler doesn’t always mean safer.

Historical examples:

1. REE (Re-Entrancy):

Simplest code pattern: external call then state update
Most developers used it
The DAO hack (2016): $60M stolen
“Simple” code had subtle vulnerability

2. Access Control:

Simplest pattern: No access control checks
Developers skip complexity
Result: Parity multisig hack, Compound bug, etc.

3. Flash Loans:

“Simple” DeFi primitive
Enabled $2.71B in exploits (2025 alone, per Web3 security reports)

Point: “Simpler for developers” can mean “easier to make security mistakes.”

What We Need Before Production

Before I’d trust native rollups with significant TVL:

1. Formal Security Analysis

Academic papers analyzing security model
Formal verification of EXECUTE precompile implementation
Game-theoretic analysis of griefing incentives

2. Bug Bounty Programs

Significant rewards for finding vulnerabilities
Multiple independent security audits
Red team exercises simulating attacks

3. Testnet Battle-Testing

At least 12 months on testnet with real economic incentives
Deliberate attempts to break it
Post-mortem analysis of any failures

4. Economic Security Modeling

What’s the cost of attacking a native rollup?
What’s the profit potential?
Does the security model hold at scale ($10B+ TVL)?

5. Failure Mode Documentation

What happens when re-execution fails?
How do users recover funds?
What’s the worst-case scenario?

My Honest Assessment

Optimistic rollups: Battle-tested, $186B+ TVL, known vulnerabilities (7-day delay, bridge risks) but proven secure in production.

ZK rollups: Mathematically elegant, constant-time verification, but circuit complexity creates attack surface. Production-ready in 2026.

Native rollups: Theoretically simpler, but unproven security assumptions. Early prototype phase. Needs formal analysis and real-world testing before handling significant value.

For Emma and Small Dev Teams

Emma, you asked about practical advice. From a security perspective:

If your protocol handles <$10M TVL:

Optimism/Arbitrum are safe choices
Risk is tolerable, ecosystems are mature
Ship fast, iterate based on user feedback

If your protocol handles $10M-$100M TVL:

Stick with battle-tested infrastructure
Security audits are mandatory
Don’t experiment with unproven tech

If your protocol handles >$100M TVL:

Do NOT use prototype native rollups
Multiple audits, formal verification, bug bounties
Wait for native rollups to prove themselves on smaller protocols first

Investment Wasn’t “Wasted”—It Built Our Understanding

Brian, Zoe, and Lisa covered this well. I’ll add the security angle:

What billions in proof systems research bought us:

Deep understanding of L2 security models
Battle-tested fraud proof implementations
Production ZK systems (proving it’s possible)
Thousands of audits teaching us what breaks
Security frameworks we now use to evaluate native rollups

Without that investment, we wouldn’t know:

What security guarantees we actually need
Where complexity is necessary vs overkill
How to audit new L2 designs
What questions to ask (like the ones I’m raising above)

Final Thought

I’m excited about native rollups. The concept is elegant. But excitement must not override caution.

History of crypto: Overhyped tech launches too early → massive hacks → ecosystem damage → legitimate users suffer.

Let’s learn from:

The DAO (overhyped smart contracts)
Mt. Gox (overhyped exchanges)
Terra/LUNA (overhyped algorithmic stablecoins)
Bridge hacks (overhyped cross-chain tech)

My recommendation:

Researchers: Formal security analysis, now
Developers: Deploy on testnets, break things, learn
Users: Wait for 12+ months of battle-testing before bridging significant funds
Auditors: Develop native rollup security checklists

Trust but verify. Then verify again.

And if you’re deploying production contracts on native rollups before formal security analysis… please don’t.

—Sophia