Transaction Flow in NEAR Protocol
This guide traces the complete lifecycle of a transaction in NEAR Protocol, from JSON-RPC submission to validator execution.
Quick Reference
| Task | RPC Method |
|---|---|
| Submit transaction (fire-and-forget) | broadcast_tx_async |
| Submit and wait for result | broadcast_tx_commit |
| Check transaction status | tx_status |
| View account info | view_account |
| Call view function | call_function |
Guide Sections
Core Concepts
- Foundations - Transaction structure, actions, serialization formats
- RPC & Submission - JSON-RPC endpoints, validation, access keys
- Finality - Execution outcomes, querying results,
wait_untiloptions
Execution Model
- Async Model - Promises, receipts, cross-shard communication
- Runtime Execution - State machine, action execution
- Gas & Economics - Gas accounting, refunds, pricing
Infrastructure
- Network & Blocks - P2P protocol, transaction pool, chunk production
- Infrastructure - State storage, sharding, trie structure
Advanced Topics
- Advanced Features - Meta-transactions (DelegateAction), Promise Yield/Resume
- Reference - Mental models, debugging tips, appendices
Key Concepts
Transactions are Async
Unlike synchronous blockchains, NEAR transactions create receipts that execute asynchronously. A cross-contract call may span multiple blocks and shards.
Receipts, Not Calls
When your contract calls another contract, it doesn't get a return value immediately. Instead:
- Your call creates an ActionReceipt destined for the target contract
- That receipt executes (possibly in a future block, on a different shard)
- The result comes back as a DataReceipt to your callback
Cross-Shard by Design
NEAR is sharded - different accounts live on different shards. Cross-shard communication is automatic but asynchronous. Atomicity is only guaranteed within a single shard.