# starknet-ecosystem.com: a community directory rebuilt as a Next.js dashboard

> The Starknet Ecosystem site is an entry point into the Starknet ecosystem, a directory of more than three hundred projects with live metrics, grants, tokens, learning resources and jobs, rebuilt in version 2 on Next.js 16 with Chakra UI, TypeScript and Vercel. The interesting parts are the data plumbing, which pulls from several external APIs, and the contribution model, where a large part of the content arrives as pull requests from the community itself.

**419Labs/starknet-ecosystem.com** — Starknet Ecosystem Dashboard

- Repository: https://github.com/419Labs/starknet-ecosystem.com
- Website: https://www.starknet-ecosystem.com
- Stars: 563 · Forks: 491
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/419labs-starknet-ecosystem-com

## What the site is

The site describes itself as your entrypoint into Starknet, a place to explore 300 or more projects, live metrics, grants, jobs, learning resources, and everything building on Starknet.

That framing is the key to the project. It is not a protocol website and not a product of StarkWare or the Starknet Foundation. It is a directory, and the directory is assembled and maintained by the community rather than by a central editorial team.

The version 2 rewrite is described as a complete rebuild with a new bold design system, improved navigation, and new sections. The six new sections are the substance of the rebuild.

Projects lets you browse and filter the 300 or more ecosystem projects with live data from starknet-db.com. Metrics covers TVL, DEX volume, staking statistics and validator data, powered by DefiLlama, Endur and avnu. Grants covers Starknet Foundation seed and growth grants, Propulsion, X-Founders and more. Tokens provides live token data via the avnu API with CoinGecko and Voyager links. Academy offers curated learning paths, SDKs, tooling and community resources. And Jobs aggregates job boards from the Starknet Foundation, StarkWare and the wider ecosystem.

Note the pattern in the data sources. Three separate providers for metrics, one for token data, one database for the project list, and a set of external job boards. A directory that shows live numbers is a different kind of project from one that shows a static list, and the difference is where most of the engineering effort goes.

The primary language is TypeScript, the licence is Apache-2.0, the default branch is main, and the homepage is starknet-ecosystem.com. The last push was on 2026-09-01 with the project not archived, and the repository publishes no GitHub releases, so the version lives in the package manifest rather than in tags.

The footer credit is a nice detail: built with craft by avnu and the Starknet community.

## The tech stack, and the version numbers in it

The stack line is compact and worth reading closely: Next.js 16, React 18, Chakra UI v2, TypeScript, Vercel.

Next.js at 16 is the current major, and the manifest pins next at 16.1.6. React is at 18.3.1, which is notable because Next 16 does not require React 19, and pinning React 18 with Chakra UI v2 is a deliberate constraint rather than an oversight.

Chakra UI is the reason. The manifest has @chakra-ui/react at 2.8.2, @chakra-ui/layout at 2.3.1 and @chakra-ui/color-mode at 2.2.0, and Chakra v2 is built on Emotion, which is why the manifest also carries @emotion/react at 11.14.0, @emotion/styled, @emotion/cache and @emotion/server. That last one, the Emotion server package, is what makes Chakra work with server components.

So the version combination reads as: a current Next.js on a slightly older React, with a component library that has not been ported to the newest React. That is a common and defensible position. Chakra v2 is mature, its documentation is extensive, and moving a large site to Chakra v3 and React 19 is a large diff for a visual system that already works.

Two other entries in the dependency list are worth noting. framer-motion at about 12.23.25 is the animation library, which is consistent with the new design system and the bold visual direction mentioned in the rebuild notes. And swr at about 2.4.0 is the data fetching library, which is the mechanism for the live data described above.

Then there is a set of smaller choices. FontAwesome for icons, dayjs for dates, nprogress for the route progress bar, geist for fonts, and the two Vercel packages, @vercel/analytics and @vercel/speed-insights, which wire up usage and performance telemetry for a site that is a static Next.js application with some dynamic data on top.

The dev dependencies are equally telling: eslint at 9 with the next, react and react-hooks plugins, @tailwindcss/postcss at 4.1.18 with a postcss.config.js at the root, jest with jest-environment-jsdom at 30.2.0 and a jest.config.js and jest.setup.js, and knip for dead code detection.

## Development, and the scripts that make it work

The development section is five commands:

```bash
yarn install
yarn dev        # localhost:3000
yarn build      # production build
yarn lint       # eslint
yarn test:ci    # jest
yarn knip       # dead code detection
```

