Scaffold-ETH 2 wires a Hardhat chain and a NextJS app into one root script table

One workspace root fans every command into two packages

The wiring is the product. `yarn chain` starts a blockchain and `yarn start` boots a React front end, yet the two halves share nothing but a repository root, so most of the drudgery in a dapp project is the bridge between a compiled contract and a typed client. scaffold-eth/scaffold-eth-2 hands you that bridge as a Yarn workspace whose `workspaces` array names exactly two members.

  "workspaces": {
    "packages": [
      "packages/hardhat",
      "packages/nextjs"
    ]
  },

Two hops are the whole mechanism. The root package calls itself `se-2` and forwards every short name into a workspace call:

  "chain": "yarn hardhat:chain",
  "hardhat:chain": "yarn workspace @se-2/hardhat chain",

So `yarn chain` lands as `chain` inside `packages/hardhat`, and the same forwarding carries `yarn deploy` and `yarn start` into their own packages. Because the packages are named `se-2`, `@se-2/hardhat` and `@se-2/nextjs`, a fork can rename all three from a single file. Nothing in the design is clever beyond that indirection, and nothing needs to be clever for the daily loop to work.

Its own numbers do not agree with its own tags. The root version field reads `0.0.1`, the newest tag on record is v0.0.37 dated 2024-04-16, every published tag falls in March or April 2024, and the last push to the repository was on 2026-08-27. Pin a tag and you get a tree more than a year older than the branch head, and no script in the table records which commit you are standing on.

Three terminals, one local chain, one browser page

Three prerequisites come first: Node `v22.10.0` or newer, Yarn at v1 or v2+, and Git. After that the generator does the work.

npx create-eth@latest

That package name deserves a pause, because it is not the repository's own name. The project is called Scaffold-ETH 2 while the root `package.json` calls itself `se-2`, and what you install here is `create-eth@latest`. No step of that quickstart tells you to clone this repository or run an install inside it, which leaves the first chore of every fork unwritten.

The next three commands each want their own terminal.

yarn chain

starts a local Ethereum network on your machine for testing. In a second terminal:

yarn deploy

puts a test smart contract on that network. In a third:

yarn start

serves the NextJS app, and you open `http://localhost:3000`. The `Debug Contracts` page is where you actually call the contract from the browser, and app level settings live in `packages/nextjs/scaffold.config.ts`, the file named for tweaking configuration. A missing port 3000 listener means the third terminal never came up, not that the contract failed.

Hot reload is promised without a documented transport

The feature list states that the frontend auto-adapts to the smart contract as you edit it, and the mechanism behind that sentence is nowhere in the visible tree. No watcher script, no ABI sync command, no config key for it appears among the root entries, and the only place the contract and the interface visibly meet is the `Debug Contracts` page. Nothing else in the repository pictures that pairing.

What you can check yourself is narrower. React hooks that wrap wagmi with TypeScript autocompletion sit behind `docs.scaffoldeth.io/hooks/`, ready made web3 components behind `docs.scaffoldeth.io/components/`, and behaviour changes go into `packages/nextjs/scaffold.config.ts`. Type checking has its own commands, `next:check-types` and `hardhat:check-types`, while tests run through `hardhat:test` and builds through `next:build`.

So treat hot reload as a claim you verify once by editing a function and watching the interface change, rather than as an architecture you can read. The absence is the point: nothing in the repository tells you how the reload happens, which means a fork that breaks it has no file to start debugging from.

Foundry is named in the stack line and missing from the tree

NextJS, RainbowKit, Foundry/Hardhat, Wagmi, Viem, and Typescript is what the stack line claims. Only one of those two contract toolchains is actually implemented. The workspace members are `packages/hardhat` and `packages/nextjs`, every visible root script is prefixed `hardhat:` or `next:`, and no forge command, foundry configuration or third workspace sits at the top level. Foundry is an intention the shipped layout does not carry, so a team that wants forge inherits the front end and rebuilds the contract workspace by hand.

Topic tags tell the same story. They carry ethersjs next to viem, yet the stack line names viem and wagmi and the hooks wrap wagmi, which leaves ethersjs without a counterpart anywhere in the description. Those tags also carry daisyui and tailwindcss, styling tools the stack line never mentions, so the front end arrives with a Tailwind based component layer that the prose does not admit to.

