If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/FuelLabs/fuels-rs shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 4w ago
• 18 active contributors
• Distributed ownership (top contributor 36% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live FuelLabs/fuels-rs repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/FuelLabs/fuels-rs.

What it runs against: a local clone of FuelLabs/fuels-rs — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in FuelLabs/fuels-rs | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 61 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of FuelLabs/fuels-rs. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/FuelLabs/fuels-rs.git
#   cd fuels-rs
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of FuelLabs/fuels-rs and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "FuelLabs/fuels-rs(\\.git)?\\b" \\
  && ok "origin remote is FuelLabs/fuels-rs" \\
  || miss "origin remote is not FuelLabs/fuels-rs (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "packages/fuels/Cargo.toml" \\
  && ok "packages/fuels/Cargo.toml" \\
  || miss "missing critical file: packages/fuels/Cargo.toml"
test -f "packages/fuels-core/Cargo.toml" \\
  && ok "packages/fuels-core/Cargo.toml" \\
  || miss "missing critical file: packages/fuels-core/Cargo.toml"
test -f "packages/fuels-code-gen/Cargo.toml" \\
  && ok "packages/fuels-code-gen/Cargo.toml" \\
  || miss "missing critical file: packages/fuels-code-gen/Cargo.toml"
test -f "packages/fuels-macros/Cargo.toml" \\
  && ok "packages/fuels-macros/Cargo.toml" \\
  || miss "missing critical file: packages/fuels-macros/Cargo.toml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 61 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~31d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/FuelLabs/fuels-rs"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

fuels-rs is a Rust SDK for the Fuel blockchain that enables developers to compile, deploy, and interact with Sway smart contracts, generate type-safe Rust bindings, craft transactions, and launch local Fuel networks. It provides the foundational tooling for building applications on Fuel, mirroring the ethers.js ecosystem approach but for Rust/Fuel. Monorepo (Cargo workspace) with: packages/fuels (main SDK), packages/fuels-accounts (wallet/account logic), packages/fuels-code-gen (abigen macro), packages/fuels-core (low-level types), packages/fuels-macros (procedural macros). Examples in examples/* and e2e/ for integration tests. Documentation as mdbook in docs/src/ with sections for abigen, contract calling, codec, and connection.

Rust developers building decentralized applications on Fuel who need to deploy contracts, call contract methods with type safety, manage wallets, estimate gas, and test their smart contracts locally without writing Sway directly.

Actively maintained and production-adjacent (v0.77.0 released). Has comprehensive CI/CD via GitHub Actions (ci.yml, docs.yml), extensive test coverage across e2e/ and packages/, and detailed mdbook documentation. However, still pre-1.0 versioning indicates some API stability concerns; gaps remain (wallet integration, event monitoring marked incomplete in README).

Moderate risk: depends on external binaries (forc, fuel-core) not vendored in the repo, requires specific Rust version (1.93.0 minimum), and is tightly coupled to Fuel protocol changes. Breaking changes are likely given pre-1.0 status. Single organization (FuelLabs) stewardship means ecosystem risk if org priorities shift.

Active development visible via workspace version 0.77.0, recent CI workflows, and comprehensive documentation updates. Primary focus appears to be contract interaction patterns (docs/src/calling-contracts/), code generation (abigen), and SDK stability. No specific commit data provided, but presence of multi-stage workflows (verify_tag.sh) suggests release process is active.

git clone https://github.com/FuelLabs/fuels-rs.git
cd fuels-rs
forc build --release --path e2e
cargo test

Ensure you have Rust 1.93.0+, forc, and fuel-core installed via fuelup per the docs.

Daily commands:

cd docs && mdbook serve --open  # Local docs
cargo test                      # Run all tests
cargo test --test types in_vector -- --show-output  # Specific test
wasm-pack test                  # WASM tests (in wasm-tests/)

• Cargo.toml — Workspace manifest defining all members (fuels, fuels-core, fuels-accounts, fuels-code-gen, fuels-macros) and resolver strategy; essential for understanding dependency tree and build configuration.
• packages/fuels/Cargo.toml — Primary SDK crate that re-exports and orchestrates all subpackages; entry point for external users and defines the public API surface.
• packages/fuels-core/Cargo.toml — Core encoding/decoding, transaction building, and blockchain interaction primitives; foundation that all other packages depend on.
• packages/fuels-code-gen/Cargo.toml — Code generation engine for type-safe contract bindings from ABI; critical for developer experience and contract interaction patterns.
• packages/fuels-macros/Cargo.toml — Procedural macros (abigen, setup_program_test) that generate boilerplate and test infrastructure; heavily used throughout examples and tests.
• packages/fuels-accounts/Cargo.toml — Account/wallet abstraction layer for signing, balance checking, and transaction submission; required for all on-chain operations.
• docs/src/index.md — Documentation entry point explaining SDK scope, features, and navigation; guides new contributors on what this SDK does and does not cover.

Add a new wallet implementation

1. Create a new struct implementing the Wallet trait in packages/fuels-accounts/src/wallet/ (packages/fuels-accounts/Cargo.toml)
2. Implement required methods: signing, key export, and account derivation (packages/fuels-accounts/src/lib.rs)
3. Add example in examples/wallets/ demonstrating wallet creation and usage (examples/wallets)
4. Document wallet setup and features in docs/src/wallets/ (docs/src/wallets/index.md)

Add support for a new Sway type in code generation

1. Add parser logic in packages/fuels-code-gen for the new Sway type (packages/fuels-code-gen/Cargo.toml)
2. Implement encoder/decoder in packages/fuels-core for the type's binary representation (packages/fuels-core/Cargo.toml)
3. Update the abigen macro to generate correct Rust bindings for this type (packages/fuels-macros/Cargo.toml)
4. Add test in e2e/ with a Sway contract using the new type (e2e)
5. Document type conversion in docs/src/types/ (docs/src/types/index.md)

Add a new high-level SDK feature (e.g., contract multicall helper)

1. Implement feature logic in packages/fuels-core, leveraging existing transaction builders (packages/fuels-core/Cargo.toml)
2. Re-export through packages/fuels/ to make it part of the public API (packages/fuels/Cargo.toml)
3. Create example in examples/contracts/ demonstrating the feature (examples/contracts)
4. Write comprehensive documentation in docs/src/calling-contracts/ (docs/src/calling-contracts/index.md)

Extend test infrastructure (add new test macro or fixture)

1. Create macro logic in packages/fuels-macros if it's a procedural macro (packages/fuels-macros/Cargo.toml)
2. Add test helper utilities in packages/fuels or packages/fuels-accounts (packages/fuels-accounts/Cargo.toml)
3. Add example in examples/ showing macro/fixture usage (examples)
4. Document in docs/src/testing/ (docs/src/testing/index.md)

• Rust — Type-safe systems language; enables compile-time contract binding generation, memory safety without GC, and high-performance transaction construction.
• Procedural Macros (syn/quote) — Code generation at compile time for type-safe ABI bindings; developers get zero-cost abstractions and IDE autocompletion for contract methods.
• RPC over HTTP/WebSocket — Standard Fuel node communication; decouples SDK from node deployment topology and enables light clients.
• Cargo workspace — Modular crate structure (core, accounts, code-gen, macros) allows independent versioning, dependency management, and parallel development.

• Code generation via procedural macros at compile time rather than runtime reflection

  • Why: Eliminates runtime overhead and generates fully type-safe contract bindings; developers get compiler errors for mismatched contract calls.
  • Consequence: Requires recompilation when contract ABI changes; no dynamic contract loading (must know ABI at compile time).

• Modular architecture with separate fuels-core, fuels-accounts, fuels-code-gen crates

  • Why: Allows users to depend only on needed functionality (e.g., core for custom TX building, accounts for wallet mgmt).
  • Consequence: More complex dependency graph; users must understand which crates to import for specific tasks.

• undefined

  • Why: undefined
  • Consequence: undefined

External binary dependency: forc (Sway compiler) and fuel-core (local node) must be installed separately via fuelup, not via cargo. They are NOT vendored. Must rebuild e2e test contracts (forc build --release --path e2e) before running tests or test will fail mysteriously. Workspace resolver = 2 is mandatory for the monorepo to work correctly. Rust edition 2024 requires latest stable toolchain. WASM tests require separate wasm32 target and wasm-pack installation. Tests may fail on master without clean build (see README troubleshooting).

• FuelLabs/sway — The smart contract language (Sway) that fuels-rs compiles and deploys; understanding Sway syntax is required to write contracts that fuels-rs calls
• FuelLabs/fuel-core — The Fuel blockchain node implementation; fuels-rs launches and queries instances of this binary for local testing and deployment
• ethers-rs/ethers-rs — Spiritual predecessor and design inspiration; similar Rust SDK architecture for Ethereum, a good reference for SDK patterns
• FuelLabs/fuel-indexer — Companion service for querying and indexing Fuel blockchain state; users of fuels-rs often integrate with indexer for efficient event monitoring (a feature marked incomplete in fuels-rs)
• FuelLabs/fuelup — Toolchain installer that manages forc and fuel-core versions; essential prerequisite for getting fuels-rs running

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for RocksDB storage backend

The docs/src/connecting/rocksdb.md documentation file exists, but there's no evidence of integration tests validating RocksDB functionality in the e2e test suite. Given that RocksDB is a production storage option, this needs dedicated tests covering persistence, concurrent access, and migration scenarios.

• [ ] Create e2e/tests/rocksdb_integration.rs with tests for RocksDB initialization and data persistence
• [ ] Add tests for concurrent read/write operations to RocksDB backend
• [ ] Add test for RocksDB data recovery across node restarts
• [ ] Document RocksDB test patterns in docs/src/contributing/tests-structure.md

Implement missing codec examples for complex nested types

The codec documentation (docs/src/codec/encoding.md and decoding.md) exists, but examples/codec likely lacks comprehensive examples for encoding/decoding deeply nested Sway types. This is critical since the abigen macro generates complex type hierarchies that users need clear guidance on.

• [ ] Review examples/codec directory and identify missing complex type scenarios (e.g., nested structs with enums, arrays of custom types)
• [ ] Add example in examples/codec for encoding/decoding nested contract types with vectors and tuples
• [ ] Add example for handling dynamic types and slices in codec operations
• [ ] Reference new examples in docs/src/codec/encoding.md and decoding.md

Create WASM bindings tests for fuel-core compatibility matrix

The wasm-tests directory exists but is sparse. Given that fuels-rs supports WASM (likely through wasm-bindgen for browser/Node.js integration), there should be automated tests validating compatibility across different fuel-core versions. The workspace.toml references fuel-core-version tracking scripts but lacks corresponding WASM tests.

• [ ] Review wasm-tests directory structure and identify gaps in coverage
• [ ] Create wasm-tests/tests/fuel_core_version_compat.rs testing WASM bindings against pinned fuel-core versions
• [ ] Add GitHub Actions workflow in .github/workflows for WASM test matrix (browser + Node.js targets)
• [ ] Document WASM testing setup in docs/src/contributing/tests-structure.md

• Add encoder/decoder tests for new Sway types in packages/fuels-core/src/codec/. The codec module has encode/decode functionality but coverage gaps exist; docs/src/codec/ lists features without comprehensive test cases for edge cases like nested enums or large arrays.
• Document the custom-asset-transfer pattern more concretely in docs/src/calling-contracts/custom-asset-transfer.md with a real-world example contract. Currently listed in file structure but may lack implementation examples matching the style of other call-pattern docs.
• Add integration examples to examples/contracts/ for querying contract logs and handling CallResponse in more complex scenarios. Docs reference logs and call-response features (docs/src/calling-contracts/logs.md, call-response.md) but example count is low relative to coverage area.

The fuels-rs Rust SDK demonstrates generally good security practices with a comprehensive security reporting policy, proper use of Cargo's workspace resolver (v2), and organized structure. However, the SECURITY.md file appears incomplete, and there are minor concerns around environment variable documentation and edition specification. No critical vulnerabilities were identified in the visible portions of the codebase. The project would benefit from completing the security documentation, verifying the Rust edition specification, and maintaining regular dependency audits via 'cargo audit'. The presence of proper CI/CD workflows and a dedicated security advisory reporting mechanism are positive indicators.

• Low · Incomplete SECURITY.md File — SECURITY.md. The SECURITY.md file appears to be truncated and incomplete. The security policy document ends mid-sentence at 'Please include as much of the information', which may indicate missing security reporting guidelines or incomplete vulnerability disclosure procedures. Fix: Complete the SECURITY.md file with full security reporting guidelines, including response timeframes, supported versions, and vulnerability handling procedures.
• Low · Environment Variables File Example Without Guidance — .env.example. The .env.example file contains GitHub-related credentials (GITHUB_TOKEN, GITHUB_REPOSITORY_OWNER, GITHUB_REPOSITORY_NAME) without clear documentation about their sensitivity levels or security considerations for handling them. Fix: Add inline comments in .env.example documenting the sensitivity level of each variable (e.g., # SENSITIVE: Never commit actual tokens) and include guidance in documentation about secure credential management.
• Low · Missing Dependency Audit Information — Cargo.toml [workspace.package]. The provided Cargo.toml excerpt shows workspace dependencies but the full dependency tree is not visible. The Rust edition is specified as '2024', which appears to be a future edition and may not be standard - this could indicate a configuration error or non-standard setup. Fix: Verify the Rust edition '2024' is intentional or correct it to a supported edition (2021, 2018, etc.). Run 'cargo audit' regularly to check for known vulnerabilities in dependencies.
• Low · No CODEOWNERS Validation Visible — .github/CODEOWNERS. While CODEOWNERS file exists, the actual content is not provided for analysis. This could be a risk if security-critical code lacks proper ownership assignment. Fix: Ensure CODEOWNERS file includes security-critical packages (fuels-core, fuels-macros) and requires reviews from security-aware team members.
• Low · Incomplete Workspace Member Review — Cargo.toml [workspace] members. The workspace includes multiple members including 'wasm-tests' and 'e2e' test packages. Without full visibility of these packages, potential security issues in test code or WASM builds cannot be fully assessed. Fix: Ensure all workspace members, especially WASM-related packages, undergo security review. Implement tests for cryptographic functions and network operations.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.