The set of commands is a decent summary of what the project expects of a contributor. Install with yarn, run the dev server on localhost:3000, build for production, lint with eslint, run the test suite under jest in CI mode, and run knip for dead code detection.

knip is the one that stands out. Dead code detection is a check that finds exports, files, dependencies and types that nothing uses. For a large site with a long history of contributors, that is a genuinely useful guard, because unused code tends to accumulate and it makes the codebase harder to navigate. Running it as a named script alongside lint and test tells you the project treats it as part of the definition of done.

The package manifest expands on the README with the full script list:

```json
    "build": "next build",
    "postbuild": "next-sitemap",
    "start": "next start",
    "lint": "eslint data src",
    "test": "jest --watch",
    "test:ci": "jest --ci",
    "knip": "knip"
```

Two of those are worth reading. The build script is next build with a postbuild of next-sitemap, so the sitemap is generated after the build rather than being hand-maintained. And the lint script is eslint data src, which lints two directories specifically. The presence of a data directory in the lint target implies the same thing the directory listing shows: a data/ folder that is part of the repository and can contain lint errors, so it is linted alongside the source.

The test script is jest --watch and test:ci is jest --ci, the usual split between a local loop and a one-shot run. The jest-environment-jsdom dependency at 30.2.0 confirms the tests are DOM tests, which for a component-heavy site is what you would expect.

The site is deployed to Vercel, and the README carries a Vercel Deployment badge pointing at the production deployment status, so the deployment is part of the visible project state rather than a private operational detail.

## The contribution model, and where the content comes from

The Contribute section is short and it is the most distinctive thing about the project.

Every contribution is welcome, and then there are five links, each pointing at a document in the docs/ directory: list a project, update a project, list a job, update a job, and add or improve translations.

That is five separate documented workflows, and they are workflows for non-developers as much as for developers. A project that wants to be listed in the ecosystem does not need to write code; it needs to open a pull request that adds an entry. A job gets listed the same way. And translations are contributed the same way.

The consequence is that the repository is not just a Next.js application, it is also a content pipeline, and the data/ directory at the root is where the content lives. The docs/ directory holds the instructions for adding to it, and the eslint script targets data as well as src, so the data files are linted with the same rules as the code.

The jobs section is the clearest case, because it aggregates job boards from the Starknet Foundation, StarkWare and the ecosystem rather than hosting listings itself. An aggregated board needs submissions from each source, and a documented pull request workflow is how those get in. The same reasoning applies to the grants section, which covers Foundation seed and growth grants plus programmes like Propulsion and X-Founders.

The translations workflow is worth calling out separately, because it is a design decision rather than a chore. A directory of three hundred projects, a set of metrics, a grants section, learning resources and a jobs board has a lot of text, and a community that speaks more than one language would otherwise have every page partly in English. Making translations a first-class contribution path is how that gets fixed.

The project also coordinates through Telegram, at the Starknet ecosystem channel, for pull request coordination and ecosystem updates, which is the right place to ask before opening a large change.

## The repository layout, and the data directory

The top-level listing shows a site that is more than a set of pages.

There is src/ for the application code, public/ for static assets, and data/ for the content. Then the configuration: next.config.js, postcss.config.js, eslint.config.mjs, jest.config.js, jest.setup.js, tsconfig.json, next-sitemap.config.js, next-env.d.ts and global.d.ts, which is the conventional place for ambient type declarations in a TypeScript project.

The .npmrc file at the root is worth a note. It is used to configure npm's behaviour for this project, and in a Yarn project it usually pins or configures the package manager settings so that installs are reproducible.

Then there are hive.json and CLAUDE.md. hive.json is not a JavaScript build artefact name, so it is configuration for something called hive, and without more context it is not possible to say what it drives. CLAUDE.md is the same kind of file that appeared in several other repositories in this queue, an instruction file for coding assistants, which tells you the project expects to be worked on with automated tooling.

The yarn.lock at the root and the use of yarn in the README commands, together with an .npmrc rather than a .yarnrc, is a mildly unusual mix. It is not a problem, but it does suggest the repository was set up with npm at some point and moved to Yarn, and the two managers' configuration files are both still present.

There is a .github/ directory for workflows and issue templates, a docs/ directory holding the contribution guides, and a LICENSE file. The gitignore is there too, which for a project with a data directory is where you would exclude generated files.

The overall shape is familiar: a Next.js app with its content in version control, its configuration split into focused files, and no build tooling beyond the framework itself.

