DEV Community: Satori Geeks

Lean context architecture for multi-agent pipelines

Satori Geeks — Thu, 16 Apr 2026 19:01:25 +0000

In a second week of my project I noticed my agents were getting slower and dumber. When I checked the logs, I realized why: every single agent was loading the entire project history just to write one line of copy.

That file was 254 lines, around 3,400 tokens. Then there was a separate AGENTS.md — 267 lines, about 3,050 tokens. Two more root files added another 2,200. Every agent loaded all four. Roughly 8,700 tokens just to orient, most of it irrelevant to whatever that agent actually needed to do.

This is the refactor that fixed it.

255 lines and everyone reads everything

Token waste adds up (8,700 per invocation, across 8 agents, across multiple sessions), but that's not the real problem. The real problem is noise diluting signal. An agent working from clean, relevant context does better work than one working from an everything-file where most of what it reads doesn't apply to its job.

I should have seen it earlier. I didn't.

The load-only-if-needed pattern

The fix was just a tedious afternoon of moving files around. Four root files collapsed into one: CLAUDE.md, now at ~1,070 tokens. Pipeline overview, agent roster, done criteria, chain lineup, dev commands — the minimum every agent needs to orient.

Then each agent gets its own spec: agents/[role]/AGENT.md. Small files on purpose. The Copywriter's runs ~420 tokens. QA is ~235. Each covers only what that role needs — inputs, outputs, what it doesn't do, and references to load only when relevant.

Every one of them ends the same way: Await your brief. It will contain all week-specific state. Agents spawn stateless. Stable context (who they are, what they do) lives in the AGENT.md. Week-specific facts arrive in the brief for that session. The separation sounds obvious in retrospect. It wasn't obvious when everything was baked into one file.

Per-agent context load: ~8,700 tokens → ~1,385. Agent output got more focused. Fewer irrelevant references, fewer moments where the wrong agent wandered into territory that wasn't its job. This is also a Claude Code pipeline, and the refactor improved what the agents actually produced — less noise in means less noise out.

Cleaning up the broken links

Every structural rename silently breaks briefs that reference the old path. You move a file, run the pipeline a week later, something fails in a confusing way, you trace it back to a path nobody updated.

The fix is one habit:

grep -r "old-filename" .

After collapsing the four root files, I ran it and found 18 files still pointing to deleted names. 11 active files got updated. 7 were historical records — intentionally left, because those paths were accurate when those files were written. That's not sloppiness. It's a triage decision, and it's worth making deliberately rather than stumbling into it.

The checksum refactor workflow

The grep habit catches stale references. The checksum workflow is what makes large-scale moves tractable in the first place.

Before touching anything structural, snapshot checksums of every file:

find . -type f -not -path '*/.*' | sort | xargs md5sum > checksums_before.txt

Do the moves. Then run it again:

find . -type f -not -path '*/.*' | sort | xargs md5sum > checksums_after.txt

Same hash, different path means the same file moved. Diff the two outputs and you have a rename map automatically — no manual tracking of what went where. Then feed each old path into grep.

This project moved 76 files in one session using this approach. Without the checksum diff, correlating old references to new paths across multiple terminal sessions would have been a manual tracking problem. With it, the rename map came out of a script. The combination is: checksum diff builds the map, grep burns through the tree, triage decides what to update and what to leave as historical record.

YAML vs Markdown — when each wins

One design rule that came out of this: YAML for status documents, Markdown for instruction documents.

State passed between pipeline stages — session status, open items, key facts — is short, structured, needs to be machine-readable. YAML fits. Agent briefs with code blocks, nested tables, and ordered research questions need Markdown. Forcing those into YAML adds syntax noise and makes them harder to parse.

The rule: if an agent reads it to understand what to do, use Markdown. If a pipeline stage produces it for the next stage to consume, use YAML. That distinction maps to a lot of systems beyond this one.

The honest tradeoff

This architecture has overhead. For a solo one-week project, one context file is fine. You don't need any of this.

The argument is only load-bearing when agents specialise and when the pipeline runs across multiple sessions — which is exactly this project's structure. If you're wiring up a couple of agents that each run once, skip it.

It's better now, but I'm still keeping an eye on that 1,000-token root file. It’s already starting to grow again.

The most exotic consensus in the series. The most vanilla build.

Satori Geeks — Wed, 15 Apr 2026 19:14:17 +0000

Week 3 of Proof of Support is live on Core DAO. Chain selection has its own article — I covered why Core won the shortlist here. Short version: Satoshi Plus consensus, Bitcoin miners voting with hashrate, BTC holders timelocking on L1 with OP_CLTV. Three parties, one validator election, EVM on top.

Here's what actually happened.

The thing that was supposed to bite didn't

Research flagged one config change going in: evm_version = "shanghai" in foundry.toml. Core DAO's docs require the Shanghai pin — Cancun opcode support isn't confirmed even after the Hermes fork. Two weeks on Base and Scroll had me defaulting to "cancun", and silently wrong bytecode is exactly the kind of wrong that wastes a morning.

forge build compiled clean on the first run. OZ Ownable and ReentrancyGuard are fine against the Shanghai target. 14 tests. No issues.

So. That wasn't the problem.

The first L1 in the series — and the CORE token problem

Base is an OP Stack rollup. Scroll is a ZK rollup. Core DAO is just an L1. No sequencer, no proving layer, no 7-day withdrawal window. After two weeks of rollup mechanics, the mental model simplification is real — "confirmed" means confirmed, full stop.

The catch is the gas token. CORE, not ETH. For a developer it's trivial — you need CORE in the deployer wallet, you get it, you move on. For a casual supporter landing on the app, it's a different story.

Getting CORE isn't smooth. There's one official bridge at bridge.coredao.org (uses LayerZero for its bridging tech!) that works. Symbiosis also lists a Core DAO bridge — I checked, it was dry, at least for certain pairs. In the end I swapped on a CEX from my Base wallet and sent CORE directly to the deployer. That's not a bad path if you know your way around exchanges, but it's not something a casual user clicks through in thirty seconds. It's probably the biggest real-world friction point for adoption this week.

