Near protocol
Near protocol access keys authorize transactions, while execution outcomes show their results
Near protocol requires you to inspect the signer, network, receiver, action list, amounts, and permissions before signing, then follow the transaction hash through receipt execution afterward. A valid signature authenticates the transaction, not its result. Use the recorded execution status and resulting account or contract state to check whether it completed as intended.
Action Types and Their Different Consequences
A NEAR transaction can carry one or more actions, and each action instructs the runtime to make a particular change at the receiver account. A Transfer moves native NEAR. A FunctionCall invokes contract code with a method name, serialized arguments, prepaid gas, and an optional deposit. Other actions can deploy code, change keys, stake funds, create an account, or delete one.
The action label determines which details deserve the closest review. A transfer centers on the receiver and amount, while a contract call also depends on its method and arguments. AddKey and DeleteKey alter future authorization. DeployContract changes the code associated with an account, and DeleteAccount names a beneficiary for the remaining balance. Treat those account-management actions as control changes, not routine application interactions.
Signed Fields Bind the Signature to One Transaction
A signature authenticates one serialized transaction. Changing the signer account, public key, nonce, receiver account, block hash, or action list produces different data that the original signature does not authenticate.
The network context matters before authorization. Mainnet and testnet can contain similar-looking account names, while the transaction references a block hash from one chain. Confirm the intended network before comparing balances or contract state. The receiver is equally important because every top-level action in an ordinary transaction targets that receiver, even when a contract later creates receipts for other accounts.
Permission Boundaries Before Authorization
Access-key type determines which transaction the network will accept from a particular public key. Check that boundary to distinguish a restricted FunctionCall transaction from full-access authority.
Full-Access Authority
A full-access key can authorize every valid native account action. It can transfer funds, call or deploy contracts, add and remove keys, stake, and delete the account. A request that adds another full-access key grants continuing control beyond the present transaction. A request that removes a key may also affect recovery, especially when few other authorized keys remain.
Function-Call Limits
A function-call key is restricted to one FunctionCall action directed at its configured receiver. Its permission may name allowed methods and may include an allowance for transaction costs. An empty method list permits calls to any method on that receiver, so the receiver and arguments still need review. A function-call access key cannot attach a deposit to its contract call.
The allowance is a fee budget for that access key, not a description of everything the called method may change. Contract logic can update its own state, create further receipts, or act on assets already placed under its rules. Permission scope and contract behavior therefore answer different questions.
Function Calls Need Argument-Level Review
A FunctionCall action packages several independent choices, and the method name alone rarely describes their full effect. Review the receiver, method, arguments, gas, and deposit as one signed instruction.
Method and Receiver
The receiver identifies the account whose contract code will run, while the method selects an exported function. A familiar method name on an unexpected receiver is still an unexpected call. Conversely, the correct receiver does not make every method appropriate. Compare both fields with the operation that initiated the signing request.
Arguments and Beneficiaries
The arguments supply values that contract code will interpret. Depending on the application, they may contain an account identifier, quantity, permission setting, or another destination. A token transfer made through a contract illustrates the distinction: the top-level receiver can be the token contract, while the intended beneficiary and token amount appear inside the arguments. If a wallet cannot decode them, the prompt provides less evidence for approval.
Gas and Attached Deposit
Prepaid gas sets the execution budget for a function call; it is not the same field as an attached deposit. The deposit transfers NEAR to the receiver as part of the call, subject to the method’s logic. Gas pays for computation and related receipt processing. Inspect both values because a small-looking network cost does not rule out a larger attached deposit.
Amounts, Fees, and Refund Expectations
A transfer amount, attached deposit, and transaction fee represent different movements of value. The transfer or deposit belongs to the requested action. The fee covers network processing, and the final charge depends on the work actually performed. Wallets may present converted or estimated values, so confirm the original unit and the field to which each number belongs.
Unused prepaid gas can return through a refund receipt, while consumed gas remains part of the execution cost. A failed contract call commonly produces a refund for its unused gas and attached deposit, but an asynchronous workflow may already have created other receipts with successful effects. Compare the final balance change with the receipt outcomes rather than assuming that one displayed fee or refund describes the whole transaction.
What Does the Signature Actually Cover?
The signature authenticates the exact serialized transaction and proves control of the selected access key. It covers the receiver and actions as well as technical freshness fields such as the nonce and block hash. It does not certify the contract’s intent, the application’s description, or the eventual success of asynchronous work.
Signing and broadcasting are separate protocol operations, even when a wallet performs both during one confirmation flow. A signed transaction that has not been broadcast can be discarded. Once it has been submitted, assume it may execute until status evidence establishes otherwise. Closing a window or seeing an application timeout does not cancel a request that already reached the network.
Using the Transaction Hash to Verify Execution
The transaction hash identifies the submitted request and should be retained with the signer account and network. A status lookup by hash also needs the sender account identifier. Those values let you distinguish the original request from a later retry and prevent a similarly named account on another network from being mistaken for the signer.
An application success screen is a presentation layer, not independent execution evidence. Read the transaction status through an RPC result or another interface that exposes the same chain data. Match its receiver and actions with the signed request before using the outcome to explain a balance or state change.
From an Unresolved Submission to Confirmed State
A submitted transaction with no visible application change should first be treated as unresolved. The required starting evidence is the transaction hash, signer account, and network. Without that combination, a status query may inspect the wrong request or return no record even though another correctly identified transaction exists.
Querying the known hash changes nothing on-chain and can reveal the execution stage. Signing another request creates a different transaction with a fresh nonce and can produce a second effect if the first one later succeeds. Checking the status first avoids creating a duplicate effect while the original transaction remains unresolved.
| RPC Waiting Level | What It Establishes |
|---|---|
| INCLUDED | The transaction is in a block, but the block may remain unfinalized and receipts may still be pending. |
| EXECUTED_OPTIMISTIC | All non-refund receipts have executed, although their blocks may not yet be final. |
| EXECUTED | The transaction is finalized and all non-refund receipts have executed. |
| FINAL | The transaction and all generated receipts, including refunds, are finalized. |
A requested RPC waiting level is a minimum return condition, so the transaction may already have progressed further. A less strict level may be enough for a responsive interface, while accounting or reconciliation may require stronger evidence.
If the query shows pending execution, continue tracking the same hash. If it shows failure, inspect the error and receipt outcomes before deciding whether the intended state remains unchanged. If the transaction is final and successful, compare the resulting account or contract state with the expected change. The final status and resulting state show whether the operation completed, independently of the application’s promise.
Receipt Outcomes and Partial Effects
Execution evidence comes from both the initial transaction outcome and the receipts created from its actions. This distinction matters on a sharded network because contract calls can schedule work that executes later or on another shard.
Initial Outcome
The initial transaction validates the signature, access key, nonce, balance, and action constraints before producing work for the receiver. Inclusion shows that the request entered a block. It does not by itself show that the receiver completed every action or that later contract calls reached their intended states.
Downstream Outcomes
Receipt outcomes record execution by the accounts that process the work. A complex call can create additional action and data receipts, including callbacks and refunds. Cross-contract execution is asynchronous, so one receipt may succeed while another fails. Successful effects from one branch are not automatically erased merely because a separate branch returns an error.
Observable State
The resulting state should match the operation that was authorized. For a transfer, inspect the relevant balances after adequate finality. For a contract call, check the contract state, returned value, logs, and downstream outcomes that bear on the requested effect. A SuccessValue can be empty and still indicate successful execution, so an empty value is not itself evidence of failure.
Missing Status and Safe Recovery
An unknown transaction response can come from an incorrect hash, signer account, network, or a provider that lacks the requested record. It does not prove that the transaction never reached the chain. Recheck those identifiers and query synchronized network data before creating a replacement request.
A confirmed validation error or expired transaction did not execute its actions, although the cause still matters. A replacement needs current transaction data, including an acceptable nonce and recent block hash, and it deserves the same receiver and action review as the original. If the first hash is accepted or pending, continue tracking it instead of signing a duplicate.
Reconcile the State Before Finishing
A completed signing workflow ends when the transaction identity, required finality, execution outcomes, and resulting state agree. Keep the hash when the action affects funds, permissions, deployed code, or another state that may need later explanation.
A mismatch is a reason to inspect the failing receipt, returned error, or contract state. Blind resubmission replaces an evidence problem with a second irreversible request. Preserve the original hash, outcomes, and observed state while deciding whether to wait, correct an input, or prepare a separate transaction.
Near protocol - common questions
Can a Signed Transaction Be Edited Before Broadcast?
No. The signature authenticates the exact serialized transaction, including its receiver, actions, nonce, and block hash. Changing any of those fields invalidates that signature. If an unbroadcast transaction is wrong, discard it and construct a new one. If it may already have been broadcast, track its hash before signing a replacement.
Why Does Each Access Key Have Its Own Nonce?
NEAR tracks the nonce for each signer account and public-key combination rather than using one account-wide sequence. Multiple authorized keys can therefore submit transactions without sharing the same nonce counter. A new transaction’s nonce must be greater than the stored nonce for the key that signs it, or validation will reject the request.
When Is an Attached Deposit Different From a Network Fee?
An attached deposit is NEAR transferred to the receiver as part of a FunctionCall action, while the network fee pays for processing the transaction and its receipts. Prepaid gas defines an execution budget. The final fee reflects consumed resources, and unused prepaid gas can return through a refund receipt.
Does the Receiver Account Always Receive Every Downstream Asset?
No. The transaction receiver processes the top-level actions, but contract code can create receipts for other accounts. In a contract-mediated token transfer, for example, the token contract may be the receiver while the beneficiary appears in the call arguments. Verify the arguments, downstream outcomes, and final state instead of relying on the receiver field alone.
What Should I Share When Troubleshooting a Signing Failure?
Share the transaction hash if one exists, the signer account, the network, the displayed receiver and actions, the exact error, and the expected versus observed state. Never share a private key or recovery phrase. Avoid sharing an unbroadcast signed payload because another party could submit it while it remains valid.