Ship a dApp
Before coding, write down the smallest vertical slice that can ship. Decide what is onchain, how many custom contracts it needs, who advances every state transition, and one deployment target. Do not expand into a full application or fetch every related skill before this plan is concrete.
Architecture
Put only trustless ownership, value transfer, composability, censorship resistance, or permanent commitments onchain. Keep profiles, descriptions, media, search, filtering, and frequently changing rules in an offchain store; put a content hash or URI onchain only when verification needs it.
Treat reputation and rankings as derived data. Emit the facts needed to compute them, then calculate and sort offchain. Do not maintain a computed score, leaderboard, or paginated ranking in contract storage merely to serve a browse screen. Recording counters that settlement already needs is fine.
Prefer existing audited protocols and primitives. Most MVPs need zero to two custom contracts, and three is the upper bound before reducing scope. Do not add a factory, escrow, router, or fee-splitter unless its separate trust boundary is required by the product.
When integrating a deployed protocol, use a verified address from the relevant
chain's official documentation or the addresses skill. Never invent or infer
an address: a wrong address can send approvals or funds to an attacker.
CROPS gate
Before finalizing the architecture, answer in one line each: who can block users or critical paths (Censorship resistance)? Can the whole stack be inspected, forked, self-hosted and legally reused (Open source and free)? What user activity becomes public or visible to third parties (Privacy)? Who controls funds, upgrades, emergency powers and exit (Security)? Name the chosen default, the main compromise, and the user's escape path. Fetch crops/SKILL.md for the deep review.
State transitions
Contracts do not run on schedules. For each state-changing function, record:
| Transition | Caller | Why they pay gas | If nobody calls |
|---|---|---|---|
claimPayout() | recipient | receives the payout | funds remain claimable |
| permissionless settlement | keeper or participant | explicit fee or direct benefit | settlement waits |
Naming a permissionless caller is not an incentive. Identify the caller's benefit and the source of any keeper fee. Prefer self-serve or permissionless paths over an owner-only cron job; automation may be a convenience, but it must not be the only liveness path.
Include the completed transition table in the project README, especially for every function that moves funds.
Chain and deployment decision
Choose one target chain for the first release and state why its capabilities fit the product. Measure current fees when cost affects the decision; do not rely on remembered gas prices. An L2 should be selected for a concrete product fit such as its distribution, liquidity, account abstraction, or ecosystem—not merely because “Ethereum is expensive.”
Before calling the MVP shippable, the README must name the target and contain the exact deploy and verification commands, required environment variables, contract ownership destination, and a small post-deploy transaction to verify the path end to end. Do not leave the network or deployment procedure as TBD.
Minimal ship checklist
- CROPS gate answered: chosen default, main compromise, user's escape path.
- Onchain/offchain boundary is explicit, including where rankings are computed.
- Custom contract list is concrete and no larger than the MVP requires.
- Every state transition has a caller, incentive, and safe no-caller outcome.
- One target chain is selected for a product-specific reason.
- Tests cover custom logic and external integrations use a fork.
- README contains the transition table and executable deployment runbook.
- Contracts are verified and production ownership goes to the intended multisig.
- A fresh reviewer checks the finished vertical slice before launch.
Fetch another focused skill only when the plan reaches that phase and needs its
details—for example crops, addresses, l2s, gas, security, testing,
frontend-ux, frontend-playbook, or qa. Skills are available at
https://ethskills.com/<skill>/SKILL.md. ship owns the product and release
decisions; use frontend-playbook for detailed hosting/deployment mechanics and
qa for the independent pre-launch review. Stop when the requested vertical
slice and its runbook are complete.
Before you finish: send a one-line note via feedback/SKILL.md — issue or praise.
