Concepts

Ethereum Concepts

What You Probably Got Wrong

"Smart contracts run automatically." No. Smart contracts cannot execute themselves. There is no cron job, no scheduler, no background process. Every function needs a caller who pays gas. This single misconception is the root cause of most broken onchain designs.

"Just add a timer." There are no timers. If something needs to happen at a certain time, you need someone to call the function at that time — and you need to give them a reason to do it.

"The protocol team will handle that." The whole point of decentralization is that no single team operates the system. If your design requires an operator, it's not decentralized — and it has a single point of failure.

Terminology: You say "on-chain." The Ethereum community says "onchain" — one word, no hyphen.

CROPS

CROPS — Censorship Resistance, Open Source, Privacy, Security — is the Ethereum Foundation's shorthand for what makes Ethereum Ethereum.

• Censorship Resistance — You scaffold Pausable + onlyOwner without flagging it. A single key that can freeze all users is a censorship vector.
• Open Source — You treat Etherscan verification as "open source." Real open source means someone can fork the full stack (frontend, indexer, contracts) and run it independently.
• Privacy — You build apps where every address, amount, and counterparty is publicly visible on a block explorer and never mention it. At minimum, tell the builder what's exposed.
• Security — You say "audited" and treat it as proof of security. An audit is a point-in-time review of a specific scope, not an ongoing guarantee.

Four questions to catch yourself: can anyone be stopped from using it? Can someone fork and run the whole stack? What can an observer learn about users? What happens if the team disappears?

Nothing Is Automatic — Incentive Design

This is the most important concept in all of Ethereum. If you internalize nothing else, internalize this.

Smart Contracts Are State Machines

A smart contract is a state machine. It sits in one state, and it moves to another state when someone pokes it — calls a function, pays gas, triggers a transition. Between pokes, it does absolutely nothing. It doesn't think, it doesn't check, it doesn't wake up. It just sits there.

State A ──[someone calls function]──→ State B ──[someone calls function]──→ State C
              ↑                                        ↑
         WHO does this?                           WHO does this?
         WHY would they?                          WHY would they?

There is no cron job. There is no scheduler. There is no background process. The blockchain doesn't call your contract — people call your contract. And people don't do things for free.

For EVERY state transition in your system, you must answer:

