# fuels-rs: the Rust SDK for building on Fuel

> fuels-rs compiles, deploys and tests Sway contracts from Rust and generates type-safe bindings for them. It is a working SDK with a real CLI, but wallet integration and event querying are still unchecked on its own feature list.

**FuelLabs/fuels-rs** — GitHub describes it as Fuel Network Rust SDK. The repository metadata lists Rust as its primary language. The metadata lists the Apache-2.0 license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/FuelLabs/fuels-rs
- Website: https://fuellabs.github.io/fuels-rs
- Stars: 43,001 · Forks: 1,360
- Language: Rust
- License: Apache-2.0
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/fuellabs-fuels-rs

## What fuels-rs solves for Sway contract developers

Fuel is a blockchain whose contracts are written in Sway, not Solidity. That means the usual Rust tooling for EVM chains does not apply, and a developer who wants to call a Sway contract from a Rust service has to handle ABI encoding, transaction construction and node interaction themselves. fuels-rs exists to remove that work. The README lists its scope plainly: compiling, deploying and testing Sway contracts, launching a local Fuel network, crafting and signing transactions with hand-crafted scripts or contract calls, and generating type-safe Rust bindings of contract methods.

The audience is narrow and identifiable. It is a Rust developer who already has a Sway contract, or who is writing tests for one, and who wants that contract callable from typed Rust rather than from raw bytes. The repository layout reflects this. The workspace members include packages/fuels, packages/fuels-accounts, packages/fuels-code-gen, packages/fuels-core, packages/fuels-macros, packages/fuels-programs and packages/fuels-test-helpers, with separate example crates for contracts, predicates, providers, wallets and rust_bindings. Code generation is not an add-on here; it is its own package, which tells you the bindings are the centre of the design rather than a convenience.

## How the SDK is put together

The workspace split is the clearest signal of the architecture. fuels-core holds base types, fuels-accounts handles wallets and signing, fuels-programs covers contract and script interaction, fuels-code-gen produces the generated Rust, and fuels-macros exposes the procedural macros that developers actually write. fuels-test-helpers exists so that tests can spin up local infrastructure without every project reinventing it. On top of that sits packages/fuels, the crate that most users depend on.

Code generation is the mechanism worth understanding before adopting. You point the tooling at a compiled Sway contract, and fuels-code-gen emits Rust types and methods that mirror the contract's ABI. Calls then go through those generated methods rather than through hand-built byte arrays. The trade-off is that the generated code is a build artefact: when the contract changes, the bindings must be regenerated, and a mismatch between the ABI you generated from and the contract deployed on chain is a runtime failure, not a compile error. The README does not describe a guard against that drift.

The README also names two things the project has not finished. Wallet integration and events querying/monitoring are both unchecked in the feature list. Everything else on that list is checked, including launching Fuel nodes, deploying contracts, interacting with deployed contracts, running Sway scripts, the CLI, and local test wallets. Treat that list as the honest boundary of what the SDK claims to do today.

## Installing fuels-rs and deploying your first contract

The README states two dependencies before anything else: the latest stable Rust toolchain, and the forc and fuel-core binaries, which it points at the Fuel installation guide for fuelup. The workspace Cargo.toml sets rust-version to 1.93.0 and edition to 2024, so an older toolchain will not build the crate.

Once fuelup has installed forc and fuel-core, the SDK's own end-to-end projects have to be built before the test suite will run. The README gives this exact sequence, and the path argument is e2e at the repository root:

```bash
forc build --release --path e2e
cargo test
```

You can narrow that down. The README shows a filter on the test binary name plus a substring match on the test function, with --show-output to print what the test logged:

```bash
cargo test --test types in_vector -- --show-output
```

If tests fail on master, the README's first suggestion is a clean rebuild rather than debugging. It lists these commands in order:

```bash
cargo clean
rm Cargo.lock
forc build --release --path e2e
cargo test
```

The examples directory is where a first real use should start. examples/contracts and examples/rust_bindings cover deploying and calling a contract from generated bindings, and examples/wallets and examples/providers cover the account and connection side. Each is a workspace member, so cargo run with the appropriate package name builds it. The README does not spell out those run commands, so read the example's own source before assuming flags or environment variables.

## Where fuels-rs is the wrong choice

Two unchecked boxes on the feature list are the practical limit. Wallet integration is not done, and events querying or monitoring is not done. If your application needs to watch a contract's events and react to them, or to plug into a user's existing wallet, the SDK as described does not cover that, and you should not plan around it being added on a schedule the README does not give.

