Skip to main content
You can send a transfer on NEAR using NEAR CLI or an API library such as near-api-js, near-kit, or near-api-rs.

​
Send a Transfer

A plain transfer to a non-created implicit account creates it; the sender pays the account-creation charge.
A plain transfer to a non-existing named account fails and refunds the transferred amount, while consumed gas remains charged.

​
Transaction results

Inspect result.status for success or failure and require final_execution_status === "FINAL" before treating the transfer as complete. The example below shows a finalized FT transfer-and-call submitted by influencer.testnet on testnet.
For detailed information, see transaction receipts. To view the transaction in NearBlocks Explorer, use result.transaction.hash.

​
Concurrent Transactions

If you start sending multiple transactions from a same account - e.g. when creating a relayer - you need to manage nonces carefully to avoid conflicts. In NEAR, accounts can have multiple keys, each with its own nonce sequence. So the simplest way to avoid nonce collisions is to use multiple access keys for concurrent transactions. In near-api-js the MultiKeySigner rotates through a set of keys when creating transactions:

​
Submission errors and retries

With near-api-js 7.3.1, error handling depends on the method used: Typed errors are exported from near-api-js/rpc-errors. When the high-level method throws a transaction or contract execution error derived from a submitted transaction, its transactionResult contains the RPC response, including receipt outcomes. Use that response to inspect status.Failure and the failed receipt; read-only call errors do not include transaction outcomes. Account.signAndSendTransaction() defaults to up to 10 retries after InvalidNonceError, constructing and signing a new transaction on each retry. These examples set retries: 0 so withdrawal recovery controls replacement transactions. This setting does not disable the provider’s HTTP retries. Before broadcasting a withdrawal, persist its business intent, network, signer, reserved nonce, signed bytes, and transaction hash. Keep one recovery process in control of that intent until its outcome is resolved. If rebroadcasting is necessary, resend the same signed bytes while their reference block remains valid. A newly signed transaction has a different hash and can execute a second payment. An expired block hash or consumed nonce on a later attempt does not prove that the original transaction never executed. Resolve the original outcome and reconcile balances before issuing a replacement under the same intent lock. Actions within one receipt are atomic; separate receipts are not rolled back together. A contract call can fail after an earlier receipt has transferred funds. Keep transport errors, validation rejections, and execution failures distinct in your withdrawal records.

​
Frequently Asked Questions

NEAR uses a gas-based model where prices are generally deterministically adjusted based on congestion of the network.We avoid making changes that are too large through re-sharding by changing number of available shards (and thus throughput).Accounts don’t have associated resources. Gas amount is predetermined for all transactions except function calls. For function call transactions the user (or more likely the developer) attaches the required amount of gas. Unused prepaid gas is refunded according to current runtime rules, including any configured unused-gas refund penalty. Query the runtime configuration and budget gas for the contract being called.
The issuer of a transaction should attach some amount of gas by taking a guess at budget which will get the transaction processed. The contract knows how much to fund different cross contract calls. Gas price is calculated and fixed per block, but may change from block to block depending on how full / busy the block is. If blocks become more than half full then gas price increases.See gas purchase, burn, and refund accounting for the current fee model.