Transaction Flow in NEAR Protocol

This guide focuses on the stages a docs user can actually observe: submission, transaction status, receipt fan-out, and final outcome. It keeps protocol background only where that background changes what you should query next.

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_until options

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:

1. Your call creates an ActionReceipt destined for the target contract
2. That receipt executes (possibly in a future block, on a different shard)
3. 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.