The decision that forced everything else was the Solana week.
Once I knew there would be a non-EVM chain mid-series — a week using Rust and Anchor instead of Solidity and Foundry — a dozen downstream decisions snapped into place. What frontend framework to use. How to handle wallet connectors. Which hosting platform made sense for weekly chain swaps. Almost nothing about the technical stack was chosen independently of the chain lineup.
So let's start with the chains.
Why Base for Week 1
Week 1 is Base. It's the only locked decision in the series.
Base is an Ethereum L2 mid-transition. In February 2026, Coinbase announced it's migrating away from the Optimism OP Stack toward its own unified in-house codebase — consolidating infrastructure under one roof while keeping the protocol open source and EVM-equivalent. The architecture is moving. The developer surface isn't: Foundry works out of the box, wagmi has a built-in base chain import, Basescan works like Etherscan. No custom compiler, no exotic account model.
That stability — an infrastructure shift that produces no developer-visible friction — is exactly what makes it the right baseline week. The point of Week 1 is to establish a clean reference point. Starting with something exotic would make the baseline noisy and the comparisons less meaningful.
The five-week arc
Weeks 2–4 have recommended picks — zkSync Era, Moonbeam, and Solana — confirmed at the start of each week, not in advance. The reason is straightforward: the quality of the research on a chain is only really testable by building on it. A rough Week 1 could change what matters most to investigate in Week 2. Locking every chain now would throw away that feedback loop.
Week 5 is intentionally unplanned. The slot exists to follow wherever the first four weeks lead — or wherever feedback, a surprising discovery, or a chain worth reviewing points.
The arc is intentional, though. Think of moving into a new neighbourhood each week, starting at the most familiar address on the street:
- Week 1 (Base): Standard EVM L2. Same toolchain, same patterns, just cheaper gas. The baseline.
- Week 2 (plan: zkSync Era): ZK-EVM — same Solidity, different execution environment. The ZK proofs themselves are transparent to the developer; the custom compiler and partial EVM equivalence are not.
- Week 3 (plan: Moonbeam): EVM on Polkadot. Same language, but the chain runs as a parachain on a different underlying platform. The toolchain feels familiar; the infrastructure beneath it doesn't.
- Week 4 (plan: Solana): Non-EVM. Rust, Anchor, a completely different account model. This is the week that moves to a different city entirely.
- Week 5: Open — deliberately unplanned. Not another EVM chain. Whatever the first four weeks point toward.
That's a better story than picking chains arbitrarily. Each week changes the frame of reference for the one that follows — and the final slot stays open to follow where the experiment leads.
Two chains that didn't make the list: Polygon PoS is technically a sidechain, not a rollup — but it's mid-transition. Polygon 2.0 is moving it toward a zkEVM-based architecture — rollup territory rather than pure sidechain — though the final form (rollup, validium, or hybrid) is still evolving. That's the real reason it doesn't fit here: it's too far into transition to serve as a clean EVM L2 baseline, and not far enough along to be the ZK-EVM week — a slot Week 2 already covers. Evmos had real potential as a Cosmos EVM option for Week 3, but the team pivoted to building "evmOS" as a framework rather than a destination chain. Ecosystem momentum has been uneven enough that its status as a destination chain — rather than a framework — is unclear, which makes it a higher-risk choice for a one-week build.
Why React, and why per-chain adapters
Back to Solana.
@solana/wallet-adapter-react — the only mature, officially maintained Solana wallet adapter — requires React. Once that's true for one week, switching frameworks between weeks adds cognitive and tooling overhead for no gain. React + Vite is the call because of Week 4, not because it's the only option for the EVM weeks.
The obvious shortcut for wallet connectors was Reown AppKit (formerly Web3Modal), which claims EVM and Solana support in a single React library. The problem: at the time of writing, there are documented open bugs in EVM-to-Solana session switching. For a project that changes chain configurations weekly and already defines a clean per-chain adapter interface, that abstraction layer adds instability without removing meaningful complexity.
The approach instead: one adapter per week, each around 130 lines of code, each self-contained. EVM weeks (1–3) use wagmi + viem. Solana week (4) uses @solana/wallet-adapter-react + @coral-xyz/anchor. Week 5 gets its own adapter once the chain is confirmed. Each one implements the same five-method adapter interface — connect, disconnect, sendSupport, getMessages, getChainMeta — behind a consistent contract. (sendSupport, getMessages, and withdraw are the smart contract's three functions; the adapter adds wallet lifecycle on top.) The frontend calls the interface; the adapter handles the chain. Clean, auditable, no vendor dependency — and the isolation was a hard requirement, not a convention: FR-027 in the spec prohibited chain-specific imports outside src/adapters/weekN/ in any UI shell file, enforced by spec rather than left to discipline.
Hosting: Cloudflare Pages
Vercel was the obvious call. It wasn't the right one.
The Hobby plan includes restrictions around commercial usage, which can be ambiguous for projects involving on-chain transactions. That ambiguity is a constraint, not a scandal — but it's enough to route around when there's a better option available.
Cloudflare Pages has no such restriction, unlimited bandwidth on the free tier, and built-in preview deployments on every branch push. That last point matters for a project that swaps chain configurations weekly — testing a new adapter without pushing to production is not optional friction. GitHub Pages was ruled out for the same reason: preview deployments require manual setup there.
One note on decentralisation: publishing on Paragraph.xyz already establishes that ethos clearly. The frontend doesn't need to be on IPFS every week to be consistent with the project's identity. The plan is Cloudflare Pages for weeks 1–4, with an optional Pinata IPFS pin on the final Week 5 deploy. That takes about thirty minutes to configure and adds one step to the final build — not to each weekly build.
The stack follows the chain lineup
None of these decisions were made before the chain research was done. React was forced by Solana. Per-chain adapters were forced by the architecture and the adapter instability in universal libraries. Cloudflare Pages was forced by Vercel's ToS.
That's the honest version of how this stack got chosen. The chain list came first, and everything else fell out of it. The spec pre-committed to this outcome before any code existed: SC-005 required zero UI code changes to add a new chain — a measurable criterion written before the scaffold was built, not a post-hoc observation about how it turned out.
The selections also serve a purpose beyond getting weeks built. Each chain is a data point in a question I don't have the answer to yet: which part of this space is worth going deeper into, which tooling is worth learning properly, which direction makes sense for what comes next. Five weeks is the structure. What follows depends on what those five weeks actually surface — and the open slot in Week 5 is the first acknowledgement of that.
Top comments (0)