Skip to content

Developer Tooling & SDKs

In short

Blockchain developer tooling from open-source maintainers who keep Solhint and eth-cli alive. SDKs, CLIs, plugins, and starter kits designed for the friction developers actually feel.

60%
integration-time reduction
200+
Chainlink integrations
75%
oracle-reliability improvement
1M+
Solhint developers
Trusted by teams building on-chain

Blockchain developer tools are the SDKs, CLIs, client libraries, framework plugins, and starter kits that let people build on a chain or protocol without reverse-engineering it first. Good developer tooling is what turns documentation into adoption: it removes the friction between "we have an API" and "developers are shipping on it," and most teams underestimate how much of that gap is tooling, not docs.

Protofire builds and maintains exactly this kind of tooling, and we do it as the team behind Solhint, the open-source Solidity linter used by 1M+ developers. SDK development, CLI design, and library maintenance are not a side project for us; they are work we ship in production and keep alive across version changes.

We build it for the people whose growth depends on it, L1/L2 chains, ecosystem and grants teams, and protocols that want third-party developers to integrate faster, because when the tooling is good, the GitHub activity, the integrations, and the TVL follow.

The categories of developer tooling Protofire builds and maintains

From static analysis to release automation, we own the full developer-tooling surface.

01

Linters & static analysis

Code-quality tools that run against Solidity source before deployment, led by Solhint, the open-source linter used by 1M+ developers.
02

SDKs & client libraries

Packaged language bindings for on-chain interaction, signing, contract calls, event handling, and data access, across TypeScript, JavaScript, and Haskell.
03

CLIs & command-line toolkits

eth-cli and chain-specific command-line tools that let developers fetch data, deploy, and call contract methods on any network from the terminal.
04

Framework plugins

Hardhat and Foundry plugins that integrate oracle, automation, and data-feed testing directly into the workflows developers already use.
05

Subgraph & data tooling

Indexing queries and data-access layers built on The Graph so dApp frontends read on-chain history without running their own nodes.
06

Dev environments & CI

Docker images, starter kits, and release-automation pipelines that take a builder from zero to a working local stack without manual assembly.
01

What developer tooling we build

Developer tooling is everything a builder touches between reading your docs and deploying to mainnet. In practice that means SDKs and client libraries, command-line tools, framework plugins (Hardhat, Foundry), Docker images, starter kits and reference apps, and sample integrations that show the happy path.

The goal is the same across all of them: reduce the number of decisions and dead ends between a developer's first commit and a working integration. We start from observed friction, support load, hackathon questions, failed integrations, rather than guessing, then package the parts that are stable enough to expose.

Tooling built against the wrong pain point is shelfware; tooling built against a measured one compounds adoption. Because we maintain our own developer tools, we design for the parts teams forget: versioning, examples that stay current, CI for releases, and the long tail of maintenance. Benefits: friction removed where developers actually feel it · adoption that compounds, not one-off support · tooling that survives version changes.

02

How we build developer tooling

1

DX Gap Review

We map where developers actually stall, support load, hackathon friction, failed integrations, and prioritize the one or two assets that would move adoption most.
2

Prototype & Choice

We choose the right language and runtime for the tooling scope and build a working prototype to validate the shape before committing the full build.
3

Build & Test

We implement the SDK, CLI, plugin, or kit with documentation, examples, and tests, the parts that decide whether developers actually adopt it.
4

Release & Maintain

Versioning, CI for releases, sample apps, and ongoing updates as your chain or protocol interfaces evolve. Tooling that isn't maintained is tooling that gets abandoned.
03

What we build

SDKs & client libraries (web3 / TypeScript / JavaScript)
CLIs & command-line toolkits
Hardhat & Foundry plugins
Launch kits & starter templates
Docker images & dev environments
Sample apps & reference integrations
Subgraphs & data-access tooling
Linters & developer-quality tools (Solhint)
04

OSS maintainers, not a dev-rel slide

Protofire is a blockchain development company with 250+ shipped projects across 60+ networks and 95+ protocols since 2016, and developer tooling is something we maintain in public, not something we only bill for. We maintain Solhint, the open-source Solidity linter used by 1M+ developers and built with Ethereum Foundation grants; we maintain eth-cli for Ethereum dApp development; we're a Chainlink core contributor and a top-3 indexer in The Graph ecosystem; and our Safe deployments run across 120+ EVM networks securing $2B+ in assets.

When we recommend how to package an SDK or design a CLI, it's from tools we keep alive ourselves, including the linter a million developers run on their own contracts. That same maintenance discipline runs through the Hardhat Chainlink Plugin and Foundry Chainlink Toolkit we built as a Chainlink core contributor and the TypeScript and JavaScript SDKs and client libraries we have shipped for ecosystems including Kadena and Cardano.

The proof is in adoption. Chainlink Developer Tools: the Hardhat Plugin and Foundry Toolkit we built, cut average oracle-integration time by roughly 60% (from ~10 developer-days to 4-5) and improved oracle reliability ~75%, and 200+ projects adopted Chainlink using the suite. And Solhint quietly became default tooling for the Solidity ecosystem, used by 1M+ developers worldwide.

On Cardano, the Developer Studio dev stack we shipped, Docker, CLI, templates, Haskell libraries, and VS Code integration, took builders from zero to a working dApp without manual setup, another adoption surface we measure by how many teams actually build on it. Tooling, for us, is measured the same way developers measure it: by how many people ship on it.

“Tooling is measured the way developers measure it: by how many people ship on it.”

