The State of Solidity Language Servers in 2026

Solidity tooling has come a long way. Foundry replaced Hardhat as the default build system. Solc ships monthly. But language servers — the thing you interact with every time you hit "go to definition" — have barely kept up.

We benchmarked every major Solidity language server against Uniswap v4-core, one of the most widely deployed Solidity codebases. The results are not close.

The contenders

Five Solidity language servers exist today:

Of these five, only two are actively maintained: solidity-language-server and Nomic Foundation. Juan Blanco's extension hasn't been updated in five months with 152 open issues. qiuxiang's server hasn't seen a commit in over two years. The solc LSP is inactive — the Solidity team has stopped development on it entirely.

Most Solidity developers still use either the Nomic Foundation server (bundled with the Hardhat VS Code extension) or Juan Blanco's extension. These are the defaults. They've been around the longest and have the most installs.

One server that should be on this list — solc --lsp, the official LSP built into the Solidity compiler — is no longer a real option. The Solidity team has called it "effectively abandoned experimental functionality" with no plans to revive it. It ships with documented internal compiler errors during normal editor operations like rename and semantic tokens. Development stopped before the LSP reached stability.

This matters. The official compiler team decided that language server support is not their problem. That leaves the ecosystem dependent on third-party servers — which makes the quality of those servers a critical infrastructure question.

The question is whether "most installed" still means "best."

The benchmark

We used lsp-bench, an open-source tool that sends real LSP requests over JSON-RPC stdio and measures latency, correctness, and memory. No mocks, no synthetic files. Real requests against real projects.

Target project: Uniswap v4-core — src/libraries/Pool.sol (line 102, col 15)

Setup: 10 iterations, 2 warmup, 10-second timeout per request, 15-second index timeout.

Every server was given the same file, the same cursor position, the same machine. Either you respond in time, or you don't.

Results

Initialization

How long does it take to start the server and be ready to handle requests?

All servers initialize. But the gap is already 200x between fastest and slowest. When you open a file, you either get instant code intelligence or you wait almost a full second.

Go to definition

The most common LSP operation. Click a symbol, jump to where it's defined.

One server returned a result. Four did not.

Go to declaration

Hover

Show type information and documentation for the symbol under the cursor.

Find all references

Find every usage of a symbol across the entire workspace, including dependencies.

Document symbols

List all contracts, functions, events, and variables in a file.

Diagnostics

Compilation errors and warnings.

Solc wins diagnostics — it is the compiler. solidity-language-server delegates to solc for diagnostics so the overhead is the LSP layer. Both produce results. The other three do not.

Document links

Clickable import paths and type references.

Scorecard

Memory

solidity-language-server uses 39.7 MB while supporting 26 LSP methods. Nomic Foundation uses 513 MB and timed out on 7 of 8 benchmarks.

Why the others fail on v4-core

Uniswap v4-core is not a toy project. It has deep import graphs, transient storage, custom types, and hundreds of cross-file references. Most Solidity language servers were built for small projects — a few contracts, a flat directory.

When you scale to a real codebase:

• Nomic Foundation re-analyzes the full project on every request. At v4-core scale, this exceeds any reasonable timeout.
• Juan Blanco crashes during the diagnostic phase. It never reaches the navigation features.
• qiuxiang initializes quickly but cannot complete any navigation request within 10 seconds.
• solc --lsp returns results for diagnostics but leaves most LSP methods unimplemented or empty. The Solidity team has officially abandoned the LSP, calling it "effectively abandoned experimental functionality." It also has documented internal compiler errors during normal operations like rename and semantic tokens. It will not improve.

These aren't edge cases. v4-core is the kind of project that Solidity developers actually work on.

What solidity-language-server does differently

Written in Rust. Parsing, indexing, and navigation are all native. No JavaScript runtime, no garbage collection pauses.

