Solana Explorer: the block explorer as a protocol workbench

A block explorer that knows about protocols

The Solana Explorer is a web application that allows users to explore the Solana blockchain, and it provides a user-friendly interface to view transactions, accounts, blocks and other on-chain data.

What separates it from a generic chain explorer is the last part of that sentence. The Explorer supports various protocol integrations, allowing users to inspect and understand different types of transactions and instructions on the Solana network. A transaction on Solana is a bundle of instructions called to a program, and a raw decoder tells you that a program was called with four accounts and sixteen bytes of data. A protocol screen tells you what those four accounts were and what the sixteen bytes meant.

That is the difference between a database view and a workbench, and it is why the contributing guidelines single out protocol integrations when they ask for tests, and why the contributing guidelines ask for screenshots specifically for protocol screens. Those are the pages that break in ways a general block list does not, because they depend on an interface definition that the program can change underneath them.

The project is TypeScript, MIT licensed, with the default branch on master, the site at explorer.solana.com, and the last push on 2026-10-20. There are no GitHub releases, and the package manifest marks the application as private at version 0.1.0, so this is a repository you run yourself rather than a package you install.

Contributing means tests, CI and a screenshot

The contributing section is short and specific, and it tells you what the maintainers consider the hard parts of this codebase.

Before submitting a pull request you should read the CONTRIBUTING.md guide, ensure your code includes appropriate tests, especially for protocol integrations, make sure the pull request passes all the CI checks before requesting a review, and include screenshots for any user interface changes, particularly for protocol screens.

Three of those four are about verification rather than about code. The tests matter most for protocol integrations, because that is where the behaviour depends on data the Explorer does not control. The CI check is a precondition for review, which is a reasonable way to keep the review queue clean. The screenshots for protocol screens are a hint about what reviewers need to see, since a change to a decoder is hard to judge from a diff and easy to judge from a picture of the new screen.

The issue guidance is equally concrete. Use GitHub issues for non-security bugs, and include clear steps to reproduce, expected versus actual behaviour, and relevant screenshots. For security vulnerabilities, especially those related to Solana Verify and Verified Builds, the route is an email to a disclosure address rather than a public issue, which is the correct handling for a defect in the trust machinery of a chain.

The disclaimer says more than the usual disclaimer

Most project READMEs carry a disclaimer. This one is long, and the reason is worth understanding rather than skipping.

The first part is the familiar part. All claims, content, designs, algorithms, estimates, roadmaps, specifications and performance measurements described in the project are done with the Solana Foundation's best efforts, it is up to the reader to check and validate their accuracy and truthfulness, and nothing in the project constitutes a solicitation for investment. Content produced by the Foundation or the developer resources it provides is for educational and inspiration purposes only, and the Foundation does not encourage, induce or sanction the deployment, integration or use of such applications in violation of applicable laws and regulations.

Then the export control paragraph, which is the part that is unusual. It spells out that United States export control and sanctions laws prohibit United States persons, and other persons subject to those laws, from transacting with persons in certain countries and territories or on the sanctions list. It then concedes the awkward part directly: as a project based primarily on open source software, it is possible that such sanctioned persons may nevertheless bypass the prohibitions, obtain the code comprising the Solana blockchain protocol and deploy, integrate or otherwise use it, and that there is therefore a risk to individuals and organisations that other people using the protocol may be sanctioned persons, and that transacting with them would violate the law.

It then says where that risk lands. It applies to individuals, organisations and ecosystem participants that deploy, integrate or use the protocol code directly, for example as a node operator, and to people who transact on the blockchain through light clients, third party interfaces and wallet software.

The reason this is in a block explorer README is that the Explorer is a third party interface. A reader who uses it is transacting, in the sense the paragraph means, and the project is being explicit that it cannot prevent that and is not asking you to.

The environment file documents the product

The .env.example file is the most informative document in the repository, because every entry in it is a decision about how the Explorer behaves.

It starts with the RPC endpoints, with separate variables for mainnet, devnet and testnet, and the comment says to fill them out with a custom RPC URL to test the explorer locally without getting rate-limited. That single line tells you how the application is developed: against a paid or self-hosted node, not against the public endpoint, because a public endpoint is shared and will throttle you.

Then the whitelist for custom endpoints, which is the most interesting mechanism in the file. The variable is a comma-separated list of hostnames that a customUrl= link may point at without asking the user to approve it, the rules are bare lowercase hostnames only with no scheme, port, path or wildcard, invalid entries are skipped with a warning, an empty list means every remote endpoint from a link needs the user's consent, and the value is exposed to the client. So the Explorer can be pointed at an arbitrary RPC through a URL parameter, and the whitelist is the only thing standing between a link and a browser being sent somewhere the operator did not sanction. An empty whitelist means consent is requested every time, which is the safe default and the one that will annoy people who want short links to work.

