Skip to main content
Native NEAR deposits can arrive as direct transfers or as transfers generated by contract calls. Both are detected through successful, finalized receipt outcomes. For fungible-token deposits, see Fungible Tokens.

​
Detecting Deposits

​
Find Incoming Receipts

Exchange can query finalized blocks and their new chunks, or consume a receipt stream from an indexer. Track incoming receipts across all shards: scanning only original transaction receivers misses deposits generated by contracts in later blocks. Inspect chunk receipts as well as transactions, and resolve receipt outcomes even when their original transactions were included earlier. For indexers and hosted data APIs, see Accessing On-chain Data.

​
Verify Finalized Execution

For a known transaction, query status with receipts using named parameters tx_hash, sender_account_id, and wait_until: "FINAL". Require final_execution_status === "FINAL". An indexer must independently establish finality of each receipt’s outcome block. For each receipt addressed to an exchange-controlled account, match receipt_id to receipts_outcome[].id and verify that outcome.executor_id matches the receiver. A successful receipt has SuccessValue or SuccessReceiptId, not Failure or Unknown.

​
Identify Deposit Amounts

Inspect every Transfer action, including those in mixed-action receipts. Record the deposit amount and action index; review key changes, contract deployment, or deletion in the same receipt before accepting it under your custody policy. Receipts with predecessor_id: "system" are refunds or system payouts; reconcile them separately rather than crediting a new customer deposit. NEAR attached to a FunctionCall needs an approved exchange-contract interface that authenticates the customer and accounts for accepted funds, forwarding, and refunds. Do not infer a deposit solely from the attached amount.

​
Direct Transfer Example

This testnet transaction transfers 2 NEAR from influencer.testnet to linkdrop.primitives.testnet. Query its finalized receipt details:
Selected fields from the response:
The receipt ID matches the outcome ID, the executor matches the receiver, and execution succeeded and finalized. The Transfer.deposit is 2000000000000000000000000 yoctoNEAR (2 NEAR). If the receiver is a customer-assigned account you control, record that movement once using its receipt ID and action index (0 here). The receiver’s balance after this transfer is shown in Balances & Reconciliation.

​
Transfer from Function Call

NEAR allows transfers to happen within a function call. More importantly, when an account is deployed with some contract, it is possible that the only way to transfer tokens from that account is through a function call. Therefore, exchanges need to support transfers through function calls as well. The lockup and multisig examples below show how contract calls generate transfer receipts and how to inspect their execution outcomes.

​
Example of transfer from a lockup contract

A contract evgeny.lockup.near is deployed and we can check its owner by
Now we want to transfer some unlocked tokens (1 NEAR) with the following call
Note: the response below can be obtained by hitting the RPC with the transaction hash and NEAR account like this:
As we can see, there are four receipts generated in this function call. If we apply the criteria mentioned above, we can find in receipts field this object
which contains only Transfer action and whose predecessor_id is not system. Now we can check the status of the execution by looking for the same receipt id EvHfj4fUyVuLBRKNdCZmFGr4WfqwYf7YCbzFsRGFTFJC in receipts_outcome field of the rpc return result, this leads us to this execution outcome
and its status contains SuccessValue, which indicates that the receipt has succeeded. Therefore we know that 1000000000000000000000000 yoctoNEAR, or 1 NEAR has been successfully transferred.

​
Example of transfer from a multisig contract

Multisig contract, as the name suggests, uses multiple signatures to confirm a transaction and therefore, actions performed by the multisig contract involve multiple transactions. In the following example, we will show how a transfer is done from a multisig contract that requires two confirmations.
  • First step: add_request_and_confirm. This initiates the action that the multisig contract wants to perform with one confirmation. The multisig contract multisigtest.testnet wants to transfer 1 NEAR to bowen and it first sends a transaction that calls add_request_and_confirm with a request
that indicates it wants to transfer 1 NEAR to bowen. Notice that this transaction only records the action but does not perform the actual transfer. The transaction result is as follows:
  • Second step: confirm. A second transaction is sent to confirm the transfer. This transaction takes the request id returned by the first transaction and does the actual transfer. The transaction result is as follows
Notice that similar to the transfer from lockup contract, there is also one receipt in the receipts field that meet our requirements:
and we can find its outcome in receipts_outcome:
which indicates that the transaction is successful. For fungible-token deposits, see Fungible Tokens.