Forem: Satori Geeks

Why TON beat the highest-scoring candidate

Satori Geeks — Mon, 27 Apr 2026 09:39:41 +0000

Weeks 1–4 each had a defined category. Base was the EVM L2 week. Scroll was ZK. Core DAO was EVM-on-Bitcoin. Solana was non-EVM mainstream. Every week, the category defined the field. The question was never "what kind of chain?" It was "which chain best fits this type?" Clear axis, tractable problem.

Week 5 is the Wildcard slot. The brief from day one: the unknown, what's at the frontier right now? No category. No axis. A wide field and an open question, and it turns out the open question is harder to answer than the constrained one.

The field

Six candidates made the shortlist: Monad, TON, AO on Arweave, Fuel Network, Starknet, Stacks. One parallel-EVM (Monad) and one ZK-VM (Starknet — Cairo makes ZK explicit in the language itself, unlike Scroll where it's invisible plumbing). The most exotic option: AO, which runs Lua on Arweave's permanent log storage. Fuel uses strict VM parallelism via access lists in a UTXO model, with Sway as a Rust-inspired contract language. And TON — Telegram-native, actor-model VM, 900 million monthly active Telegram users already inside the access layer.

Two eliminations worth naming

AO on Arweave scored 27/60. That number undersells it. Lua as the contract language, running on Arweave's permanent log storage — the Holographic State model, where the state itself is never stored, only the process logs, and anyone can replay them to derive the current state (they call this Holographic State). An actor-oriented computation model that makes TON look almost conventional. I genuinely wanted to build on it. The problem: no local test framework, documentation that runs dry fast, sparse production examples.

Stacks (Clarity) was the harder cut. Clarity is interpreted, not compiled — which is what makes it fully decidable: no infinite loops, no reentrancy by design. The source publishes on-chain rather than bytecode, so there's nothing to exploit at the compiler level. Genuinely interesting language. But Stacks settles on Bitcoin. Week 3 was Core DAO, which also settles on Bitcoin (different consensus model, same anchor). Two Bitcoin-settled chapters in five weeks is one too many.

The scored finalists

Chain	Language	Est. Score	One-line verdict
Monad	Solidity (EVM)	54/60	Parallel EVM — best rubric ceiling, fourth EVM week
Starknet	Cairo	43.5/60	ZK in the language, not just the plumbing — strong alt
TON	Tact	43/60	Actor model + Telegram-native + language new to the series
Fuel Network	Sway	40/60	UTXO-parallel architecture, thin ecosystem
Stacks	Clarity	39/60	Interesting language, too much W3 overlap
AO (Arweave)	Lua	27/60	Best story, tooling not build-week-ready

Full methodology can be found here.

Why TON, and why not Monad

Monad scored 54/60 — the highest estimate of any candidate in this series. It would have been the easiest build by a long way: same Solidity contract as weeks 1–3, Foundry, MetaMask. The entire tooling delta is adding one RPC URL to the wallet config. The actual frontier story with Monad is optimistic parallel execution and MonadDb — state-heavy apps can see real throughput gains from that architecture. The tip jar doesn't come close to stress-testing it. There's also a practical catch: Monad is still in gated devnet as of this week, so the real friction wouldn't have been the code at all — it would have been getting network access and a working faucet.

That aside, it still didn't win.

Using the Wildcard slot to ship a fourth Solidity week would have answered "what's at the frontier?" with "what you already know." Reasonable answer most weeks. Not for the finale.

Starknet at 43.5/60 was the strongest alternative. Those 0.5 points over TON's 43 come from tooling: Starknet Foundry and Scarb are genuinely mature, closer in feel to the Foundry experience than Blueprint is. TON's score is lower because the tooling is younger and the actor model has a steeper ramp than Cairo does. But this is a Wildcard pick, and that's a narrative call as much as a DX one. TON has things this series hasn't touched: an actor-model VM where every contract is an isolated process and all cross-contract communication goes through async messages — not a pattern layered on top of shared EVM state, a different execution model from the ground up. A language (Tact) that looks like TypeScript and thinks like Erlang. And the chain is literally embedded as the payment layer in a messaging app 900 million people already have on their phones.

Starknet's rubric ceiling is 0.5 points higher. TON's story ceiling isn't close.

What this means for the build

TON isn't a safe pick. The 43/60 estimate is a promise of friction: the async message-passing model is a genuine mental shift from Solidity, TON uses a Bag of Cells (BoC) architecture where state is a tree of cells rather than EVM's flat storage slots (which makes hitting cell size or reference limits a real constraint when storing arbitrary-length strings), and contract verification on verifier.ton.org is more manual than forge verify-contract. If something blocks mid-week, Starknet at 43.5/60 is the fallback — solid tooling, Cairo is genuinely novel, ZK-in-the-language is different enough from Scroll. But the aim is TON.

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

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

Week 4: Solana — the view from outside the EVM

Satori Geeks — Thu, 23 Apr 2026 13:33:30 +0000

After three weeks of Solidity — Base, Scroll, Core DAO — week four was the one I kept putting off mentally. Same app, same interface spec. But the contract language changes. The runtime model changes. Where state lives changes. I went in expecting a hard week. It was hard. Also weirder than expected in specific ways.

The cost shock

Deploy cost hit first. The full story is in the Anchor vs Pinocchio piece. Short version: I measured the Anchor binary before pushing it to mainnet. 230 KB. At current SOL prices that's $141. On Base or Scroll, deploy costs a dollar or two and you never think about it again.

I rewrote the program in Pinocchio. Four hours, 30 KB, $18 actual deploy cost. Worth it, though I hadn't planned to spend day two on a rewrite.

The mental model shift

On EVM, state lives in the contract. Mappings, arrays, structs — all inside, implicit. Solana programs are stateless. State lives in separate accounts the program owns. For the tip jar that's three accounts: a MessageBoard PDA (global state), a Vault PDA (accumulated SOL), and one Support PDA per message.

Every instruction has to declare explicitly which accounts it touches, before execution — and whether each account is read-only or writable. Sealevel uses that metadata to schedule transactions in parallel: two transactions can run concurrently if they don't share any writable accounts. Touch the same writable account and they're serialised. The verbose account declarations aren't bureaucratic overhead; they're the scheduling contract.

Rent is the other non-EVM thing. Every account holds a SOL deposit proportional to its byte size — a "rent-exempt minimum" it has to maintain to survive. Each message creates a 387-byte Support PDA. The sender pays ~0.00358 SOL for that deposit. At $86/SOL that's $0.31. The transaction fee itself is $0.0004. Worth flagging: unlike EVM storage gas, which is spent and gone, this SOL is a deposit — if the program closes the account it goes back to a specified address. In this implementation, Support PDAs are never closed, so in practice it's permanent. But that's a program design choice, not a chain constraint.

The thing I didn't see coming

Public Solana RPC nodes disable getProgramAccounts. HTTP 410.

I wrote getMessages() with getProgramAccounts — that's what every tutorial uses. Tested on devnet: "Could not load messages." The reason getProgramAccounts is disabled isn't arbitrary rate-limiting — it requires a full scan of the account database, which is expensive enough that most public RPCs (including Helius and Triton's free tiers) simply don't offer it. The fix took an hour once I understood the problem: fetch message_count from the MessageBoard PDA, derive each Support PDA address by index, batch-fetch with getMultipleAccountsInfo. That works for a small program — getMultipleAccountsInfo caps at 100 accounts per call, so it scales fine for a demo. For production with high message volume you'd want a proper indexer: Helius's Digital Asset Standard API or something like Subsquid. But you never see this on a local validator. You only find out at smoke test on a public endpoint.

Rubric scores

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

Dimension	Estimated	Actual	Delta
Getting Started	4	4	—
Developer Tooling	4	4	—
Contract Authoring	3	3	—
Documentation Quality	4	3	−1
Frontend / Wallet	5	3	−2
Deployment Experience	4	4	—
Transaction Cost	5	3	−2
Community & Ecosystem	5	4	−1

Weighted score: 41.5 / 60 (estimated: 50 / 60)

The two big drops: Frontend/Wallet and Transaction Cost. Both looked smooth on paper; both had a gotcha that only showed up in practice.

Verdict

41.5/60. Solana lands in "Good — solid DX with manageable rough edges," and I'm not going to argue with that. Anchor has real depth behind it — the test loop is as good as Foundry, the community answered almost every blocker I hit. Pinocchio is worth knowing about when you care about binary size, though it's not where you'd start.

The per-message SOL outlay came in at $0.31–0.54 (rent deposit on the Support PDA, not the tx fee — technically recoverable if the program closes the account, but this one doesn't). The frontend had a public RPC gotcha that nothing in the docs adequately flags. Both are workable. Neither is what the tutorials show.

One gap the rubric doesn't capture: the developer's one-time deploy cost. On EVM it's irrelevant. On Solana, before the Pinocchio rewrite, it was $141. Full breakdown in the Pinocchio article.

A week out, I'd build on Solana again. With more SOL in the wallet and getProgramAccounts crossed off the list of things I'd reach for.

Building on five chains back to back, what I keep noticing is that the friction is never where the docs say it will be.

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

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

→ Program on explorer

Anchor vs Pinocchio: the real deploy cost

Satori Geeks — Wed, 22 Apr 2026 21:23:53 +0000

The Solana mainnet deploy came in at $141. For a demo project. I stopped, recalculated, and stared at the number for a minute.

I'd built the tip jar in Anchor 0.32.1 — the standard framework, the one with real docs, the one everyone reaches for first. It worked. Seven integration tests passed. Then I checked the binary before committing 1.6 SOL to mainnet: 230 KB.

Three options, one decision

On Solana, accounts need to hold enough SOL to cover two years of rent to become rent-exempt, otherwise the runtime can garbage-collect them. For a program account, that's about 6,960 lamports per byte. At ~$86/SOL, 230 KB works out to ~1.64 SOL — $141.

You can close a Solana program later and reclaim that SOL to a recipient wallet. So it's not technically unrecoverable. But "recoverable in theory" doesn't change what you need in your wallet before you can deploy.

Option	Binary size	Approx. cost
Anchor 0.32.1, unoptimised	230 KB	~$141
Anchor + `opt-level = "z"`, `lto = true`, `strip = "symbols"`	~90–100 KB	~$60
Pinocchio rewrite	15–20 KB (estimation)	~$9

Anchor with size flags was 15 minutes of work. Those flags strip symbols and merge compilation units — they don't touch Anchor's macro overhead. There's a floor, and $60 is still a lot for a demo. I went with Pinocchio.

What Pinocchio actually is

Pinocchio is a zero-dependency Rust framework for Solana programs. No macros, no IDL, no borsh. You write the discriminator logic, the account parsing, the PDA derivation — all of it.

Where Anchor's #[derive(Accounts)] generates validation from a handful of attributes with a lot happening out of sight, Pinocchio puts every check in explicit byte-offset reads. Nothing is invisible. The price for that is verbosity. The reason to pay it is binary size.

The rewrite

Four hours. Three instructions (initialize, send_support, withdraw) and three account types (MessageBoard PDA, Vault PDA, per-message Support PDA). I wrote the byte layout manually, encoded fields by hand, checked boundaries explicitly.

The 7/7 tests passed at the end. Worth noting: since Pinocchio generates no IDL, the TypeScript tests couldn't use Anchor's program.methods.sendSupport().rpc() style. Every instruction had to be built as a raw TransactionInstruction — manual Buffer.concat, explicit account list, correct discriminator byte. So the actual scope of the work was the Rust rewrite plus rewriting the test client from scratch.

Tests ran against a live solana-test-validator with the Pinocchio binary pre-loaded. No Anchor runner.

Binary: 30 KB. Above the 15–20 KB estimate — the manual validation boilerplate adds code that Anchor macros would have inlined. Still 87% smaller than the Anchor build.

Actual mainnet deploy: 0.214 SOL. ~$18. Within 1% of the rent calculation I'd done upfront.

Build	Binary size	Deploy cost
Anchor 0.32.1	230 KB	~$141 (never deployed to mainnet)
Pinocchio 0.9 — estimated	~15–20 KB	~$9
Pinocchio 0.9 — actual	30 KB	$18

The rubric gap

My scoring rubric has a dimension for per-message transaction cost (D7) and one for deployment experience (D6). There's no dimension for the developer's one-time deploy cost.

On EVM weeks — Base, Scroll — this never came up. Both cost cents. On Solana, after the optimisation, it was $18. Before: $141. That's a real number with no rubric home. Worth flagging, because a methodology that doesn't measure something can't be honest about it.

Eight Non-EVM Chains, One Week — Why Solana Won

Satori Geeks — Mon, 20 Apr 2026 21:07:55 +0000

Week four was always going to be the hard one.

Weeks one through three: EVM. Different platforms — Base, Scroll, Core DAO — different security profiles, different deploy quirks. Same language. Solidity, all the way down. Week four is the first time the contract language changes. The question isn't "which non-EVM chain is active?" (most of them are, more or less). It's whether I can actually learn one in a week, starting from Rust-curious-but-not-fluent.

The field

The brief started with five candidates. Three more landed when I started digging: Fuel Network (Sway), Algorand (Python), Radix (Scrypto). Altogether: Rust-based languages, a Python chain, a Move chain, a Haskell-inspired language, and one chain where Rust contracts were recently abandoned.

Two eliminations worth naming

Polkadot / ink!: ink! development and maintenance ended in January 2026. Funding ran out; v5 is the last release. Polkadot is pivoting toward PolkaVM and JAM (Join-Accumulate Machine), but neither is production-ready yet. If a tutorial still lists ink! as a viable target, it's pointing at a dead end. Good to know before you spend a day on toolchain setup.

Cardano / Aiken: Lowest score in the comparison — 34.5/60. Not because Aiken is bad tooling. It isn't. The issue is eUTxO. There is no mapping(address => Message[]). Messages would be UTxOs carrying datums, locked at a script address, constructed entirely off-chain. A one-week build on Cardano isn't about shipping features — it's a week-long wrestling match with a new mental model. Wrong scope for a sprint.

The scored finalists

Chain	Language	Score	Verdict
Solana	Rust + Anchor	50/60	Deepest community, best frontend story, account model is the cliff
NEAR Protocol	Rust or TypeScript	49/60	JS contracts make it approachable; wallet deprecation is a gotcha
Algorand	Python (Puya/AVM)	46/60	Most learnable language, wallet ecosystem is too thin
Aptos	Move	46/60	Polished tooling, resource model shift smaller than expected
Fuel Network	Sway	39/60	Interesting architecture, young ecosystem, one wallet option
Polkadot / ink!	Rust	35/60	⚠ Maintenance ended Jan 2026 — not a safe pick
Radix	Scrypto	35/60	Foundation transition in 2026 adds uncertainty
Cardano	Aiken	34.5/60	eUTxO model is a week unto itself

Why Solana, and why not NEAR

One point between them. NEAR had something real going for it: JS contracts. With near-sdk-js, a Solidity developer writes a NEAR contract in TypeScript and deploys same-day. No Rust. I almost picked it on that basis alone. One caveat worth flagging: near-sdk-js has historically been seen as less production-ready than the Rust SDK — higher gas costs, fewer security audits at scale. For a one-week experiment that's manageable. For production, it matters.

What actually moved the needle was community depth. Not the kind that shows up in a score — the kind that matters at 11pm when something breaks and you need an answer now. Solana has a Helius blog post for the exact error. A StackOverflow thread. Someone in the Anchor Discord hit this three weeks ago and documented the fix. NEAR is active, just smaller. That gap hits at the worst moment.

The other NEAR problem: wallet fragmentation. The original wallet (wallet.near.org) is deprecated. The replacement is scattered across Meteor, MyNEAR, HERE Wallet. You run into that friction during connect-wallet testing — not a good time.

The account model — PDAs, explicit account declarations, rent — is the steepest part. It exists for a reason: Solana's runtime (Sealevel) processes non-conflicting transactions in parallel. Unlike the EVM's single-threaded execution, Sealevel needs to know upfront what each transaction will touch — that's why every account must be declared explicitly. The friction is the feature. Learnable-hard, not paradigm-shift hard. And it's the most transferable thing you take out of the week.

The fallback

If Solana hit a wall mid-build — toolchain drift, account model slower than expected — NEAR with JS contracts was the escape hatch. I wrote that down before starting. One-week builds need a named fallback, not a vague "we'll figure it out."

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

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

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