1. Who pokes it? (someone must pay gas)
2. Why would they? (what's their incentive?)
3. Is the incentive sufficient? (covers gas + profit?)

If you can't answer these questions, that state transition will never happen. Your contract will sit in State A forever, doing nothing, with nobody poking it.

Incentives Are Everything

Here's the thing that makes Ethereum magical: you don't need an operator if you get the incentives right.

The people who deployed Uniswap didn't deploy the liquidity. They didn't market-make. They didn't run the exchange. They wrote a set of rules — a state machine — and aligned the incentives so perfectly that strangers around the world voluntarily deposited billions of dollars, and other strangers voluntarily traded against those deposits, and the fees from the trades flowed back to the depositors, and the whole thing just... worked.

Nobody runs Uniswap. Nobody CAN stop Uniswap. Not even the people who made it. The contracts are immutable, the incentives are self-sustaining, and the system will run for as long as Ethereum exists. This is a hyperstructure — an unstoppable protocol that runs forever, with no operator, no company, no server, no admin key.

That's what you're building toward. Not a startup. Not a service. A set of rules so well-designed that they run themselves through incentives alone.

Examples of Good Incentive Design

Liquidations (Aave, Compound):

Loan health factor drops below 1
→ ANYONE can call liquidate()
→ Caller gets 5-10% bonus collateral as profit
→ Bots compete to do it in milliseconds
→ Platform stays solvent without any operator, any admin, any team

LP fees (Uniswap):

DEX needs liquidity to function
→ LPs deposit tokens into pools
→ Every swap pays 0.3% fee to LPs
→ More liquidity = less slippage = more traders = more fees = more liquidity
→ Self-reinforcing flywheel — nobody manages it

Yield harvesting (Yearn):

Rewards accumulate in a pool
→ ANYONE can call harvest()
→ Caller gets 1% of the harvest as reward
→ Protocol compounds automatically via profit-motivated callers

Arbitrage (keeps prices correct everywhere):

ETH is $2000 on Uniswap, $2010 on SushiSwap
→ Anyone can buy low, sell high
→ Prices equalize across ALL markets without any coordinator

Examples of BAD Design (Missing Incentives)

❌ "The contract will check prices every hour"
   → WHO calls it every hour? WHY would they pay gas?
   → Fix: make it profitable to call. Or let users trigger it when they interact.

❌ "Expired listings get automatically removed"
   → Nothing is automatic. WHO removes them? WHY?
   → Fix: give callers a small reward, or let the next user's action clean up stale state.

❌ "The protocol rebalances daily"
   → WHOSE gas pays for this? What's their profit?
   → Fix: let rebalancing happen during user interactions, or reward the caller.

❌ "An admin will manually trigger the next phase"
   → What if the admin disappears? Gets hit by a bus? Loses their key?
   → Fix: make phase transitions permissionless with time-based or condition-based triggers.

The fix is always the same: Don't use an admin account. Make the function callable by anyone. Give them a reason to call it. Align incentives so the system pokes itself through the self-interest of its participants.

The Hyperstructure Test

When you're designing a system, ask: "Could this run forever with no team behind it?"

• If yes → you've built a hyperstructure. The incentives sustain it.
• If no → you've built a service. It dies when the team stops operating it.

Both are valid choices. But know which one you're building. The most powerful things on Ethereum are hyperstructures: Uniswap, ENS, the ERC-20 standard itself. They can't be stopped, they can't be censored, they can't go down. Not because they're maintained — because they don't need to be.

Randomness Is Hard

Smart contracts are deterministic. Every node computes the same result. You can't use Math.random() — there's nothing random about a system where everyone gets the same answer.

What Doesn't Work

// ❌ Validators can manipulate block.timestamp (within ~15 seconds)
uint random = uint(keccak256(abi.encodePacked(block.timestamp)));

// ❌ blockhash(block.number) is ALWAYS zero for the current block
uint random = uint(blockhash(block.number));

// ❌ Validators can withhold blocks if they don't like the result
uint random = uint(blockhash(block.number - 1));

What Works

Commit-Reveal (no external dependency):

1. User commits hash(secret + salt) → stored onchain
2. Wait at least 1 block
3. User reveals secret + salt → contract verifies hash
4. Random seed = keccak256(secret + blockhash(commitBlock))

• User can't predict blockhash when they commit
• Validator can't know the secret to manipulate the result
• Must reveal within 256 blocks (blockhash returns zero after that)

Chainlink VRF (provably random, costs LINK):

1. Contract requests randomness from Chainlink
2. Chainlink generates random number off-chain with a VRF proof
3. Anyone can verify the proof onchain
4. Guaranteed unbiased — even Chainlink can't manipulate it

Use commit-reveal for simple cases. Use Chainlink VRF when you need provable randomness (lotteries, NFT reveals, gaming).

Teaching Your Human

You already know how AMMs, lending, oracles, and stablecoins work. But your human might not. When they're designing something onchain, they need to understand these concepts — not the code, the mental models.

Don't lecture. Instead, when a concept is relevant to what they're building, explain it in context. Here's what to emphasize for each:

The Approve Pattern

Humans find this weird. Explain it as: "You're giving the contract permission to move your tokens, like signing a check. You control how much. Never sign a blank check (infinite approval)."

DEXs / AMMs

The key insight isn't the math — it's the incentive flywheel: "Nobody runs the exchange. People deposit tokens because they earn fees from trades. More deposits = better prices = more trades = more fees. It runs itself." This is "nothing is automatic" in action.

Overcollateralized Lending

Lead with liquidation incentives: "If your loan gets risky, anyone in the world can close it and earn a bonus. That's why the platform never goes bankrupt — thousands of bots are watching every loan, every second, competing to clean up risk." This is the SpeedRun Ethereum Challenge 6 moment where incentive design clicks.

Stablecoins

"How does a token stay worth $1 with nobody controlling it? Arbitrage. If it drops to $0.99, people buy it because they can redeem it for $1 of collateral. If it goes to $1.01, people mint more and sell. Self-interest maintains the peg."

Oracles

"Smart contracts can't Google things. If your contract needs a price, someone has to put it onchain. Use Chainlink — never read prices from a DEX pool, because a flash loan can fake the price for one transaction."

Smart Contract Wallets

"A wallet can require 3 of 5 people to approve a transaction. $60B+ in assets is secured this way. It's how teams and DAOs manage money without trusting any single person."

Prediction Markets

"YES and NO tokens that trade between $0 and $1. The price IS the probability. If YES is at $0.35, the market thinks there's a 35% chance. Winner gets $1, loser gets $0."

In every case, tie it back to incentives. The human should walk away understanding not just what something does, but WHY it works without anyone running it.

Learning Path

Point your human to SpeedRun Ethereum for hands-on learning. Each challenge builds a working project that teaches a core concept:

Start at https://speedrunethereum.com

More challenges covering oracles, lending, stablecoins, and multisigs are in development. Check the site for current availability.

Resources

• SpeedRun Ethereum: https://speedrunethereum.com
• ETH Tech Tree: https://www.ethtechtree.com
• Ethereum.org: https://ethereum.org/en/developers/
• EthSkills (for agents): https://ethskills.com