Hermes finality is noticeable

One quick line on this: post-Hermes (November 2025), Core DAO has 2-block finality — about 6 seconds. Compared to Scroll's ZK proving latency, where confirmation means "in the sequencer, not yet on L1," the Core DAO frontend felt fast. Transactions landed visibly. No sitting and wondering.

Vibe Check

(Full methodology: how I'm scoring the chains)

Dimension	Weight	Est	Actual	Delta
D1 Getting Started	×1.0	4	4	0
D2 Developer Tooling	×2.0	4	4	0
D3 Contract Authoring	×2.0	4	4	0
D4 Documentation Quality	×1.5	4	3	−1
D5 Frontend / Wallet	×2.0	4	4	0
D6 Deployment Experience	×1.5	4	3	−1
D7 Transaction Cost	×1.0	5	5	0
D8 Community & Ecosystem	×1.0	4	4	0

Actual: 46/60. Estimated: 49/60. Delta: −3 weighted points (D4 and D6 each drop one raw point at ×1.5 weight: −1.5 each)

D4 and D6 are both down one — the verification docs had the wrong flags, and the testnet/mainnet API key split wasn't documented anywhere. Everything else landed where research said it would.

D5 is the strong spot: coreDao is built into viem, MetaMask connected immediately, zero custom chain config for mainnet. D7 stays a 5 — the deploy cost 0.083 CORE, roughly $0.002 at ~$0.027/CORE. A sendSupport() call is a fraction of that. Effectively free for supporters.

The consensus paradox

Satoshi Plus is the most interesting security mechanism I've touched in this series. Bitcoin miners include metadata in coinbase transactions to vote for Core validators. BTC holders timelock coins on Bitcoin mainnet using OP_CLTV — the coins don't move, they just declare a preference. Three independent parties produce a hybrid score that elects 31 validators for the day.

From inside the house — the Solidity contract, the viem adapter, the MetaMask prompt — I felt none of it. Same EVM. Same Foundry flags. Same gas estimates I'd have on any other EVM L1. The foundations are Bitcoin-native. The walls look identical.

I'm genuinely uncertain whether that's a feature or a missed opportunity. You want the security model to be invisible to the developer — that's what "it just works" means. But there's something odd about spending a week on the most exotic consensus design in the series and coming away with a build log that reads the same as the previous two weeks.

The app is live: https://proof-of-support.pages.dev

Week 4 picks up the non-EVM category. The build log will look different.

Finding life in the experimental EVM shortlist

Satori Geeks — Mon, 13 Apr 2026 20:40:06 +0000

"Experimental" EVM. That was the brief for Week 3. For this series, it means finding a chain where the Solidity code stays the same but the neighborhood is completely foreign. No L2s, no rollups, no "rebranded" OP Stack chains. I wanted my code secured by something that isn't an Ethereum validator.

I expected a playground. I found a graveyard.

The ghosts and the marketing plays

Step outside the Ethereum L2 bubble and the landscape changes fast. Most of the names I remembered from previous cycles are either in maintenance mode or actively winding down.

Evmos, once the poster child for EVM on Cosmos, effectively finished in 2025. Milkomeda—the bridge to Cardano and Algorand—is archived and frozen. Vaulta (the artist formerly known as EOS EVM) is being deprecated in favor of yet another project. (I’ve lost track of how many times EOS has rebranded at this point).

Then there’s the "Bitcoin EVM" wave. BOB (Build on Bitcoin) sounds perfect, until you realize it’s just another OP Stack rollup on Ethereum where you pay gas in ETH. It’s a marketing play in a trench coat. I’m looking for a new security model, not a new way to pay fees to Ethereum L1.

Hedera was another candidate, but the "EVM compatibility" has too many asterisks. You have to "activate" new MetaMask addresses manually. The contract size limit is enforced through a non-EVM file service that breaks standard Foundry deploys. It’s a neighborhood with a very restrictive HOA—technically live, but a nightmare to move into. I'm here to write code, not read a 40-page manual on how to use a wallet.

The scored finalists

I ran the remaining candidates through the rubric. I wasn't just looking for a chain that worked; I wanted one that was actually alive.

Chain	Platform	Score	One-line verdict
Core DAO	Bitcoin (Satoshi Plus)	49/60	Cleanest DX, stable ecosystem, Bitcoin consensus is the real story
Moonbeam	Polkadot parachain	48/60	Solid tooling, sharp ecosystem decline
Flare Network	Data-centric L1	48/60	FTSOv2 oracles are interesting; niche audience
Berachain	Cosmos SDK	45/60	TVL collapsed from $3.2B to $74M since launch
Kava	Cosmos SDK EVM	41/60	Maintenance mode, verification friction
Rootstock / RSK	Bitcoin (merge-mined)	41/60	Oldest Bitcoin EVM, Foundry bug, HTTP-only RPC
Astar Network	Polkadot parachain	41/60	Team pivoted to Soneium; parachain in caretaker mode
Neon EVM	Solana SVM	36/60	Exotic, but lacks Ethereum's `transfer()` gas stipend / reentrancy protection
Canto	Cosmos SDK EVM	36/60	No GitHub commits since Sep 2024; team status unknown

Why Core DAO

Core DAO won because it offered the cleanest path to the most interesting narrative. While other survivors are in maintenance mode (Moonbeam, Kava, Astar) or dealing with massive TVL drawdowns (Berachain), Core DAO feels stable enough to actually build on. I checked the explorer—the blocks are ticking over, the documentation is current, and the "neighborhood" doesn't feel like it’s being packed into boxes.

The hook is "Satoshi Plus" consensus. It’s a three-party model: Bitcoin miners delegate their hash power, BTC holders stake natively (via OP_CLTV time-locks, no custodians involved), and CORE stakers handle the validation. It’s an EVM chain physically integrated into the Bitcoin mining economy.

Coming from Week 1 (Base, an optimistic rollup) and Week 2 (Scroll, a ZK rollup), Core DAO is the third major answer to the "what secures my code?" question. This time, the answer is Bitcoin miners.

The ones that got away

Flare Network and Rootstock are still on my list. Flare's "enshrined oracles"—where data feeds are part of the L1 protocol itself—is a compelling piece of infrastructure. Rootstock remains the OG Bitcoin EVM, and despite some Foundry-related address bugs, it's still the purist's choice for merge-mining.

But for Week 3, we're heading to Core. The code is the same, but the security model is a completely different animal.

→ The live app is at https://proof-of-support.pages.dev

→ Scoring methodology for the series: How I'm Scoring the Chains

What "Stage 1 ZK Rollup" actually means for your deployed contract

Satori Geeks — Sun, 12 Apr 2026 09:08:28 +0000

You'll see "Stage 1" on L2Beat and most developers treat it as a good sign — higher is better, move on. But it's a specific security model with specific requirements. Scroll crossed into it with the Euclid upgrade in April 2025.

The three stages

L2Beat defines rollup maturity in three stages. The progression isn't about performance — it's about who can stop you from getting your money out.

Stage 0 is where most rollups start. The validity proof system may be live, but user protections are thin: the operator can censor transactions, the team controls upgrade keys unilaterally, and there's no guaranteed exit path that doesn't depend on the team cooperating. You're trusting that the people running it won't act against you.

Stage 1 adds three things:

Forced transaction inclusion. If the sequencer ignores your transaction, you can submit it directly to the L1 inbox contract. The sequencer can't censor you indefinitely.
Permissionless batch submission. If the sequencer fails to post a batch within a defined window — the Liveness Gap — any user can submit a batch and a validity proof directly to the L1 contract to move state forward. The chain doesn't die with its operator.
Security Council with independent majority. Upgrade keys move from team-controlled multisig to a council where independent members hold the majority. For Scroll, that's a 9-of-12 multisig — 7 of the 9 required signers are not Scroll employees. The team cannot push a protocol upgrade unilaterally.

Stage 2 removes trust in the Security Council as well. Exit is fully guaranteed by code, not governance. No rollup has reached Stage 2 yet — Arbitrum has removed the whitelist for fraud proofs, but retains a Security Council emergency override for bug fixes, most researchers still call it Stage 1.

What Euclid actually changed

Before Euclid, Scroll's prover used custom halo2 arithmetic circuits — one circuit gadget per EVM opcode, hard capacity ceiling per batch. Valid state transitions required the proof system, but forced inclusion and permissionless batch submission weren't live.

Euclid shipped in two phases: Phase 1 on April 16, 2025, Phase 2 on April 22. Forced inclusion went live — users can now submit directly to the L1 inbox contract if censored — and the Security Council replaced team-controlled upgrade keys. Scroll also replaced the prover stack with OpenVM (a RISC-V zkVM built with Axiom and the Ethereum Foundation's PSE team), which delivered the 5× throughput and ~50% fee reduction, and migrated the state commitment from Scroll's custom zktrie to Ethereum's standard Merkle-Patricia Trie.

The ZK validity proofs were already live before Euclid. What Euclid added was the exit guarantees and independent upgrade control.

What this means for a contract you deploy today

For a simple storage contract: every state transition is cryptographically verified, so an adversarial sequencer can't produce an invalid state root without generating an invalid proof. If the sequencer goes rogue, your funds aren't trapped — unlike an Optimistic rollup where exit requires a 7-day fraud proof window, the validity proof proves your exit is valid immediately once the batch is finalized on L1. A protocol upgrade still requires sign-off from independent members who can block it.

None of this is full decentralization. A single sequencer still handles transaction ordering, and Stage 2 is the actual end state — nobody's there yet. But the trust assumptions are different from a Stage 0 chain where "we're a reputable team" is the primary protection.

It matters most when evaluating chains for anything with real money in it. For the Proof of Support rubric, it's part of why Scroll's ecosystem score sits where it does — even as Scroll has shifted focus from the points-farming TVL chase of 2024 toward Total Value Secured (TVS) and technical alignment.

→ The build this came from: Week 2 retrospective on Scroll

→ The live app is at https://proof-of-support.pages.dev

→ Scoring methodology for the series: How I'm Scoring the Chains

Why Your Scroll Deployment Cost $25 — And Then $0.04 the Next Attempt

Satori Geeks — Sat, 11 Apr 2026 11:44:55 +0000

forge script returned an L1 fee estimate of roughly $25 to deploy a 6,452-byte contract on Scroll mainnet. L1 base fee at the time: 0.23 gwei — historically low. The wallet had ETH. The node rejected the transaction anyway.

The next morning, the same contract deployed for $0.04 total. The 625× gap comes down to two parameters and who controls them.

What the oracle returns

Every Scroll transaction carries an L1 data fee on top of the L2 execution fee. The Curie hardfork (mainnet July 3, 2024) introduced this formula:

l1Fee = (commitScalar × l1BaseFee + blobScalar × txDataLength × l1BlobBaseFee) / 1e9

Both parameters are in the L1GasPriceOracle contract at 0x5300000000000000000000000000000000000002. Call getL1Fee(bytes calldata data) with your serialised transaction to see what Scroll will estimate.

At peak: L1 base fee was 0.23 gwei, commitScalar was 6,195,200,000,000. The oracle returned 15,216,334,956,613,434 wei — roughly $25. The math checks out.

getL1Fee is an upper-bound estimate, not the amount charged. The oracle is a push model — a Scroll-operated relayer updates l1BaseFee and l1BlobBaseFee when the change crosses a threshold. Once your transaction lands in an L2 block, the L1 fee locks in at whatever value the oracle holds at that moment. The sequencer absorbs the difference between quoted and actual L1 cost. The actual charge is typically ~2× lower than the estimate.

What happened to the scalars

The $25 estimate wasn't caused by high Ethereum gas or unusual contract size. Over roughly four days, the Scroll team made six consecutive setCommitScalar and setBlobScalar calls from a team multisig — a cumulative 1,280× increase.

There's no onchain governance vote required to update these parameters. No timelock. The L1GasPriceOracle owner calls the setter directly. Scroll's own SDK docs noted as of early 2025 that tooling to automate updates was "currently being built" — the adjustments are manual operational decisions.

On April 9, 2026, after developer pushback — notably from the Succinct relayer team — the scalars were rolled back 160×. Transactions that had been costing $20+ returned to fractions of a cent. Total excess fees paid during the spike: roughly $50,000. Automated Ether.fi Cash bots, mid-migration to Optimism, bore about 66% of that. L2BEAT and The Defiant covered the event; the event framing is theirs; the numbers here are on-chain.

The deploy, after the rollback

Next morning: L1 base fee at 0.092 gwei. getL1Fee estimated 0.000038 ETH. Actual L1 data fee on-chain: 0.000019191719458387 ETH. Total deploy cost: 0.000019357216031371 ETH — $0.04.

The 2× gap between estimate and actual is expected, not a discrepancy. The conservative fluctuation_multiplier baked into the scalars is intentional. The sequencer quoted high, settled lower, kept the margin.

Gas used: 1,377,898 of 1,791,267 (76.92%). Same 6,452-byte bytecode. Identical contract.

Before you deploy on Scroll

Read l1BaseFee() from the oracle before any large deploy. If it looks elevated relative to L1 mainnet gas at etherscan.io/gastracker, the scalars may be set high — not L1 congestion.

Treat getL1Fee as a ceiling. A 2× overestimate is normal. During the April 2026 spike it was the difference between $25 and $0.04.

There's no automated alert when scalars change. The most reliable current signal is L2BEAT's Scroll page or the Scroll team's announcement channels.

If the estimate looks wrong, wait. The fee model is an operational parameter, not a protocol constant. It changed 1,280× in four days. It rolled back in one.

The contract deployed. Week 2 is done. The mechanism is documented.

→ The build this came from: Week 2 retrospective on Scroll

→ The live app is at https://proof-of-support.pages.dev

→ Scoring methodology for the series: How I'm Scoring the Chains

Research Passed. Tests Passed. Security Passed. Scroll Mainnet Didn't.

Satori Geeks — Thu, 09 Apr 2026 14:47:47 +0000

The wallet had ETH. The transaction kept failing with "insufficient funds."

I checked the balance: cast balance confirmed 0.0023 ETH. The error was -32000: invalid transaction: insufficient funds for l1fee + gas * price + value. That last field was the tell. This wasn't about execution gas.

The investigation

Sent 1 wei to myself first — no calldata, just to confirm the account could actually send anything.

cast send 0x5f7bD072EADeB2C18F2aDa5a0c5b125423a1EA36 \
  --value 1 --rpc-url https://rpc.scroll.io \
  --account deployer --legacy --gas-price 200000

Went through. Receipt showed l1Fee: 127,720,592,525,704 wei (0.000128 ETH) for zero calldata. At 0.23 gwei Ethereum base fee. Which is historically low.

That was the tell. Queried the L1GasOracle at 0x5300000000000000000000000000000000000002 for the full picture. Post-Curie hardfork, Scroll's fee model uses a commitScalar to price L1 data.

commitScalar: 6,195,200,000,000

6.2 trillion. That number amplifies how much weight L1 data costs carry in the final fee. Then called getL1Fee directly with the deployment bytecode — all 6,452 bytes.

Result: 15,216,334,956,613,434 wei. That's 0.01521 ETH in L1 fees before L2 execution. Total roughly 0.016 ETH, about $25 at current prices.

Week 1, Base: 0.000021 ETH total including L1 fees. Same contract, same bytecode.

That's 700×. Not a universal constant. Base and Scroll have different underlying architectures, DA models, and fee parameters. It's the number for this contract, on these two chains, at the time of testing.

Mainnet cancelled. Not a bug, not a configuration error. Economically unsuitable for this use case.

(The per-transaction L1 fee tells the same story: in this implementation, a user's sendSupport call would cost more in L1 overhead than the tip itself. Deployment cost is sensitive to bytecode size and compression, so other contracts will see different numbers — but for a small social contract, the math doesn't work.)

One thing worth calling out

Scrollscan runs on Blockscout, not Etherscan. On the verified contract page there's a file tree panel in the sidebar: the full project directory structure, each file readable on click. Nothing flattened into a single tab. There's also a UML diagram auto-generated from the Solidity source: inheritance, state variables, function signatures in one view. Best block explorer UX I've seen in this series so far. The UML visualizer especially — Etherscan doesn't have one.

The verified testnet contract is at 0x6D89c4974f8f211eD07b8E8DA08177DEE627DeFa on Scroll Sepolia. Worth a look at the explorer tab.

Community signal

Posted to Farcaster, Scroll Discord, and Ethereum StackExchange asking about the Curie fee model's impact on deployers. No response so far. If I got the fee mechanics wrong, nobody's corrected me yet. Not bitter — but it's a data point, and the rubric counts it.

The vibe check

(Full methodology: How I'm Scoring the Chains)

Dimension	Weight	Estimated	Actual	Delta
D1 Getting Started	×1.0	4	2	-2
D2 Developer Tooling	×2.0	5	5	0
D3 Contract Authoring	×2.0	5	5	0
D4 Documentation Quality	×1.5	4	3	-1
D5 Frontend / Wallet	×2.0	4	4	0
D6 Deployment Experience	×1.5	4	3	-1
D7 Transaction Cost	×1.0	3	1	-2
D8 Community & Ecosystem	×1.0	3	2	-1

Weighted total: 42/60. Good band. Research estimated 50/60.

Every point of that 8-point drop came from economics and ecosystem, not tooling.

D2, D3: identical Foundry and OZ setup to Week 1. Nothing changed. Score unchanged.

D1 (2/5): nine faucets tried. Most required login, mainnet ETH balance, or were under maintenance. Resolution: Sepolia ETH from Google Cloud Web3 faucet, bridged via the Scroll Sepolia portal. About 10 minutes waiting for the bridge. The neighbourhood is fine once you're in; getting there is a longer walk than expected.

D4 (3/5): Scrollscan stopped accepting new API key registrations mid-transition between explorer providers. The fix is Foundry's --verifier blockscout --verifier-url https://sepolia.scrollscan.com/api/ flags. Not mentioned anywhere in the official getting-started docs. The Curie fee model impact on deployers is the same story — research and blog posts exist, but none of it is surfaced where a developer would look before a mainnet deploy.

D5 (4/5): wagmi ships scroll and scrollSepolia chain imports. Wallet integration was clean. Dropped the Coinbase SDK connector — Scroll supports EIP-1193 so injected wallets including Coinbase Wallet work fine, but the Coinbase SDK's Smart Wallet onboarding path lacks native Scroll support. Integration hurdle, not a chain-level incompatibility. Worth knowing before you wire it up.

D6 (3/5): testnet was a single command, Blockscout verification worked first attempt. Mainnet blocked on economics, not process.

D7 (1/5): ~$25 to deploy at historically low L1 prices. That cost would increase significantly under higher L1 gas prices — rollup fees don't scale linearly due to batching and compression, but the direction is clear. For small, frequent transactions the L1 fee overhead is structural and unworkable for this use case.

D8 (2/5): three channels, zero responses.

Testnet is the verdict

The testnet deploy worked cleanly. One command, contract verified on Blockscout, 14/14 tests passing. The decision to stop at testnet was economic, not technical.

There is no mainnet contract address. That's not an oversight.

Verdict: The ZK proof system is genuinely interesting. Foundry, OZ, wagmi all work identically to every other EVM chain. The Blockscout explorer is the best in this series. The fee model, at current parameters, makes Scroll unsuitable for social micro-transactions.

I wouldn't build a production tip jar here today.

Update — same day, a few hours later

It went through.

Contract live on Scroll mainnet at 0x53814B0BB5fe236285843342563213287DFFb674. First message already sent — tx on Scrollscan.

Total deploy cost: 0.000019357 ETH. $0.04. L1 data fee: 0.000019191 ETH, L2 execution: 0.000000165 ETH. The oracle's re-query had estimated ~0.000038 ETH earlier — actual was roughly half. It overestimates.

The number worth keeping: peak L1 fee earlier that day was ~0.01521 ETH (~$25). Actual deploy a few hours later: $0.04. Same contract. Same bytecode. Same chain. Same day. ~625×.

That's not a misconfiguration. That's the fee model responding to Ethereum L1 congestion. You cannot quote a deploy cost on Scroll. You can quote a range. That range, within a single calendar day, spanned three orders of magnitude.

The week is complete. Failed retro, then not failed. That's the story.

Something about running five weeks of chain comparisons with AI assistance: the gaps in the documentation that the agents flag as "likely resolved by now" keep turning out to be real.

→ The live app is at https://proof-of-support.pages.dev

→ Scoring methodology for the series: How I'm Scoring the Chains

The runner-up chain won: how I chose Scroll for Week 2

Satori Geeks — Wed, 08 Apr 2026 20:23:46 +0000

Linea scored 51 out of 60 on my rubric. Scroll scored 50. Scroll got the build week.

That one-point gap wasn't post-rationalized. The pick came down to two things the rubric doesn't score directly: faucet auth requirements and timing. I'll get to both.

Two chains that didn't make the shortlist

Five candidates went through the blocker check. Two were eliminated. Polygon zkEVM was announced as sunset in June 2025. PancakeSwap pulled support the following month and developer momentum has been draining out since. Building on it now would produce an article about a chain in hospice care. Kakarot was simpler: the GitHub repo was archived January 9, 2025, the team was acquired by Zama, and they pivoted to FHE. No deployable mainnet. Both gone before we talk scores.

The remaining four

zkSync Era made the cut but scored the lowest at 40.5 out of 60. The foundry-zksync fork is still alpha, tests run roughly 17× slower than mainline Foundry, and the native account abstraction model means msg.sender behaves differently in smart wallet contexts. Real build risk for a quick-turnaround week.

Taiko is technically the purest: Type 1 zkEVM, identical EVM, zero code changes, decentralized sequencer through Ethereum L1 validators. It scored 49. TVL sits around $20M, and the Hoodi testnet only replaced Hekla in September 2025, so the wagmi chain definition needs manual configuration. Newer testnet story than I wanted.

That left Linea at 51 and Scroll at 50.

Why Linea almost won

Linea is built by Consensys, the same company behind MetaMask, and it ships pre-configured in MetaMask's default network list. Docs are professionally maintained. TVL is the highest of the qualified candidates. The proof system uses lattice-based cryptography (Vortex/Plonk) instead of elliptic-curve SNARKs, which is a genuinely interesting post-quantum angle. If the criterion were "biggest chain with the most traction," Linea wins.

Why Scroll won

Two things.

First: faucets. W1 on Base went smoothly partly because the testnet faucet only needed a wallet address. I learned to check this before scoring, not after. Linea's cleanest path to Sepolia ETH requires a free Infura account. Not social-gated or ENS-gated, but you still need an account. Scroll's Telegram bot takes a wallet address and sends ETH, nothing else. That difference is small on paper. After last week, I notice it.

Second: timing. In April 2025, Scroll replaced its entire prover stack. The original architecture used hand-written halo2 arithmetic circuits to prove EVM execution, one circuit gadget per opcode, with a hard capacity ceiling per batch. Euclid swapped it out for OpenVM, a RISC-V zkVM built by Axiom in collaboration with Scroll and the Ethereum Foundation's research team. Instead of proving EVM execution directly, the system compiles to RISC-V and proves that. Throughput went up 5×, transaction costs dropped roughly 50%, Scroll hit Stage 1 ZK Rollup status on L2Beat. They also moved from a custom zktrie to Ethereum's standard Merkle-Patricia Trie, so any tooling that handles Ethereum state proofs now handles Scroll state proofs too. Most developers I've talked to don't know this happened. It's April 2026 and it's still not common knowledge.

The TVL question

Ether.fi exited to Optimism in early 2026. They took 300,000 user accounts, 70,000 active cards, and roughly 85% of Scroll's TVL with them, dropping the number from over $1 billion to around $27 million. That's the number. Ether.fi's reason: Optimism has larger TVL and a broader app suite, which matters more than ZK rollup maturity for a payments product. That's a real signal about where liquidity goes. But it's a liquidity routing decision, not a judgment on the developer infrastructure. The tooling is solid. The proving stack is active. The GitHub has ongoing commits across 152 repositories as of April 2026. TVL and developer experience are different charts.

What the pick says

Picking the second-ranked chain means the rubric is a starting point, not a verdict. A 1-point gap is noise. What mattered was whether the friction points I care about actually lined up: faucet auth on day one, a fresh technical story, proven tooling. They did.

Scroll was open-source from the first commit. Not retroactively. A governance vote happened before the biggest upgrade shipped. W1 was the establishment chain. This is the contrast.

→ The live app is at https://proof-of-support.pages.dev

→ Scoring methodology for the series: How I'm Scoring the Chains

I ran the same smart contract through three AI security audits. The brief was the bug.

Satori Geeks — Fri, 03 Apr 2026 15:28:24 +0000

A smart contract reviewed by the same model that wrote it is a managed risk at best. Models from the same family, given similar prompts, will apply similar reasoning patterns — not because they're "colluding," but because of their shared DNA. If they're trained on the same overlapping datasets (Common Crawl, GitHub, Stack Overflow), they'll likely converge on the same blind spots regarding obscure Solidity vulnerabilities or specific EIPs. The same interpretive pattern that shaped a flaw is the one most likely to miss it.

The fix isn't to stop using them; it's to increase coverage. Running reviews across different lineages — different training data, different alignment, different fine-tuning — minimises the chance of a shared blind spot. ChatGPT, Gemini, and Qwen are all transformers, but the paths they took to get here are different enough to matter.

For Week 1 on Base, I ran the audit on three models independently: ChatGPT, Gemini, and a local Qwen instance. Same contract, same checklist, parallel sessions. No "peeking" allowed.

What three independent audits found

All three passed. No one found a dealbreaker. That's a useful signal, but it isn't a guarantee. LLM-based reviews can still miss critical vulnerabilities entirely; having three models agree doesn't change the underlying tech's limits. What it does do is ensure a gap isn't just a quirk of one model's training.

Interestingly, all three flagged the same bottleneck: getMessages() iterates over the entire message array to return results newest-first. This is an O(n) scaling issue. On Base (an L2), gas is cheap, but the block gas limit is still the ceiling. While off-chain view calls would handle the load, any on-chain transaction triggering that iteration would eventually revert — a Gas Limit DoS that grows silently alongside adoption.

Qwen called it Medium severity. ChatGPT and Gemini treated it as a Note. The resolution: spec-required, acceptable at current scale, no action before mainnet. The finding was consistent; the panic level was the variable.

The brief was the real problem

This was the biggest takeaway I didn't see coming.

My original brief for all three models was: "Audit the contract against the spec." That's a standard request, but it's also a trap. It frames the spec as the ceiling. A model following that instruction will check if the code matches the document, but it won't necessarily ask if the document itself is flawed or missing key security properties.

I caught the framing error early and updated the briefs: "Perform a full security audit; treat the spec as the correctness baseline, not the audit scope."

It's a minor wording tweak with a massive shift in optimisation. The spec becomes a reference — what the contract is supposed to do — rather than a boundary — the only thing you need to check. The first brief asks for conformance. The second asks for vulnerabilities.

The lesson: prompts are specifications. The same discipline that goes into writing a contract interface — precise, unambiguous, explicit — has to apply to the security brief. Vague input produces vague output. Not because the model is "lazy," but because the brief didn't ask the right question.

The new standing structure

Three-model review is now the standard. Each week, three parallel briefs go out — SECURITY_CHATGPT.md, SECURITY_GEMINI.md, SECURITY_QWEN.md — and consolidate into a single security.md for the final handoff.

This isn't just overhead. It's the difference between a single-pass sanity check and a robust coverage strategy. It's not a replacement for formal verification or a professional audit, but it's significantly more reliable than a single-model pass.

The structural risk of AI blind spots is real. The solution has to be structural, too. Running a parallel process surfaced a flaw in the briefing that a single-model review never would have caught.

The contract passed. The process stayed. The next brief is already in the works.

→ The full Week 1 build — deploy experience, faucet reality, rubric scores — is in the retrospective: Week 1: Base — 56/60

→ The live app is at https://proof-of-support.pages.dev

Base Is Migrating Off the OP Stack. Here's What I Checked Before Building.

Satori Geeks — Thu, 02 Apr 2026 10:05:32 +0000

In February 2026, Coinbase announced what amounted to a quiet bombshell: Base is moving away from the OP Stack toward an in-house "unified codebase."

I caught the news right as I was prepping a contract deployment. My entire stack — chain IDs, RPC endpoints, Foundry configs, wagmi imports — had been built for the OP Stack. My first thought wasn't "this is a crisis," but it was: is my documentation about to become obsolete at the exact moment I hit deploy?

I went down the rabbit hole. Here's what's actually changing.

What the migration actually is (and isn't)

The new system is the unified stack, currently living in github.com/base/base.

Don't let the "in-house codebase" framing spook you. This isn't a VM overhaul or a sudden pivot to ZK (yet). It's an infrastructure consolidation — pulling components previously scattered across different repositories into a single Base-managed binary, built on open-sourced components including Reth, the Rust Ethereum execution client.

Status as of now: v0.6.0 shipped March 27, 2026, and the repo has over 3,000 commits. We're well past announcement territory. The full mainnet cutover is expected "in the coming months," per the blog. Base Sepolia and mainnet RPCs are unaffected throughout.

One data point on the Superchain side: DL News reports that revenue sharing with the Optimism Collective is expected to end as part of this move, citing an Optimism spokesperson. The OP token fell roughly 4% on the day of the announcement, with further declines over the following days. Whether the Superchain model survives that departure is a debate for another day; the price move is just a signal of how it was read.

Building on Base this week? Change nothing.

I cross-referenced the Base Engineering Blog with current tooling and repo activity. No changes have been announced to developer-facing tooling, and everything continues to work as-is:

Solidity: pragma solidity 0.8.24 — still correct. No EVM or compiler changes.
Foundry: Business as usual. forge script --verify still targets Basescan. Base has explicitly committed to "continue contributing to Foundry."
RPCs: https://mainnet.base.org and https://sepolia.base.org — no changes. Base's stated commitment: "All RPCs, including those in the optimism namespace, will continue to be fully supported."
Frontend: import { base, baseSepolia } from 'wagmi/chains' — unchanged. Chain IDs 8453 (mainnet) and 84532 (Sepolia) do not change mid-chain. Base commits to "continue contributing to Wagmi."
viem, EIP-1559, block.timestamp — no changes announced.

The Research Agent ran the verification in minutes; the conclusion took three seconds to read. Nothing you interact with as a developer has changed.

Two threads to watch

Two items stayed on my radar after the verification pass.

1. The proof system upgrade. Base has had fault proofs live since October 2024, using the Cannon optimistic system — permissionless challengers, 3.5-day dispute window. Base reached Stage 1 decentralization in April 2025. The unified stack roadmap points toward Base V1: a planned swap from optimistic to TEE/ZK proofs for faster finality. No launch date yet. This is an upgrade to a functioning system, not a gap being closed — but worth watching when the spec arrives.

2. The exit mechanics. Two paths currently protect you from sequencer failure. Withdrawal finalization has a 7-day challenge window. If the sequencer goes offline entirely, you can force transaction inclusion via L1 — L2Beat documents up to a 12-hour delay on that path. Both are confirmed compatible during the current transition. How they change post-Base V1 is not publicly specified — a genuine documentation gap to revisit once the spec is out.

I checked what I needed to before building. The tools work as expected. Two threads to revisit when Base V1 ships — the proof system upgrade and the exit mechanics spec. The build went ahead on the same configuration the research documented. The Week 1 retrospective covers how it went.

→ The full Week 1 build — deploy experience, faucet reality, rubric scores — is in the retrospective: Week 1: Base — 56/60

→ The live app is at https://proof-of-support.pages.dev

→ Scoring methodology for the series: How I'm Scoring the Chains

Your private key doesn't belong in your terminal. Here's the Foundry fix.

Satori Geeks — Wed, 01 Apr 2026 13:10:01 +0000

You're about to run forge script --broadcast. The command needs a private key. The options that come to mind first all share the same problem: paste it into the terminal and it ends up in .bash_history or .zsh_history. Put it in .env and it's one accidental git add away from the repo. Hardcode it in the deploy script and it's in version history the moment the file is committed. These aren't theoretical risks — they're how keys get exposed.

There is a better way built directly into Foundry.

Using Foundry's encrypted keystore

Import your private key into an encrypted keystore:

cast wallet import deployer --interactive

The --interactive flag prompts for your private key and a password. Foundry stores the key encrypted at ~/.foundry/keystores/deployer. Nothing touches shell history. The name deployer is arbitrary — use whatever you'll recognise.

Before running a deploy, confirm the import worked:

cast wallet list

This lists all keystores by name. If deployer appears, the import succeeded. Two seconds, one less thing to debug mid-deploy.

Now run the deploy referencing the keystore by name:

forge script script/Deploy.s.sol \
  --rpc-url $RPC_URL \
  --account deployer \
  --broadcast \
  --verify

--account deployer tells Foundry which keystore to use. It prompts for the password at runtime. The private key is not in the command, not in .env, not anywhere in the repository. The password prompt is the only moment the key decrypts, and it never leaves your machine.

What this protects against: shell history logs every command you run — .bash_history, .zsh_history, your terminal emulator's scrollback. .env files get committed. Command arguments show up in process listings. The key is encrypted at rest and decrypted only at deploy time. There is no passive exposure surface.

One note on the password

The password matters. A weak password on an encrypted keystore holding a deploy key for a contract with real funds is not meaningfully safer than .env. Use a password manager. The keystore adds a layer; the quality of your password determines what that layer is worth.

This is now the default for every remaining week of this series. First-time setup took about ninety seconds. The instinct — "I don't feel okay putting it in the terminal" — was right; the tooling already had the answer.

→ The full Week 1 build — deploy experience, faucet reality, rubric scores — is in the retrospective: Week 1: Base — 56/60

→ The live app is at https://proof-of-support.pages.dev

→ Scoring methodology for the series: How I'm Scoring the Chains

How I'm Scoring the Chains

Satori Geeks — Wed, 01 Apr 2026 12:58:06 +0000

Designing a scoring system after the build is convenient. The dimensions settle around what you happened to encounter; the weights drift toward what turned out to matter. The score feels right because the rubric was shaped around the result.

This one was fixed before Week 1 started.

A scoring system designed after the build will justify what happened rather than measure it. Building it first forces the criteria to be general enough to apply to every chain — EVM and non-EVM, polished and experimental — before you know which one you're deploying on.

Eight dimensions. Three weights.

#	Dimension	Weight	Max
D1	Getting Started	×1.0	5
D2	Developer Tooling	×2.0	5
D3	Contract Authoring	×2.0	5
D4	Documentation Quality	×1.5	5
D5	Frontend / Wallet	×2.0	5
D6	Deployment Experience	×1.5	5
D7	Transaction Cost	×1.0	5
D8	Community & Ecosystem	×1.0	5

Maximum score: 60. Each dimension scores 1–5. The weight reflects how much that dimension determines whether you'd actually build a production app on the chain.

D2, D3, and D5 carry the most weight because they are the daily surface: the tools you use every hour, the language you write in, the wallet integration you fight with on every frontend. Get those wrong and no amount of documentation or community enthusiasm compensates.

D4 and D6 are mid-weight — important but recoverable. Bad documentation can be worked around with research; a difficult deploy flow can be scripted.

D1, D7, and D8 are single-weight. Getting started friction matters, but you only experience it once. Transaction cost matters for production apps, but at this scale the variance between chains is more interesting than the absolute number. Community is context, not infrastructure.

What I'm measuring

Each dimension is scored from the perspective of a developer building this specific app — a social tip jar with a straightforward contract, wallet connect, and a message wall — on this specific chain, this specific week. Not a permanent rating. A snapshot of the developer experience at build time.

D1: everything before the first line of code — wallet setup, testnet funds, network configuration. The faucet experience lives here.
D2: the toolchain — Foundry or equivalent, CLI tools, local node, testing. How much of the standard EVM workflow translates unchanged?
D3: the contract side — EVM equivalence, library support, Solidity version compatibility, anything that required rewriting logic.
D4: documentation — official quickstarts, deployment guides, API references. Does the official docs get you to a working deploy, or do you end up in forum threads?
D5: frontend and wallet layer — chain imports in wagmi/viem, wallet connector support, anything that required custom integration.
D6: deploy and verify workflow — commands, manual steps, verification speed, block explorer quality.
D7: transaction cost on mainnet — deploy cost and per-transaction cost for the app's primary function. For a tip jar, a transaction that costs more than the tip is broken.
D8: broader ecosystem — community size, documentation freshness, signs of active development versus stagnation.

The score bands

55–60: Outstanding — build here with confidence, caveats worth naming but none are blockers.
45–54: Strong — solid foundation, specific gaps worth understanding before committing.
35–44: Mixed — viable, but with meaningful friction or risk you need to plan around.
Below 35: Challenged — fundamental issues that affect the build directly.

→ The full Week 1 build — deploy experience, faucet reality, rubric scores — is in the retrospective: Week 1: Base — 56/60

→ The live app is at https://proof-of-support.pages.dev

Week 1: Base — 56/60

Satori Geeks — Tue, 31 Mar 2026 11:58:52 +0000

The app deployed cleanly. I ran the function. Nothing happened.

That's cast call. It simulates — never broadcasts. The fix was cast send. One word. Thirty seconds once I asked the right question. (The honest version: I knew the difference, once. Muscle memory had just drifted.) Returning to a toolchain after time away means re-learning where the sharp edges are — even when the tooling is genuinely excellent.

Before writing a line of code, I ran a verification pass on Base's OP Stack migration. Infrastructure consolidation, not a developer-surface change. Every tool confirmed unchanged. The full check is in a separate article.

Then the faucet situation. This is where the PM brain kicked in — because the developer brain just wants to deploy, and what I found was a TSA pat-down at every gate. Ethereum Ecosystem required an ENS name. Bware Labs was under maintenance. QuickNode and Alchemy required an ETH balance on Ethereum mainnet. LearnWeb3 wanted wallet connection and GitHub auth. Five faucets, five blocked. The one that worked — Coinbase Developer Platform — required sign-in and delivered 0.0001 Sepolia ETH. Enough to proceed. But the "multiple no-auth faucets" story from the research didn't survive contact with reality. That's a getting-started problem — the kind of friction that doesn't show until someone actually tries to move in.

Private key: encrypted Foundry keystore, not .env. Right call. Full method in a dedicated article.

The deploy itself:

forge script script/Deploy.s.sol:Deploy \
  --rpc-url baseSepolia \
  --broadcast \
  --verify \
  --etherscan-api-key $BASESCAN_API_KEY

"Pass - Verified" on Basescan in forty-five seconds. No flattening, no manual ABI upload, no second command. That's the D6 story in one run.

Mainnet followed the same path. Contract address: 0x6D89c4974f8f211eD07b8E8DA08177DEE627DeFa. Same address as Sepolia — the EVM derives contract addresses from deployer nonce, and mine matched on both networks. A separate Farcaster thread covers the mechanics. Frontend wiring was one environment variable: VITE_BASE_CONTRACT_ADDRESS. Wallet connect, form submit, sendSupport(), on-chain confirmation, message on the wall. End-to-end in one take. First live mainnet message: "First message outside the testnet." Verifiable on Basescan.

One post-QA fix: the first mainnet message came in at 10,000,000,000,000 wei, and formatAmount displayed it incorrectly below 0.0001 ETH. Tests written, implementation fixed. The dev half wrote the code; the PM half noticed the edge case existed. That split is the whole job.

The Vibe Check. (Eight dimensions, three weights, max 60. Full methodology: How I'm Scoring the Chains)

D2, D3, D5, D6: all 5/5. The locals know what they're doing here. Foundry runs identically to Ethereum mainnet. OpenZeppelin v5.0.2 installed without ceremony. Wagmi ships a base chain import out of the box. forge script --broadcast --verify deploys and auto-verifies in a single run. No translation required — if you've built on EVM before, you already speak this language.

D7 (5/5): under $0.005 per sendSupport at current ETH prices, 0.005–0.006 gwei effective gas price. For a tip jar. Practically free.

Three misses.

D1 (4/5): the faucet. Five of six blocked — ENS requirements, mainnet balance gates, maintenance, GitHub auth. The one that opened required sign-in and gave 0.0001 ETH. The neighbourhood works fine once you're in. Getting there is harder than the welcome mat suggests.

D4 (4/5): the official Base quickstart uses forge create, not forge script. The [etherscan] block needed for auto-verification isn't in the primary guide — it came from the research doc. The street signs are in a language only locals speak. Not a blocker for someone who's been here before. A genuine detour for everyone else.

D8 (4/5): large community, Farcaster-native, Coinbase-backed, highest daily transaction volume of any L2. The score is 4 because Base is departing the Optimism Superchain — OP token dropped roughly 7% on the announcement. Zero practical impact on this deploy. But a chain leaving a shared ecosystem is a signal, and I've been around long enough not to ignore signals.

Weighted total: 56/60. Outstanding band.

The research estimated 56. The build delivered 56. Zero delta is what a baseline is supposed to do — the rubric held up, which means it's functioning. The interesting data starts next week.

Verdict: I would build a production app on Base, with the standard caveats — no live fraud proofs yet, Coinbase trust assumption, Superchain transition still in progress. None of those are blockers at this scale. Live app: https://proof-of-support.pages.dev. Contract verified at 0x6D89c4974f8f211eD07b8E8DA08177DEE627DeFa on Base mainnet.

Base is home. If you've built on Ethereum mainnet, you already know this toolchain — you just haven't paid these gas fees.

Week 2 is coming. The chain is chosen. The toolchain will not be identical. That's the point.

→ The live app is at https://proof-of-support.pages.dev