Near protocol Near protocol links account access to transaction outcomes across shards
Near protocol is a sharded layer-one blockchain where access keys authorize signed transactions. Receipts carry the authorized actions to execution so applications can inspect the outcomes. Full-access keys can authorize every account action, while function-call keys limit signing to a specified contract, optional methods, and a gas allowance. A submitted transaction may create several receipts, so block inclusion alone does not establish that every downstream action succeeded or reached the finality level an application requires.
Account permissions determine what can be signed, while receipts and execution outcomes show whether the requested state change actually completed.
Full-Access and Restricted Signing Paths
Access keys create two common permission paths. A full-access key can authorize transfers, staking actions, subaccount creation, key changes, contract deployment, contract calls, and account deletion. A function-call key is narrower: it targets one receiver contract, may limit permitted method names, and may cap gas spending through an allowance. It cannot authorize a direct token transfer or attach NEAR to a function call.
An account can hold several keys with different permissions. This makes access a property of the account rather than a single wallet credential. A gas key can use either permission type and can have multiple independent nonce sequences. It pays transaction gas from its own prepaid balance, while attached deposits and transfers still use the account balance. A function-call gas key cannot set an allowance because the prepaid balance is its gas budget. A wallet may retain a full-access key for account administration while an application receives a restricted key for named methods. That restriction reduces the authority exposed to the application, although it does not determine whether the receiving contract will accept the call.
Signing Constraints Before Submission
Transaction validity depends on data fixed before broadcast: the signer account, public key, nonce, receiver account, recent block hash, and requested actions. The signature covers the serialized transaction, so changing a receiver or action requires a new signature. Nodes reject mismatched signatures, stale references, invalid nonces, insufficient balances, and actions beyond the key’s permission. Passing these checks permits receipt creation; it does not settle the requested state change.
How Does a Signed Transaction Become a Final Outcome?
A signed transaction first passes network and runtime validation. The runtime charges the applicable costs, advances the selected nonce sequence, and creates an action receipt addressed to the receiver. This stage establishes that the network accepted the transaction and scheduled its actions. It does not establish that the receiver completed them successfully.
Receipt execution produces an ExecutionOutcome containing a success or failure status, logs, gas information, and any returned value. The transaction outcome and the receipt outcome therefore answer different questions. One records the transition from a signed request to a receipt, while the other records what happened when the receiver processed that receipt.
Contract calls can create more receipts for other contracts, callbacks, or refunds. Each receiver processes its receipt in a later stage, and data-dependent receipts wait for their inputs. The original transaction can consequently remain valid even when a downstream call fails. To determine the operation’s status, inspect every receipt outcome it depends on.
The RPC wait model distinguishes queued, included, optimistically executed, included-final, executed, and final transaction milestones. Inclusion confirms that a block contains the transaction, but that block may not be final and its non-refund receipts may remain unfinished. The strongest final milestone includes finalized refund receipts, which matters when accounting must reflect returned gas or deposits.
A displayed transaction hash identifies the signed payload rather than proving execution success. When an application needs a state change, it should wait for an execution milestone and inspect the returned status. Operations involving later receipts need those outcomes as well. The appropriate stopping point comes from the next action: a display update may tolerate optimistic execution, while dependent settlement may require final execution.
Receipt Routing Across Shards
Sharding changes where a receipt executes without changing the account’s signing rules. When sender and receiver accounts occupy different shards, a receipt carries the action to the shard that holds the receiver. Accounts on the same shard still use receipts, but no cross-shard routing is needed. Users authorize the receiver and action; they do not manually choose a shard for the transaction.
Cross-contract activity remains asynchronous because one receipt can produce another. A callback may depend on data returned by an earlier call, so the runtime postpones it until the required data receipt arrives. Waiting for that dependency is neither success nor failure. It is an intermediate state that explains why a transaction can appear on-chain before the complete application outcome becomes available.
Failures, Refunds, and Partial Effects
Failures fall into validation and execution layers. An invalid signature, unusable nonce, expired reference block, insufficient balance, or permission mismatch can stop a transaction before the requested receiver receipt exists. An execution failure occurs later, after a valid transaction has produced a receipt. The latter can expose a contract error even though the network accepted the original signature.
Receipt failure can trigger a refund receipt for an attached deposit, while unused prepaid gas returns through separate refund accounting. Gas already burned for completed processing remains a cost. A refund is itself part of the receipt flow, so an executed status may arrive before the final accounting state. Applications that display spend or returned funds should distinguish those milestones.
A multi-receipt workflow does not gain global atomicity merely because one signature started it. An earlier receipt can succeed while a later receipt fails, and the chain does not automatically reverse every completed state change. Contract logic may implement a compensating action, but that is application behavior rather than a general protocol guarantee. Check the relevant receipt outcomes rather than relying on the initial transaction status alone.
A Pre-Commit Decision Checklist
A pre-commit check separates durable permission rules from balances, allowances, and fee inputs that can change at signing time.
- Match the access key to the action. Transfers, key changes, contract deployment, and account deletion require full access.
- For a function-call key, confirm the receiver contract and permitted method. If it is a regular key, check any configured allowance; if it is a gas key, check its prepaid balance.
- Check the network and complete receiver account ID before signing the encoded transaction.
- Read current balance, gas, deposit, and fee information from the signing interface or RPC response.
- Choose the required completion milestone before broadcast: inclusion, execution, finality, or completed refund accounting.
Permission scope is the durable rule, while the selected nonce sequence, recent block hash, balance, allowance, and gas conditions are live inputs. A mismatch in the durable rule calls for a different key or action. A changed live input calls for refreshed transaction data and a new signature. That boundary prevents repeated submission of a request that the selected key can never authorize.
Completion Evidence and the Next Decision
Completion evidence determines whether to continue, wait, or stop. Preserve the transaction hash and sender account, then query the milestone the operation requires. A queued or included response calls for more waiting when execution matters. A timeout does not prove failure, so poll before creating a replacement transaction. An explicit execution failure is a stop condition. Successful execution at the chosen finality level permits the next dependent action, while refund-sensitive accounting should wait for the final milestone.
Still have questions?
Do I Need a Signed Transaction to Read Contract State?
No. A view method reads contract state through an RPC call without creating a transaction, selecting a signer account, or paying on-chain gas. The node executes the method against the requested block state, but the call cannot persist changes, transfer tokens, or attach a deposit.
What Happens If an Account Has No Access Keys?
The account becomes locked against ordinary externally signed transactions. If it already hosts a contract, that contract may still act through its programmed methods and could add a key if its code provides such a path. Without an applicable contract path, a wallet cannot restore control through standard signing.
Can a Named Account Create Any Account Name?
No. A named account can directly create subaccounts beneath its own account ID, while a sibling or unrelated name requires the authority responsible for that parent or top-level namespace, and creating a subaccount does not automatically give the parent continuing control after creation.
Does Deploying New Contract Code Erase Existing Storage?
No. Contract code and account storage are separate, so replacing the deployed WebAssembly code leaves stored state in place. New code must still understand the existing data layout. An incompatible change can make that state unreadable or incorrect unless the contract includes an appropriate migration process.
Which Signature Schemes Can Near Protocol Access Keys Use?
Access keys can use Ed25519, secp256k1, or ML-DSA-65 signatures. The permission model remains full access or function call regardless of the signature scheme. Their public key formats and sizes differ. Account state stores a hash of an ML-DSA-65 public key, while a signed transaction carries the full public key.
Why Does a New Transaction Need a Fresh Nonce?
A regular access key has one nonce sequence for its signer account and public key, while a gas key can have several selectable sequences. Nonces order transactions within each sequence and help prevent replay. An accepted transaction advances the nonce in its selected sequence, so another request in that sequence must use a higher value. The recent block hash also limits validity, which means stale transaction data must be refreshed and signed again.