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.
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
Top comments (0)