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