near-kit
A clean, ergonomic Rust client for NEAR Protocol.
API Docs · Examples · Changelog
Why near-kit?
If you've worked with NEAR in Rust before, you've probably dealt with raw JSON-RPC calls, manual serialization, or incomplete client libraries. near-kit is designed to fix that.
It's a ground-up implementation focused on developer experience:
- One entry point. Everything flows through the
Nearclient — no hunting for the right module. - Configure once. Set your network and credentials at startup, then just write your logic.
- Explicit units. No more wondering if that's yoctoNEAR or NEAR. Write
NearToken::near(5)or"5 NEAR". - Batteries included. Built-in support for FT/NFT standards, typed contracts, multiple signers, and automatic retries.
Quick Start
Reading from the blockchain doesn't require any credentials:
use *;
async
Sending Transactions
For writes, just add your credentials. The client handles nonce management, block references, signing, and retries automatically:
let near = testnet
.credentials?
.build;
// Transfer tokens
near.transfer.await?;
// Call a contract function
near.call
.gas
.await?;
For CI/CD, configure via environment variables:
// Reads NEAR_NETWORK, NEAR_ACCOUNT_ID, NEAR_PRIVATE_KEY
let near = from_env?;
Multiple Accounts
Transport and signing are separate concerns. Set up the connection once, then derive clients for different accounts with with_signer. They share the same RPC connection, so there's no overhead:
let near = testnet.build; // read-only, shared connection
let alice = near.with_signer;
let bob = near.with_signer;
alice.transfer.await?;
bob.transfer.await?;
For single-account scripts, the credentials builder is still the simplest path. Use with_signer when you need to manage multiple accounts or want explicit separation between connection setup and signing.
Need to pass arguments or attach a deposit? Chain the builders:
near.call
.args
.deposit
.gas
.await?;
Multi-Action Transactions
NEAR supports batching multiple actions into a single atomic transaction. This is useful for creating accounts, deploying contracts, or any sequence that should succeed or fail together:
near.transaction
.create_account
.transfer
.add_full_access_key
.deploy
.call
.args
.send
.await?;
Typed Contract Interfaces
Tired of stringly-typed method names and serde_json::json! everywhere? Define a trait for your contract and get compile-time checking:
// Now you get autocomplete and type errors at compile time
let counter = near.;
let count = counter.get_count.await?;
counter.increment.await?;
Signers
Different situations call for different key management. near-kit supports several approaches:
| Signer | When to use it |
|---|---|
InMemorySigner |
Scripts and bots with a hardcoded or loaded key |
FileSigner |
Local development — reads from ~/.near-credentials |
EnvSigner |
CI/CD pipelines via NEAR_ACCOUNT_ID and NEAR_PRIVATE_KEY |
RotatingSigner |
High-throughput apps that need multiple keys to avoid nonce conflicts. Use into_per_key_signers() to split into per-key signers for sequential send queues |
KeyringSigner |
Desktop apps using the system keychain (requires keyring feature) |
Token Standards
Working with fungible or non-fungible tokens? near-kit includes helpers for NEP-141 and NEP-171.
For common tokens like USDC, USDT, and wNEAR, use the provided constants to avoid copy-pasting addresses. They automatically resolve to the correct address based on the network:
// Known tokens auto-resolve based on network
let near = mainnet.build;
let usdc = near.ft?;
let balance = usdc.balance_of.await?;
println!; // "1.50 USDC"
// Or use raw addresses for any token
let custom = near.ft?;
// Non-fungible tokens
let nft = near.nft?;
if let Some = nft.token.await?
Available known tokens: tokens::USDC, tokens::USDT, tokens::W_NEAR
Feature Flags
| Feature | Description |
|---|---|
sandbox |
Local testing with near-sandbox |
keyring |
System keyring integration for desktop apps |
Documentation
For the full API reference, see docs.rs/near-kit.
License
MIT