We Shipped a Production L2 Rollup in 11 Weeks. Here’s the Week-by-Week Build Log

What “turnkey” actually meant

Before you read the timeline: when a rollup-as-a-service vendor tells you 4 to 6 weeks to mainnet, what they mean is 4 to 6 weeks to a working sequencer with default configs and a bridge contract. That is not a production L2. A production L2 is a sequencer that doesn’t fall over when L1 gas spikes, a prover that meets your finality SLA on real load, a bridge that can survive a regulator question, and monitoring that pages a human only when something is actually wrong.

The gap between those two definitions is roughly seven weeks of work. Here’s what those weeks actually contained.

Headcount: 1 protocol lead, 2 infra engineers, 1 smart contract engineer, 1 SRE, 1 product/PM (half-time). External auditor for weeks 8 to 10.

Week 1. Use case and stack selection

The first decision was the most consequential. Optimistic stack (OP Stack, Arbitrum Orbit) versus ZK stack (Polygon CDK, ZK Stack). The team mapped throughput targets, withdrawal-time tolerance, and proving cost against a five-year operational budget. ZK looked attractive on paper for the seven-day withdrawal elimination. The numbers said optimistic: lower infra cost, smaller team to operate, mature tooling.

Decision: OP Stack. Settlement on Ethereum. Celestia for data availability. Default sequencer to start, with a documented decentralization path. No code yet.

Week 2. Infrastructure scaffolding

Cloud accounts, IaC modules, secret management, and the wallet generation script for the four privileged roles every OP Stack rollup requires: admin, batcher, proposer, sequencer.

Mistake we caught early: the wallets were generated on a laptop and stored in a 1Password vault. The protocol lead pushed back. By Friday they were rotated, regenerated inside an HSM workflow, and the laptop ones were burned. Nobody talks about this until they’re explaining to investors why $40M of treasury keys lived in a password manager.

Week 3. L1 contracts deployed to Sepolia testnet

L1StandardBridge, SystemConfig, OutputOracle, OptimismPortal. The op-deployer tool handled most of it. What it didn't handle: the upgrade authority on the proxy admin, set to a single-signer EOA by default. The team replaced it with a 4-of-7 multisig with a 48-hour timelock before any contract was funded. Two extra days. Skip this and you ship a rollup where one compromised key drains the bridge.

Week 4. Sequencer and node services up

op-geth, op-node, op-batcher, op-proposer deployed across three regions with automated failover. First L1 to L2 deposits worked. First L2 transactions flowed through. The team celebrated.

Then the SRE asked: what happens when the batcher’s L1 wallet runs out of ETH on a Sunday? Nobody had an answer. Monitoring alert added. Refill runbook written. Rollups die in production for boring reasons like this, and the team filed three more “boring failure” runbooks before the week ended.

Week 5. The week that almost killed the launch (1 of 3): data availability

The team had committed to Celestia for DA in week 1. Week 5 was when reality arrived. Celestia integration on OP Stack required a custom plasma DA wrapper, the namespace allocation took longer than expected, and the DA-fail-safe path needed an explicit fallback to L1 calldata. The plasma wrapper was beta software at the time and broke twice in three days under realistic batch sizes.

The fix took five days and a hard conversation with the founders about whether to swap DA layers. The team kept Celestia, added an automated “fall back to blob calldata if DA confirmation lags by more than 90 seconds” path, and shipped extensive monitoring around it.

Week 6. Bridge hardening and economic configuration

The default L1StandardBridge code is reviewed and audited. The defaults are not. The team spent the week setting and documenting:

• Withdrawal rate limits per asset and per user
• Pause authority scoped to a 2-of-3 emergency multisig
• Forced inclusion windows for censorship resistance
• Gas limit caps on L1 to L2 messages to prevent griefing
• Allowlist for the initial set of bridgeable ERC-20s

Unglamorous work. Also the work that determines whether your rollup survives its first hostile actor.

Week 7. The week that almost killed the launch (2 of 3): fault proofs and the dispute game

OP Stack rollups need fault-proof infrastructure to be more than a glorified sidechain. The op-challenger service watches for invalid output proposals and disputes them. Configuring it correctly means understanding the dispute game contract, the bond economics, and the scenarios under which the challenger needs to act within minutes versus hours.

The team underestimated this by an entire week. The challenger was running but not actually validating against an independent execution client, which means it would have approved any output the proposer published. Fixing this required spinning up a second op-geth instance running in trusted mode, wiring it into the challenger’s verification path, and writing tests that simulated a malicious proposer.

If this had been missed and the rollup had launched, the security model would have been theatrical. The bridge would have been one bad output proposal away from drained.

Week 8. Audit kickoff and frontend integration

External audit started. Four engineers stayed on infra hardening while the smart contract engineer worked full-time with the auditors. In parallel, the rollup was integrated into the existing frontend, RPC providers were contracted, and the block explorer was deployed.

The auditors found eleven issues in the first pass. Three were severity-high. None were in the code the team wrote; all were in configuration choices. Configurations are code in production rollups. This is the lesson nobody internalizes until they’re 8 weeks in.

Week 9. The week that almost killed the launch (3 of 3): load testing reality

The first realistic load test. 2,500 transactions per second sustained over an hour. The sequencer held. The prover lagged 18 minutes behind by the end. Bridge withdrawals queued. Monitoring fired 47 alerts in 60 minutes, most of them false positives, which meant the real signals were buried.

Three problems revealed at once:

1. Prover throughput was not what the spec sheet claimed under realistic mempool variance.
2. Alert thresholds had been set for testnet load, not mainnet.
3. The withdrawal queue had no rate-limiting circuit, just a hard cap that returned an unhelpful revert.

The team rewrote alerting from scratch over two days, added a graceful withdrawal queue with backpressure, and provisioned 60% more prover capacity than the original budget. This was the only week where someone seriously asked whether to delay launch by a month. The decision to push through was made because the issues were known, contained, and monitored, not because they were resolved.

Week 10. Audit remediation and final hardening

All audit findings closed. Re-audit confirmed no regressions. A 12-hour soak test and a chaos test that killed the sequencer mid-batch. Recovery was clean. Runbooks held.

Week 11. Mainnet launch

Genesis block produced. Bridge live. First mainnet transaction at 14:32 UTC on a Tuesday. No one tweeted. The team watched dashboards for 72 hours straight.

That’s the week the rollup actually launched. Not week 6 when it first worked.

What “turnkey” actually costs

The 11 weeks above describe the minimum viable path to a production L2 with a small senior team that already knew the terrain. The “4 to 6 week turnkey” pitch is real, but it lands you at week 4 of this timeline, with weeks 5 through 11 still ahead and disguised as launch. Founders who don’t account for that gap discover it during their first hostile event.

Turnkey covers the parts that are well-understood and templatized. It does not cover the parts that determine whether your chain survives a real adversary, a real audit, or a real load spike. Those parts cost weeks 5, 7, and 9.

How Ancilar fits in

We work with teams launching their own L2 in two ways. The first is full-stack: architecture review, infrastructure build, contract hardening, audit coordination, and the unglamorous configuration work that decides survivability. The second is targeted: we drop into week 5, 7, or 9 of someone else’s timeline when something has gone wrong and they need engineering bandwidth that already knows the OP Stack, ZK Stack, or Orbit terrain.

Either way, the deliverable is a rollup that survives what comes after launch, not just the launch.

If you’re scoping a chain right now, or you’ve shipped to testnet and the timeline is starting to feel optimistic, that’s the conversation we’re set up to have.

Schedule an L2 architecture review with Ancilar: www.ancilar.com/services