Read the stack line as a wish list and the tree as the truth, and the difference is a day of work for anyone whose contract toolchain preference is not Hardhat.

The account scripts include a private key printer

Account handling is a first class part of the root table. `yarn hardhat:account` lists them, `account:generate` creates new local keys, `account:import` brings in keys you already hold, and the root `generate` script is a plain shortcut for `yarn account:generate`.

The entry to look at twice is `account:reveal-pk`, which the table forwards to `yarn workspace @se-2/hardhat account:reveal-pk`. Its name says it prints a private key, and no visible configuration restricts which chain that command reads from. The feature list frames a burner wallet and a local faucet as the fast path for testing, and in a project built around disposable local accounts a script named for revealing keys stops being harmless the moment the same configuration points at a network where balances are real. Check which network is configured before running it, every time.

That habit is the only guard, because there is no other one written down.

Forking a real network instead of an empty local chain

`yarn chain` gives you a blank local network where your contract is the only thing of interest on it. The root also maps `fork` to `yarn hardhat:fork`, and that is the other door: a forked node replays state from a real chain, so your contract meets balances, allowances and third party contracts that already exist. `account:import` is the companion step, since imported accounts are how a fork gets funded addresses to test with.

Verification carries two names for what looks like one job. `hardhat:verify` forwards to a workspace command called `verify`, while `hardhat:hardhat-verify` forwards to one called `hardhat-verify`. Same table, same package, two spellings, and nothing in the file says which one the extension scripts call.

A third route in runs through the generator instead. The README points at `docs.scaffoldeth.io/extensions/` and says a project can be initialised with an extension to add specific features or starter kits. The practical difference between that route and a plain fork is when you make your choices: an extension bakes them in at creation time, while a fork leaves them as edits you perform later.

Agent folders and hooks crowd the top level

The root carries configuration for four separate agent tools before it carries any Solidity: `.agents/`, `.claude/`, `.cursor/` and `.opencode/`, alongside `AGENTS.md`, `CLAUDE.md`, `.mcp.json` and `opencode.json`. The AI-ready note points at four of those, and it writes `.opencode` without the trailing slash that the other three keep, even though the directory in the root listing has one. A trivial inconsistency, and still a sign the note was typed by hand rather than generated from the tree.

Next to them sit `.husky/`, `.lintstagedrc.js`, `funding.json`, `yarn.lock`, `.yarn/`, `.yarnrc.yml`, `.github/` and `.gitignore`. The hooks pair with `hardhat:lint-staged` and with `format`, which runs `yarn next:format && yarn hardhat:format` across both packages. The contributing link in the README points at `CONTRIBUTING.MD` while the root listing has `CONTRIBUTING.md`, and the MIT licence ships as `LICENCE`, with the British spelling.

A team that only wants contracts has to delete four directories of agent configuration rather than ignore them, and the fork has to rename three spellings that disagree with each other.

Beyond localhost, the deploy path goes through documentation

Everything the quickstart builds stops at `http://localhost:3000`. `yarn deploy` deploys a test smart contract to the local network, and that is as far as the visible scripts go: the root table names no public network, no environment variable and no key variable, because a deployment target has to be supplied from outside this file. The pointer for that step is a documentation anchor about configuration of third-party services for production grade apps, plus a next-steps list that ends with setting up external services and API keys.

That is the honest cost of the fork. You get a working contract loop in minutes and inherit a table of forwarded commands whose targets you learn by reading the workspace packages yourself, plus a tree where the contract toolchain, the wallet scripts and the agent configuration all sit on the same level. Nobody documents the seam between them for you, and the README does not document a rollback path for a bad local deployment either.

Editorial conclusion

Scaffold-ETH 2 fits teams that want a contract and a typed front end talking to each other on day one, and it fits them badly when forge is a hard requirement, because only the Hardhat workspace ships. Verify three things before committing: run `npx create-eth@latest`, then `yarn chain`, `yarn deploy` and `yarn start` on Node v22.10.0; open `packages/nextjs/scaffold.config.ts` and check whether its defaults match your network; and look at which commit you actually start from, because the newest tag v0.0.37 is dated 2024-04-16.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. scaffold-eth/scaffold-eth-2 on GitHub