Developer tooling with measurable adoption
-60% integration timeHardhat Plugin & Foundry Toolkit

The Hardhat Chainlink Plugin and Foundry Chainlink Toolkit cut oracle-integration time by up to 60%, improved reliability by 75%, and helped 200+ projects adopt Chainlink.

ChainlinkView project →
0 to dAppDocker, CLI & templates

Shipped a full Cardano dev stack, Docker, CLI, templates, Haskell libraries, and VS Code integration, taking builders from zero to a working dApp without manual setup.

Cardano Developer StudioView project →

FAQ

What are blockchain developer tools?
Blockchain developer tools are the SDKs, CLIs, client libraries, framework plugins, and starter kits that let developers build on a chain or protocol without reverse-engineering it. They sit between your documentation and a working integration, handling the plumbing a builder would otherwise re-implement: signing, contract calls, event handling, data access, testing, and deployment. Good tooling is what turns an available API into an adopted one, taking a developer from first commit to a working integration in hours, not weeks. In practice the category spans SDKs and client libraries, command-line tools, Hardhat and Foundry plugins, Docker images, starter kits, and reference apps that show the happy path. At Protofire we build them for ecosystems and maintain our own, including Solhint, the open-source Solidity linter used by 1M+ developers, and eth-cli for Ethereum dApp development, so we design for versioning and maintenance, not the first release alone.
What's the difference between an SDK and an API?
An API is the interface your platform exposes, the endpoints and contracts a developer can call. An SDK is the packaged tooling that makes that API easy to use from a specific language or runtime: helper modules, types, authentication, error handling, and examples, bundled so developers don't re-implement the plumbing. You can have an API with no SDK, developers integrate the hard way, but not the reverse, since an SDK always wraps an interface. An SDK can also package a compiler, debugger, helper modules, and a framework into one installable unit, and a web3 SDK does the same for on-chain interaction: signing, contract calls, event handling, and data access. Good SDK development is what turns an available API into an adopted one, which is why a chain with strong docs but no SDK often sees integrations stall. The SDK is where developer experience is won or lost.
How long does it take to build an SDK or developer toolkit?
It depends on the surface area and the target language or runtime, but the shape of the work is consistent. We start with a DX-gap review: mapping where developers actually stall, support load, hackathon friction, failed integrations, and prioritizing the one or two assets that would move adoption most. Next we choose the right language and runtime and build a working prototype to validate the design before committing the full build. Then we implement the SDK, CLI, plugin, or kit with documentation, examples, and tests, the parts that decide whether developers actually adopt it. Finally we release and maintain it: versioning, CI for releases, and sample apps. A focused SDK or CLI is naturally faster to ship than a full multi-language tooling suite, so we confirm the exact scope and timeline after the gap review rather than quoting a number blind.
We're a chain or foundation, can you build tooling for our ecosystem?
Yes, chains, foundations, and grants programs are the core audience for this service. We build ecosystem tooling that gives hackathon participants, grantees, and third-party builders something concrete to ship with: SDKs and client libraries, Hardhat and Foundry plugins, launch and starter kits, CLIs, and reference apps that turn "here's the API" into "here's a working example you can fork." The common signal is the same across the teams we work with, builder demand exists, but the tooling to convert it into live integrations doesn't, and a chain falls behind competitor ecosystems on developer experience. Because we already maintain widely-used open-source tooling like Solhint and eth-cli, you get production-grade tooling without pulling your core engineers off chain priorities, and a partner who owns the long tail of versioning and maintenance rather than handing back a prototype that quietly rots.
Do you maintain the tooling after launch?
Yes, maintenance is part of the engagement, not an afterthought, because tooling that isn't maintained is tooling that gets abandoned. Once an SDK, CLI, plugin, or kit ships, your chain or protocol interfaces keep evolving, and tooling that doesn't track those changes silently breaks the integrations built on it. So we handle versioning, CI for releases, sample apps, updated examples that stay current, and ongoing updates as your interfaces change. This is the same way we run our own open-source projects: we maintain Solhint, the Solidity linter used by 1M+ developers, and eth-cli for Ethereum dApp development, keeping both alive across version changes rather than shipping once and walking away. Long-term ownership is how we already work, so a chain or protocol can hand us the developer-tooling surface and keep its core engineers focused on the protocol itself instead of on maintaining plugins and client libraries.
Which languages, frameworks, and chains do you cover?
Language and runtime always follow the tooling scope rather than a fixed stack. In practice we have shipped TypeScript and JavaScript SDKs and client libraries, Hardhat and Foundry plugins, Bash command-line tools, Docker-based development environments, and Haskell libraries for Cardano. On the chain side we work across EVM L1s and L2s and have built tooling for ecosystems including Chainlink, The Graph, Cardano, and Kadena. Concrete examples: eth-cli is our open-source toolkit for developing Ethereum dApps on any network; the Hardhat Chainlink Plugin and Foundry Chainlink Toolkit spin up a local Chainlink node and integrate Data Feeds, VRF, Automation, and Functions; and Cardano Developer Studio bundles Docker, a CLI, templates, Haskell libraries, and VS Code integration into one stack. We choose the right language and runtime after the gap review, so the tooling fits how your developers already work.

Reviewed by Luis Medeiros, Field CTO at Protofire. Last reviewed: June 2026.

Book a call with Alejandro Losa

Schedule a call with our Web3 Solution Architect to receive practical recommendations and a prompt proposal for upgrading your solution.

Protofire 2026. All rights reserved

Message us on Telegram