The rest of the file covers the smaller features. NEXT_LOG_LEVEL runs from zero for panic to four for debug, and all logging is suppressed when the variable is not set at all. There is a configuration block for a metadata service with an enable flag, a timeout and a maximum content size, a user agent string, and a separate URL for an IBRL block explorer. The interactive IDL feature has its own switch, and there is a list of bad tokens for the search bar, plus a variable to disable token search altogether. For search engines, SEO_DISALLOW_BOTS makes a staging build serve a Disallow robots.txt, return 404 for sitemaps and send a noindex header on every page. And there is bot protection with a BotId toggle and a challenge mode that returns a status code for detected bots, where the default is to log only.

Next.js, pnpm workspaces, Storybook, Playwright and Sentry

The package manifest describes the toolchain, and it is a large application assembled from familiar parts.

The framework is Next.js, with the build script running the workspace packages first and then next build, the dev script doing the same before next dev, and next start to serve. The workspace is pnpm based, with pnpm-workspace.yaml and a packages/ directory whose members are built by a recursive filter.

The testing story has three layers. Vitest runs the unit tests, with a coverage variant and a related-to-changed-files variant that is what you want in a large monorepo, and the CI script runs the package tests and the spec tests separately. Playwright provides the end to end tests, with a playwright.config.ts at the root, and the spec test setup lives in two files, test-setup.ts and test-setup.specs.ts. Storybook is there for the component work, with two scripts, one to build and one to serve, and the design variant running on a different port with its own configuration directory.

Monitoring and error reporting go through Sentry, with separate configuration files for the server and the edge, and there is an observability/ directory alongside them. There is also a react-scan integration, wired to a script that starts the dev server and points the scanner at localhost.

The developer tooling is thorough. Formatting is Prettier with its own configuration, and there is a separate Markdown formatting target for the documentation under the MCP directory. Linting is ESLint with a flat configuration at the root and a per-package lint, and there is a separate markdownlint-cli2 configuration file with its own script. Component scaffolding uses shadcn, with a components.json at the root and a gen script that shells out to the shadcn CLI, and the tailwind configuration sits alongside a postcss configuration.

Two scripts are worth a second look. The check script is the one a contributor runs: it formats, lints, validates the specifications, builds and then runs the tests, in that order. And openspec:validate runs the openspec validator over everything in strict mode without interaction, which means the project keeps its specifications in a machine-checkable form, and a change that does not match the specification fails before a human reads it.

The repository layout, and the parts worth opening first

The top-level listing is long, and several entries are unusual enough to be worth pointing out.

The application lives in app/, the shared packages in packages/, and there is a bench/ directory and a cache/ directory beside them, which suggests the project cares about both the performance of the queries and the caching of them. There is a config/ directory, a docs/ directory, a scripts/ directory with build tooling in it, and a patches/ directory for changes applied to dependencies.

Three entries are for automation with coding assistants. There is an .agents/ directory, a .claude/ directory and an AGENTS.md at the root, alongside a .githooks/ directory for git hooks and a .github/ directory for the workflows. A blockchain explorer that renders a lot of protocol-specific screens is a codebase where an assistant that knows the conventions can be genuinely useful, so shipping the conventions in the repository makes sense.

There is also an openspec/ directory, which is where the specifications live, and the validate script that checks them. And there is a proxy.ts, which in a Next.js application is the middleware layer, the place where requests are intercepted before they are handled, which is where a rate limit or a bot check would live. There are two instrumentation files, one for the client and one for the server, and an empty.ts at the root, which is a small trick to make the file system root importable in a way that works in every environment.

The release process is worth noting too. There is no version published anywhere, the package is private, and the audit scripts run pnpm audit at three different levels, high for the general audit, critical for the production-only CI audit and high for a separate production audit. Given that the application talks to a blockchain and renders content from arbitrary programs, having the dependency audit on the production path with a stricter level than the development one is a sensible arrangement.

Editorial conclusion

Adopt the Solana Explorer codebase if you are building a protocol-specific explorer or a decoder for a Solana program, because the per-protocol screens and the interactive IDL feature show how a general block explorer is extended into something specific to a program. Do not fork it expecting a supported public deployment, because the package is private, marked at version 0.1.0, and the repository publishes no releases, so you own the deployment and the operational work that comes with it. Before you run it, fill in the RPC endpoints in the environment file, because an unset endpoint is how the application rate-limits you out of testing it, and read the whitelist rules for custom RPC links, since every host you allow is a host a link can send a visitor's browser to.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. solana-foundation/explorer on GitHub