Where to start with smart contracts

Smart contracts are easier to write than they are to write safely. The web is full of "deploy your first NFT in 10 minutes" tutorials that skip the parts that get people rugged, hacked, or just deeply confused six months later. This path is slower on purpose. You'll deploy something tiny by the end, but you'll deploy it knowing what's happening underneath.

Step 1 — Prerequisites you actually need

Before you write a line of Solidity, you need a working mental model of the EVM. Read Mastering Ethereum, chapters 1 through 7. That's accounts, transactions, gas, the EVM itself, smart contracts in the abstract, and the start of Solidity. Don't skim. The reason most beginner smart contract bugs exist is that the writer didn't internalize how state, storage, and message calls work, and Solidity's syntax hides those details well enough that you can write broken code that compiles.

You should also be comfortable with basic programming — variables, functions, control flow, types. Not expert-level; just enough that "a mapping from address to uint256" doesn't make you flinch. If it does, spend a weekend on any beginner programming course first. Solidity is not the language to learn programming in.

For ecosystem context while you're reading, subscribe to Bankless and let it run in the background. You're not trying to absorb every episode; you're building peripheral awareness of what protocols exist and what conversations the developer community is having.

Step 2 — Learn Solidity in a structured way

This is where the path leaves the catalog and points at external resources, because no book on the shelf is as good for hands-on Solidity as the free interactive ones. In order:

• CryptoZombies is the gentlest on-ramp. It's gamified and dated in places, but the early lessons cover the syntax in a way that sticks.
• Solidity by Example is the reference you'll come back to constantly. Short, focused snippets for every common pattern.
• The Solidity documentation itself is genuinely well-written. Read it after you've written a few contracts, not before — it'll make more sense.

For protocol-level context on what you're building toward, Finematics is the best video resource. Watch the explainers on AMMs, lending, and oracles. You don't need to build any of those yet; you need to understand why the patterns in Solidity by Example exist.

Step 3 — Deploy something tiny

Pick a stupid project. A counter contract that ticks up when called. A guestbook that stores a string per address. A coin-flip contract that gives you a deterministic answer (don't try to do real randomness yet — that's a footgun). The smaller the contract, the more you'll learn per line.

Use Foundry. Read the Foundry Book end to end; it's the best free piece of writing about Ethereum tooling that exists. Deploy to a testnet — Sepolia is the current default but check what's live when you read this. Verify your contract on the block explorer. Read your own bytecode. Look up your transaction. The first time you watch your own contract execute on a public chain is the moment smart contracts stop feeling abstract.

What to skip on day one

Don't write an upgradeable contract. Don't write a contract that holds anyone's money but yours. Don't audit other people's code yet. Don't read about MEV, account abstraction, or zero-knowledge proofs as your first detour — they're fascinating and they will eat your week. And do not, under any circumstances, deploy your first contract on mainnet. Testnets exist for a reason. Use them until you've built and broken at least a dozen things.

Security is its own discipline and you need to know just enough to know you don't know it. Read the Smart Contract Weakness Classification list once. Look up the top three historical exploits — the DAO, Parity multisig, and the Ronin bridge — and understand at a sentence level what went wrong. That's enough to make you appropriately afraid.

What to do after

Once you can deploy and test a small contract confidently, the next jumps are: reading real protocol code (Uniswap V2 is the canonical starting point — short, elegant, well-commented), learning a testing discipline (fuzz testing, invariants), and picking a single protocol category to specialize in. Generalist smart contract developers exist but the good ones all went deep on something first.