There is a second, quieter limitation. The README says the project is still in active development, and the version history supports a reading of steady change: 0.75.1 in October 2025, 0.76.0 later the same month, and 0.77.0 in April 2026. A pre-1.0 crate that moves between minor versions can change APIs, and the workspace's cynic dependency is pinned to a range (>=3.1.0, <3.13.0) rather than a single version, which is a sign the maintainers are tracking a moving upstream. If your project cannot absorb API churn between minor releases, this is a cost to budget for.

Finally, fuels-rs is a Rust SDK. If your service is written in TypeScript, Go or Python, this crate does not help you, and the type-safe bindings it generates are Rust types. Nothing here is a language-agnostic client.

## How fuels-rs differs from ethers-rs

The README answers a naming question that is really an architectural statement. The prefix is fuels, not fuel, because the project wanted the SDK to feel familiar to developers coming from the ethers.js ecosystem, and the fuels-* family is described as inspired by The Ethers Project. That inspiration shows in the shape of the API: accounts, providers, contract abstractions, and a code generator that turns an ABI into typed methods.

The difference in approach is in what the ABI is. With ethers-rs you generate bindings from an EVM ABI and the contract's bytecode is EVM bytecode. With fuels-rs the source contract is Sway and the compiler is forc, so the build step before code generation is a Sway build, not a Solidity one. That is why the README's test instructions begin with forc build --release --path e2e rather than with a Solidity compiler invocation. It also means the debugging examples live under examples/debugging and the macro examples under examples/macros, both of which are specific to this toolchain rather than inherited from the EVM world.

If you are porting a mental model from ethers-rs, the account and provider abstractions will look familiar and the contract compilation step will not.

## Maintenance, licence and upgrade cost

The repository is not archived. Its last push was on 2026-04-06, the same date as the v0.77.0 release. The two preceding releases, v0.75.1 and v0.76.0, both landed in October 2025. So the release cadence visible in the repository is a burst in October 2025 followed by a single release in April 2026, and the most recent activity is that April 2026 push. Nothing published since then is documented.

The upgrade cost is shaped by the pre-1.0 version number and by the workspace's own tooling. The Cargo.toml pins rust-version to 1.93.0, so raising the SDK version can raise your minimum compiler version. The cynic dependency is a range, which means a cargo update can move it within that range without a fuels-rs release. The README's advice for a failing master build (cargo clean, delete Cargo.lock, rebuild the e2e projects, retest) is itself a hint that lockfile and build-state issues are common enough to document.

The licence is Apache-2.0, declared both in the workspace Cargo.toml and in the LICENSE file at the repository root. Apache-2.0 includes an express patent grant and requires that notices and the licence text be preserved in distributions. It is permissive, so it does not force you to open your own source. This is a description of the licence text, not legal advice; check how it interacts with your own distribution model.

## Conclusion

Adopt fuels-rs if you are writing Rust against Sway contracts, running a local Fuel node in tests, or generating typed bindings from a contract ABI. Do not adopt it if you need wallet integration or event querying, both of which remain unchecked in the README feature list, or if your toolchain cannot meet the workspace rust-version of 1.93.0. Before committing, verify that forc and fuel-core are installed via fuelup, that cargo test passes in your own workspace, and that the contract you depend on is covered by the features that are actually marked done.

## FAQ

### What dependencies does fuels-rs need?

The README lists the latest stable Rust toolchain, plus the forc and fuel-core binaries installed through fuelup. The workspace Cargo.toml sets rust-version to 1.93.0 and edition to 2024, so an older compiler will not build it.

### How do I run the fuels-rs tests?

Build the end-to-end Sway projects first with forc build --release --path e2e, then run cargo test. The README also shows filtering a single test binary, for example cargo test --test types in_vector -- --show-output.

### What should I do if the fuels-rs tests fail on master?

The README's first suggestion is to run cargo clean, remove Cargo.lock, rebuild the e2e projects with forc build --release --path e2e, and then run cargo test again. It presents this as the step to try before anything else.

## Sources

- [Official documentation](https://fuellabs.github.io/fuels-rs)
- [Official README](https://github.com/FuelLabs/fuels-rs#readme)
- [Project repository](https://github.com/FuelLabs/fuels-rs)
- [Release notes](https://github.com/FuelLabs/fuels-rs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fuellabs-fuels-rs