Editorial polish is still intentionally in progress
This section is hidden from primary navigation. Translation and editorial polish are intentionally out of scope until the section is public.
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.