Nexth, a Next.js and Ethereum starter kit built as a monorepo

One repository, three packages, one toolchain to delete

Nexth is a starter kit rather than a library. The repository is a yarn workspaces monorepo, and the root package.json declares the workspace layout as packages/* with private set to true, meaning it is not published to a registry but meant to be cloned and edited.

The package list is short and deliberate. There is an app package described as Next.js 14 with the App router, a Hardhat package for Hardhat projects, and a Foundry package for Foundry projects. The stated intent is to choose the framework to use, hardhat or foundry, and eliminate the one that will not be used.

That first step is destructive by design. The instructions are to delete the folder of the framework you will not use, either ./packages/hardhat/ or ./packages/foundry/, and then go to packages/app/wagmi.config.ts and remove the plugin that will not be used. A starter kit that asks you to prune it is a statement about what the author considers the normal path, and it is worth noticing that the pruning is not scripted. Nothing in the documented steps rewrites the wagmi config for you.

The root package.json is minimal, with three scripts that fan out across workspaces:

  "scripts": {
    "dev": "yarn workspaces -pt run dev",
    "build": "yarn workspaces -pt run build",
    "test": "yarn workspaces -pt run test"
  }

The -pt flags are passed to yarn workspaces, so the root command dispatches the same task to every workspace package rather than to a single one.

wagmi.config.ts is where the app meets the contracts

The bridge between the frontend and the contract toolchain is a single file, packages/app/wagmi.config.ts, which registers one plugin per supported framework. Both entries carry a project path and a deployments map keyed by contract name and chain id.

hardhat({
    project: '../hardhat',
    deployments: {
    Message: {
        11155111: '0xcc5a0d6268d70811edad77799f2168afe6382e89',
    },
    },
}),

foundry({
    project: '../foundry',
    deployments: {
    Message: {
        11155111: '0xcc5a0d6268d70811edad77799f2168afe6382e89',
    },
    },
}),

The chain id 11155111 appears in both blocks, and the Message contract maps to the same address value in each. The practical lesson is that a fresh clone ships one address shared by both configurations, so the deployments block is where you record what you actually deployed.

Removing a plugin is the second half of that switch, and it is manual editing in the same file rather than a setting. Because the two plugin entries point at different project directories, deleting the unused package without deleting its plugin leaves a configuration that references a folder that no longer exists.

Starting the dev server and the workspace scripts

Development is started from the repository root. The documented command is:

npm run dev

or, with yarn:

yarn dev

Both run the root script that delegates to each workspace. The root also exposes build and test commands with the same parallel fan-out, so the app and the contract package are built and tested together rather than in isolation.

Deployment is handled by the Vercel Platform, the maker of Next.js, and the README describes it as the easiest way to deploy the Next.js app. A clone-and-deploy link for the repository is included, and the README points at the Next.js deployment documentation for details rather than reproducing them.

One structural detail deserves attention for anyone who clones rather than forks. The repository contains a .gitmodules file, which is the standard marker for git submodules, alongside .eslintrc.json, .prettierrc.json, .vscode/, CONTRIBUTORS.json, FUNDING.json and a yarn.lock. The presence of the submodule marker means some directories are pulled in as separate repositories, so a plain clone without submodule initialisation can leave the tree incomplete.

The repository also ships no GitHub releases, so version tracking depends on the commit history and the version field in package.json, which reads 0.2.0.

What the README leaves out of the first run

The documentation is short, and the gaps are visible. There is no section on environment variables: nothing in the project description names a variable for a wallet project id, an RPC endpoint, a contract address outside the deployments map, or a database. A reader who wants to run this locally and connect a wallet has to find those names by reading the app package source.

There is also no walkthrough of the contract side. The Hardhat and Foundry packages are named in the repository layout, and the wagmi config points at them, but the README does not describe a compilation step, a test suite for contracts, or how a local contract is meant to be deployed before the frontend can talk to it. The same gap applies to the frontend: no route is described, no authentication flow is explained beyond the fact that SIWE is part of the stack, and no Web3Modal project id is mentioned.

The test script exists at the root, but the README says nothing about what is tested or how to run a single suite, and there is no mention of a test environment file. For a kit whose whole purpose is to save setup time, these omissions are the real cost. You trade configuration work for code reading.

The funding arrangement is documented in unusual detail, by contrast. The project funds its core dependencies through the Drips protocol, and a split contract sends 60% of proceeds to core contributors and 40% to dependencies. For 2024 the README reports 7,075 USD received, of which 4,245 USD, being 60%, went to core contributors, with a transaction link on arbiscan for the split.

Hardhat versus Foundry, and the alternative of not using a starter

The framework choice is the one decision the kit pushes onto you, and the difference is concrete in the configuration. The hardhat plugin points at a directory named ../hardhat and the foundry plugin at ../foundry, and each carries the same deployments shape. Everything else in the two packages is invisible in the public documentation, so the choice is made on ecosystem preference rather than on documented capability.

The realistic alternative is to skip the starter and assemble the same stack yourself: a Next.js app with the App router, Viem for the chain interaction layer, Wagmi as the React binding over it, Web3Modal for the wallet connection modal, SIWE for the sign-in flow, Tailwind and daisyUI for styling, and one contract toolchain installed as a dependency. The difference in approach is where the effort lands. The starter gives you a working directory layout, a wagmi configuration wired to both toolchains, formatting and lint configuration, and a workspace layout, but it also gives you a repository to prune, a placeholder deployment address to replace, submodule directories to initialise, and no environment documentation. Building it by hand gives you exactly the files you want and none of the pruning work, at the cost of writing every wiring file yourself.

The other practical difference is that the starter is a snapshot. It was written against a specific combination of dependency versions, and when those move, you are the one resolving the mismatch.

MIT licensing, Drips funding, and a dated last push

The licence identifier is MIT and the package.json repeats it, so the template itself carries no copyleft condition. The README does not discuss any additional licensing terms for the bundled dependencies, and it says nothing about relicensing the template, so read the dependency licences yourself before shipping anything commercial.

The maintenance picture is thin. The repository is not archived, and the last push was on 2026-05-21. There are no GitHub releases to track, no changelog in the repository listing, and no stated release cadence. The version field in package.json reads 0.2.0, which suggests early stage work rather than a stable line.

The funding model does add a signal worth noting. Contributors are rewarded based on their contributions, and the score is calculated from a combination of commits, issues, pull requests and other contributions, using a tool called Contributor Graph that lives in the same account. That means the repository is part of an ecosystem rather than an abandoned template, and it also means maintenance attention is tied to a funding split rather than to a support commitment from any company.

Editorial conclusion

Nexth fits a team that wants the Next.js, Viem, Wagmi, Web3Modal and SIWE wiring already in place and is comfortable deleting half the repository before starting. It does not fit a team that needs documented environment variables, a described deployment flow or a maintained release train, because the README covers none of those and the last push was on 2026-05-21. Before adopting, check that wagmi.config.ts in packages/app matches the contract toolchain you keep, confirm the chain id and contract address you need are present in the deployments block, and read the app package for the environment variable names the README never lists.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. wslyvh/nexth on GitHub