Some important changes are coming to the Rust tooling ecosystem, learn more in this blogpost!

The primary objective for the evolution of the Rust tooling ecosystem is Stabilization and Ergonomics.

Currently, many tools still rely on nearcore internal crates. Because nearcore releases frequently bump 0.x versions, this triggers a cascade of breaking changes across the ecosystem.

• The Goal: Reach 1.x Stable Releases for our core primitives and API clients.
• The Method: Migrate away from direct nearcore dependencies in favor of standalone, stable crates (e.g., omni-transaction-rs, near-api-rs).

The "Decoupling"

To achieve independence from nearcore, we must migrate the tooling stack in this specific order:

1. omni-transaction-rs + near-account-id-rs + near-gas-rs (standalone primitives)
2. new near-jsonrpc-client-rs (currently known as near-openapi-client-rs - the client generated from OpenAPI spec generated from nearcore types)
3. near-api-rs
4. near-cli-rs & cargo-near

2. Component Status Overview

Crate	Status	Priority	Key Action Item
near-sdk-rs	🚀 Active Dev	High	Prepare v6.x release
near-api-rs	🛠 Evolving	High	Absorb near-cli-rs logic; 1.x stabilization.
omni-transaction-rs	🗝 Key	High	"Final Boss" for decoupling types.
near-cli-rs	♻️ Refactor	Medium	Migrate common.rs to near-api-rs.
near-openapi-client-rs	📦 Migration	Medium	Rename, Move to Org, Release 1.0.
near-workspaces-rs	🛑 Deprecating	Low	Deprecate in favor of near-api-rs + near-sandbox-rs.
bos-cli-rs	💀 EOL	None	End of Life.

---

3. Core SDKs & APIs

near-sdk-rs [Active Development]

• Status: High activity. Preparing for v6.x release.
• Key Focus:
  • Incorporating breaking changes like structured errors support, impl Into<> and impl AsRef<> arguments for improved usability, and Promise API changes.
  • Reviewing PRs with strict scrutiny regarding ABI compatibility.

near-api-rs [Strategic Core]

• Status: Stable design, but evolving ergonomics.
• Strategic Goal: This is the primary replacement for nearcore dependencies when it comes to off-chain development for NEAR. It must reach a 1.x stable release to stop the cascade of breaking changes.
• Action Items:
  • Migration: Make sure that the common helpers logic from near-cli-rs/common.rs can be implemented with near-api-rs high-level APIs.
  • Features: Audit for missing latest protocol features.
  • Ergonomics: Make final pressure testing of the developer experience before locking in v1.0, e.g. migrating existing projects from near-workspaces-rs to near-api-rs.

near-openapi-client-rs (becoming near-jsonrpc-client-rs)

• Status: Migration pending.
• Notes: There is already a near-jsonrpc-client-rs crate, which depends on nearcore crates. The OpenAPI spec that was introduced to nearcore and is automatically generated from the nearcore types. It is now used to automatically generate the clients in Rust, TypeScript, Python, Kotlin, Swift, and we want to migrate all the downstream tooling to leverage the generated client instead of manually maintain it.
• Migration Strategy:
  • Take the current manual near-jsonrpc-client-rs, branch it as 0.20.x.
  • Merge the currently separate near-openapi-client-rs codebase as the new main.
  • Make sure that the enums/structs that could change over time are marked as #[non_exhaustive] to prevent breaking changes in the future.
  • Release as 1.0.
  • Update near-api-rs to use the released version (it already depends on near-openapi-client-rs instead of near-jsonrpc-client-rs, so the migration should be smooth)

near-sandbox-rs [Stable]

• Status: Stable code, but high friction for new users.
• Issues: Documentation and examples are too simple or too complex, and not designed for users' usecase in mind.
• Action Item: Improve documentation. Cross-link heavily with near-api-rs examples to show how they work together as the replacement for workspaces.

4. CLI Tools

near-cli-rs [Feature Complete / Refactoring]

• Status: Functionally complete.
• Maintenance: Routine dependency updates, bug fixes, and minor UX improvements.
• Major Refactor: Identify general-purpose functions in common.rs and migrate them to near-api-rs.
  • Eventually, near-cli-rs should be a thin wrapper around near-api-rs.

cargo-near [Feature Complete]

• Status: Maintenance mode.
• Tasks: Ensure compatibility with latest near-sdk-rs and near-cli-rs.

cargo-near-new-project-template

• Status: Low maintenance.
• Tasks: Update cargo-near version occasionally.

near-validators-cli-rs

• Status: Maintenance mode.
• Tasks: Keep lockstep with near-cli-rs releases.

5. Primitives & Types (The Foundation)

omni-transaction-rs

• Status: Mostly up-to-date.
• Context: This crate is the key to decoupling from nearcore types.
• Roadmap: We must aggressively migrate the rest of the stack to use this crate.
  • Flow: near-openapi-client-rs → near-api-rs → near-cli-rs → cargo-near.

near-account-id-rs [Stable]

• Status: Stable (v2.0).
• Note: Recently bumped to v2.0 due to the introduction of "0s" accounts.

near-gas-rs [Stable]

• Status: Stable.
• ⚠️ Implementation Note: nearcore uses a wrapper type over this crate for backward compatibility.
  • nearcore: Serializes gas (u64) as JSON numbers.
  • near-gas-rs: Serializes gas as JSON strings.
  • Both can deserialize from either number or string.

near-sdk-abi [Stable / Critical]

• Status: Frozen / High Caution.
• Warning: Any change here is likely a breaking change for the whole ecosystem. Modify only if absolutely necessary.

borsh-rs [Stable]

• Status: Stable.
• Maintenance: Review occasional PRs from community contributors.

6. Deprecation & EOL

• near-workspaces-rs: DEPRECATE. Users should be directed to the combination of near-api-rs (for interaction) + near-sandbox-rs (for environment).
• bos-cli-rs: EOL. No maintenance.

7. Future Considerations

• near-cryptohash-rs: Assess the need for a standalone crate for CryptoHash to avoid duplication (currently, there are at least 3 copies: nearcore, near-sdk-rs, near-api-rs/near-openapi-client-rs)