## How to evaluate it, and what to check first

There are four things to decide, and the first is the most important one for anyone thinking about contributing.

Is your interest in code or in content? This repository supports both, and the content path is the one that helps the project most. A directory of three hundred projects is only useful if it is complete and current, and the projects it lists are mostly built by small teams who will never have time to write a pull request. The docs/add-project.md and docs/add-job.md workflows exist so that a project owner can add themselves in ten minutes, and the fastest way to make this site better is to use them.

Second, the live data. The metrics, tokens and project listings all come from external APIs, and those APIs have their own rate limits, uptime and schema changes. The last push was on 2026-09-01, so a broken upstream is a possibility worth checking before you debug your own code. If you are evaluating the site as a consumer, the practical question is whether the numbers are fresh, and if you are contributing, it is whether there is a graceful fallback when an API is down.

Third, the React and Chakra version constraint. React 18 with Chakra UI v2 on Next.js 16 is a workable combination, but it is a combination that will need attention. Chakra v3 exists and moves to a different styling model, and React 19 is the direction Next is heading. If you are contributing a component, you should be aware that the design system is on v2 and that a migration is a project in itself rather than an incremental change.

Fourth, the tooling expectations. Lint, jest and knip are all wired up, and the eslint config is a flat config at eslint.config.mjs, which is the modern format. A pull request that adds an unused export will be caught by knip, and a project that has been worked on with automated tooling is a project where a CLAUDE.md file is expected to be respected.

What you get in exchange is a well-organised, current Next.js site with a real community process behind it, a design system that was just rebuilt, and a scope that is genuinely useful rather than decorative. For a Starknet developer looking for what to build on, or for a team looking for where to contribute, it is a reasonable place to start.

## Conclusion

Adopt the starknet-ecosystem.com codebase if you are building a Starknet application and want to see how a large, community-maintained directory is put together, with a rebuilt design system, live data from several external APIs, and a real content contribution pipeline. Do not contribute expecting the projects listing to be a marketing channel, because the site is explicitly a directory maintained through documented pull request workflows, and be aware that the metrics and token sections depend on third-party APIs whose uptime and schemas are outside the project's control. Before you commit, read the docs/add-project.md and docs/add-job.md guides to see the contribution format, check that knip and the eslint configuration pass on your change since unused exports are caught, and if you are planning a component, note that Chakra UI v2 with React 18 is the current stack rather than the v3 and React 19 combination, so a design system migration would be its own piece of work.

## FAQ

### What is starknet-ecosystem.com?

It is a community directory described as the entrypoint into Starknet, covering more than 300 projects with live data, plus metrics, grants, tokens, learning resources and jobs. Version 2 is a complete rebuild with a new design system and improved navigation, and the site is built by avnu and the Starknet community under Apache 2.0.

### What tech stack does the Starknet ecosystem site use?

Next.js 16, React 18, Chakra UI v2, TypeScript and Vercel. The manifest pins next at 16.1.6, react and react-dom at 18.3.1, @chakra-ui/react at 2.8.2, framer-motion at about 12.23.25, swr at about 2.4.0, and @vercel/analytics and @vercel/speed-insights for telemetry.

### Where does the live data on the site come from?

Different sections use different providers. Projects and their live data come from starknet-db.com, metrics for TVL, DEX volume, staking and validator data are powered by DefiLlama, Endur and avnu, and token data comes via the avnu API with CoinGecko and Voyager links.

### How do I add a project or a job to the ecosystem directory?

Through the contribution workflows documented in the repository. There are separate guides for listing a project, updating a project, listing a job, updating a job and adding or improving translations, each opened as a pull request. Coordination happens in the project's Telegram channel.

### How do I run the site locally?

Run yarn install, then yarn dev for a dev server on localhost:3000. The other commands are yarn build for a production build, yarn lint for eslint, yarn test:ci for jest and yarn knip for dead code detection. The build script also runs next-sitemap as a postbuild step.

## Sources

- [419Labs/starknet-ecosystem.com on GitHub](https://github.com/419Labs/starknet-ecosystem.com)
- [Issues](https://github.com/419Labs/starknet-ecosystem.com/issues)
- [License: Apache-2.0](https://github.com/419Labs/starknet-ecosystem.com/blob/main/LICENSE)
- [Project website](https://www.starknet-ecosystem.com)
- [README](https://github.com/419Labs/starknet-ecosystem.com/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/419labs-starknet-ecosystem-com
