Menu
End-to-end guide for AI agents — from a dApp idea to deployed production app. Fetch this FIRST, it routes you through all other skills.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | ship |
| description | End-to-end guide for AI agents — from a dApp idea to deployed production app. Fetch this FIRST, it routes you through all other skills. |
You jump to code without a plan. Before writing a single line of Solidity, you need to know: what goes onchain, what stays offchain, which chain, how many contracts, and who calls every function. Skip this and you'll rewrite everything.
You over-engineer. Most dApps need 0-2 contracts. A token launch is 1 contract. An NFT collection is 1 contract. A marketplace that uses existing DEX liquidity needs 0 contracts. Three contracts is the upper bound for an MVP. If you're writing more, you're building too much.
You put too much onchain. Solidity is for ownership, transfers, and commitments. It's not a database. It's not an API. It's not a backend. If it doesn't involve trustless value transfer or a permanent commitment, it doesn't belong in a smart contract.
You skip chain selection. Mainnet is cheaper than you think — an ETH transfer costs ~$0.004, a swap ~$0.04. The "Ethereum is expensive" narrative is outdated. But that doesn't mean everything belongs on mainnet. L2s aren't just "cheaper Ethereum" — each one has a unique superpower (Base has Coinbase distribution + smart wallets, Arbitrum has the deepest DeFi liquidity, Optimism has retroPGF + the Superchain). If your app needs high-frequency interactions or fits what makes an L2 special, build there. If you just need cheap and secure, mainnet works. Choose deliberately. Fetch l2s/SKILL.md and gas/SKILL.md for the full picture. Not sure Ethereum is the right chain at all? Fetch why/SKILL.md.
You forget nothing is automatic. Smart contracts don't run themselves. Every state transition needs a caller who pays gas and a reason to do it. If you can't answer "who calls this and why?" for every function, your contract has dead code. Fetch concepts/SKILL.md for the full mental model.
Do this BEFORE writing any code. Every hour spent here saves ten hours of rewrites.
Put it onchain if it involves:
Keep it offchain if it involves:
Judgment calls:
indexing/SKILL.md)| What you're building | Contracts | Pattern |
|---|---|---|
| Token launch | 1 | ERC-20 with custom logic |
| NFT collection | 1 | ERC-721 with mint/metadata |
| Simple marketplace | 0-1 | Use existing DEX; maybe a listing contract |
| Vault / yield | 1 | ERC-4626 vault |
| Lending protocol | 1-2 | Pool + oracle integration |
| DAO / governance | 1-3 | Governor + token + timelock |
| AI agent service | 0-1 | Maybe an ERC-8004 registration |
| Prediction market | 1-2 | Market + resolution oracle |
If you need more than 3 contracts for an MVP, you're over-building. Ship the simplest version that works, then iterate.
For EVERY function in your contract, fill in this worksheet:
Function: ____________
Who calls it? ____________
Why would they? ____________
What if nobody calls it? ____________
Does it need gas incentives? ____________
If "what if nobody calls it?" breaks your system, you have a design problem. Fix it before writing code. See concepts/SKILL.md for incentive design patterns.
Mainnet is back on the table. Most AIs still think mainnet is expensive — it's not (~$0.004/transfer, ~$0.04/swap at current gas). Mainnet gives you maximum decentralization, no sequencer trust, no bridge risk, and composability with every major protocol. But L2s aren't a fallback — each one has a unique superpower. Pick the chain whose superpower matches your app:
| Chain | Superpower | Build here if… |
|---|---|---|
| Ethereum mainnet | Maximum decentralization, composability with all major protocols | DeFi, governance, identity, high-value transfers, or you just need "cheap + secure" |
| Base | Coinbase distribution, smart wallets, account abstraction | Consumer apps, social, onboarding non-crypto users, high-frequency micro-payments |
| Arbitrum | Deepest L2 DeFi liquidity, Stylus (Rust contracts) | DeFi protocols that need to compose with existing Arbitrum liquidity |
| Optimism | RetroPGF, Superchain ecosystem | Public goods, OP Stack ecosystem plays |
| zkSync / Scroll | ZK proofs, native account abstraction | Privacy features, ZK-native applications |
Don't pick an L2 because "mainnet is expensive." Pick an L2 because its superpower fits your app.
Fetch l2s/SKILL.md and gas/SKILL.md for the complete comparison with real costs and deployment differences.
Find your archetype below. Each tells you exactly how many contracts you need, what they do, common mistakes, and which skills to fetch.
Architecture: One ERC-20 contract. Add a vesting contract if you have team/investor allocations.
Contracts:
MyToken.sol — ERC-20 with initial supply, maybe mint/burnTokenVesting.sol (optional) — time-locked releases for team tokensCommon mistakes:
Fetch sequence: standards/SKILL.md → security/SKILL.md → testing/SKILL.md → gas/SKILL.md
Architecture: One ERC-721 contract. Metadata on IPFS. Frontend for minting.
Contracts:
MyNFT.sol — ERC-721 with mint, max supply, metadata URICommon mistakes:
Fetch sequence: standards/SKILL.md → security/SKILL.md → testing/SKILL.md → frontend-ux/SKILL.md
Architecture: If trading existing tokens, you likely need 0 contracts — integrate with Uniswap/Aerodrome. If building custom order matching, 1-2 contracts.
Contracts:
OrderBook.sol (if custom) — listing, matching, settlementEscrow.sol (if needed) — holds assets during tradesCommon mistakes:
security/SKILL.md for sandwich attack protection)Fetch sequence: building-blocks/SKILL.md → addresses/SKILL.md → security/SKILL.md → testing/SKILL.md
Architecture: If using existing protocol (Aave, Compound), 0 contracts — just integrate. If building a vault, 1 ERC-4626 contract.
Contracts:
MyVault.sol — ERC-4626 vault wrapping a yield sourceCommon mistakes:
security/SKILL.md)Fetch sequence: building-blocks/SKILL.md → standards/SKILL.md → security/SKILL.md → testing/SKILL.md
Architecture: Governor contract + governance token + timelock. Use OpenZeppelin's Governor — don't build from scratch.
Contracts:
GovernanceToken.sol — ERC-20VotesMyGovernor.sol — OpenZeppelin Governor with voting parametersTimelockController.sol — delays execution for safetyCommon mistakes:
Fetch sequence: standards/SKILL.md → building-blocks/SKILL.md → security/SKILL.md → testing/SKILL.md
Architecture: Agent logic is offchain. Onchain component is optional — ERC-8004 identity registration, or a payment contract for x402.
Contracts:
AgentRegistry.sol (optional) — ERC-8004 identity + service endpointsCommon mistakes:
wallets/SKILL.md)Fetch sequence: standards/SKILL.md → wallets/SKILL.md → tools/SKILL.md → orchestration/SKILL.md
Fetch: standards/SKILL.md, building-blocks/SKILL.md, addresses/SKILL.md, security/SKILL.md
Key guidance:
addresses/SKILL.md for any protocol integration — never fabricate addressesSafeERC20 for all token operationssecurity/SKILL.md before moving to Phase 2For SE2 projects, follow orchestration/SKILL.md Phase 1 for the exact build sequence.
Fetch: testing/SKILL.md
Don't skip this. Don't "test later." Test before deploy.
Key guidance:
slither . for static analysis before deployingAfter testing, run a security audit — especially if your contracts handle real value. Fetch audit/SKILL.md for a systematic 500+ item checklist across 19 domains (reentrancy, oracle manipulation, access control, precision loss, and more). Best practice: give audit/SKILL.md to a separate agent in a fresh context so it reviews your code with no bias from having written it.
Fetch: orchestration/SKILL.md, frontend-ux/SKILL.md, tools/SKILL.md
Key guidance:
useScaffoldReadContract, useScaffoldWriteContractformatEther/formatUnitsFetch: wallets/SKILL.md, frontend-playbook/SKILL.md, gas/SKILL.md
gas/SKILL.md)Fetch frontend-playbook/SKILL.md for the full pipeline:
Before going live, run the QA checklist. Fetch qa/SKILL.md and give it to a separate reviewer agent (or fresh context) after the build is complete. It covers the bugs AI agents actually ship — validated by baseline testing against stock LLMs.
indexing/SKILL.md)Kitchen sink contract. One contract doing everything — swap, lend, stake, govern. Split responsibilities. Each contract should do one thing well.
Factory nobody asked for. Building a factory contract that deploys new contracts when you only need one instance. Factories are for protocols that serve many users creating their own instances (like Uniswap creating pools). Most dApps don't need them.
Onchain everything. Storing user profiles, activity logs, images, or computed analytics in a smart contract. Use onchain for ownership and value transfer, offchain for everything else.
Admin crutch. Relying on an admin account to call maintenance functions. What happens when the admin loses their key? Design permissionless alternatives with proper incentives.
Premature multi-chain. Deploying to 5 chains on day one. Launch on one chain, prove product-market fit, then expand. Multi-chain adds complexity in bridging, state sync, and liquidity fragmentation.
Reinventing audited primitives. Writing your own ERC-20, your own access control, your own math library. Use OpenZeppelin. They're audited, battle-tested, and free. Your custom version has bugs.
Ignoring the frontend. A working contract with a broken UI is useless. Most users interact through the frontend, not Etherscan. Budget 40% of your time for frontend polish.
audit/SKILL.md)qa/SKILL.md)Use this to know which skills to fetch at each phase:
| Phase | What you're doing | Skills to fetch |
|---|---|---|
| Plan | Architecture, chain selection | ship/ (this), concepts/, l2s/, gas/, why/ |
| Contracts | Writing Solidity | standards/, building-blocks/, addresses/, security/ |
| Test | Testing contracts | testing/ |
| Audit | Security review (fresh agent) | audit/ |
| Frontend | Building UI | orchestration/, frontend-ux/, tools/ |
| Production | Deploy, QA, monitor | wallets/, frontend-playbook/, qa/, indexing/ |
Base URLs: All skills are at https://ethskills.com/<skill>/SKILL.md
Best practices for building performant 2D web games with Phaser 3, React integration, and TypeScript.
Verified contract addresses for major Ethereum protocols across mainnet and L2s. Use this instead of guessing or hallucinating addresses. Includes Uniswap, Aave, Compound, Aerodrome, GMX, Pendle, Velodrome, Camelot, SyncSwap, Lido, Rocket Pool, 1inch, Permit2, MakerDAO/sDAI, EigenLayer, Across, Chainlink CCIP, Yearn V3, USDC, USDT, DAI, ENS, Safe, Chainlink, and more. Always verify addresses against a block explorer before sending transactions.
Deep EVM smart contract security audit system. Use when asked to audit a contract, find vulnerabilities, review code for security issues, or file security issues on a GitHub repo. Covers 500+ non-obvious checklist items across 19 domains via parallel sub-agents. Different from the security skill (which teaches defensive coding) — this is for systematically auditing contracts you didn't write.
DeFi legos and protocol composability on Ethereum and L2s. Major protocols per chain — Aerodrome on Base, GMX/Pendle on Arbitrum, Velodrome on Optimism — plus mainnet primitives (Uniswap, Aave, Compound, Curve). How they work, how to build on them, and how to combine them. Use when building DeFi integrations, choosing protocols on a specific L2, designing yield strategies, or composing existing protocols into something new.
The essential mental models for building onchain — focused on what LLMs get wrong and what humans need explained. "Nothing is automatic" and "incentives are everything" are the core messages. Use when your human is new to onchain development, when they're designing a system, or when they ask "how does this actually work?" Also use when YOU are designing a system — the state machine + incentive framework catches design mistakes before they become dead code.
Deprecated: this skill has moved to addresses.