Two-phase indexing. Phase 1 compiles the src-closure for immediate code intelligence. Phase 2 compiles the full closure (src + test + script) in the background. You get results before the full index is built.

Parallel sub-cache compilation. Library sub-projects build concurrently. On a real project with 1000+ library files, indexing completes in seconds, not minutes.

Stable cross-build file IDs. A custom PathInterner assigns deterministic file IDs so references resolve correctly across compilation boundaries. This is what makes cross-dependency "Find All References" work — every file in dependencies/, src/, test/, and script/ is in the same ID space.

Interface/implementation equivalence. "Find All References" on PoolManager.swap returns call sites that reference IPoolManager.swap, and vice versa. This is how references should work in Solidity, but most servers don't do it.

Beyond navigation

solidity-language-server implements 26 LSP methods — more than any other Solidity language server:

• Go to definition, declaration, implementation
• Find all references (cross-dependency, interface-aware)
• Call hierarchy (incoming and outgoing)
• Hover with NatSpec, selectors, and @inheritdoc resolution
• Completions (scope-aware, import path completions)
• Rename (project-wide, qualifier-aware)
• Diagnostics (solc + forge lint)
• Code actions (unused-import quickfix)
• Inlay hints, semantic tokens, signature help
• File operations (scaffold on create, update imports on rename/delete)
• Formatting via forge fmt

AI agent support

Language servers aren't just for editors anymore. AI coding agents — Claude Code, OpenCode, Codex — benefit from the same code intelligence.

When an AI agent can call findReferences and get 506 semantic results in 5ms instead of running grep and getting 587 noisy text matches, it writes better code. The language server becomes the agent's understanding of the codebase.

See it in action

A full video tour of every feature is on X/Twitter: @solidity_lsp feature thread

The thread walks through 16 features with short recordings:

1. Go to Definition — jump to any symbol across files
2. Go to Declaration — navigate to the declaration site
3. Go to Implementation — jump from interface to concrete implementation
4. Find All References — every usage across the workspace, including dependencies
5. Hover — type signatures, NatSpec docs, function selectors
6. Completions — scope-aware suggestions and import path completions
7. Signature Help — parameter info on function calls and events
8. Diagnostics — solc errors and forge lint warnings inline
9. Rename — project-wide rename for variables, functions, contracts, aliases, and user-defined types
10. Document Symbols — nested hierarchy in the editor outline view
11. Formatting — format on save via forge fmt
12. Inlay Hints — named parameters at call sites and on events
13. Code Actions — quick fixes like removing unused imports
14. Will Create Files — templates for .sol, .t.sol, and .s.sol files
15. Will Rename Files — automatic import path updates on file rename
16. Incoming & Outgoing Calls — trace the full call graph in both directions

Every feature shown works at sub-15ms latency on production codebases.

Install

cargo install solidity-language-server

Or use the install script:

curl -fsSL https://raw.githubusercontent.com/mmsaki/solidity-language-server/main/install.sh | sh

Editor setup: Neovim | VS Code | Helix | Zed | Vim | Emacs

Reproduce the benchmarks

All benchmarks are reproducible. Clone lsp-bench, install the servers, and run:

lsp-bench -c benchmarks/v4-core/config.yaml -s benchmarks/v4-core/servers.yaml

Full results: lsp-bench/benchmarks/v4-core

Conclusion

The Solidity language server ecosystem in 2026 has a clear performance leader. The official compiler LSP is abandoned. The most popular third-party servers time out or crash on real codebases. solidity-language-server is the only one that handles production-scale Solidity projects with sub-15ms latency across the full LSP feature set.

Preventative security infrastructure shouldn't depend on abandoned upstream projects or servers that can't index your code. The benchmarks are open. The tool is open. Try it on your codebase and see for yourself.

You can contribute to the project via the Giveth Ethereum security fund.

Benchmark data from lsp-bench, run 2026-02-13. All servers tested on the same machine against Uniswap v4-core.