Transaction
Authenticated instruction submitted to a blockchain network.
A blockchain transaction is an authenticated instruction submitted to a network for validation and possible inclusion in a block. It may transfer a native coin, call a smart contract, create a contract, vote, approve token spending, or perform another state-changing action. The exact structure depends on the blockchain.
On account-based networks, a transaction commonly includes sender, recipient, value, nonce, fee settings, network identifier, and optional contract data. The sender signs the encoded message with a private key. Bitcoin instead spends previous transaction outputs and creates new outputs under locking conditions. In both models, nodes verify that protocol rules and authorization requirements are satisfied.
After broadcast, nodes may store the transaction in a mempool and relay it. A miner, validator, or sequencer selects and orders activity. Inclusion in a block creates a confirmation, but finality differs by network. Recent blocks can sometimes be reorganized, so higher-value recipients often wait for additional confirmations or protocol finality before treating settlement as irreversible.
Transactions matter because they are the basic units through which users change shared blockchain state. Signing is usually the final authorization step. A wallet label can be misleading: a request described as “connect” or “claim” may include token approval or asset transfer. Users should verify network, recipient, amount, permissions, fees, and contract behavior on a trusted screen.
Failures have several forms. A transaction can remain pending, be dropped before inclusion, or be included and revert during smart contract execution. A reverted transaction generally consumes a fee because computation occurred. A successful status also does not guarantee a favorable result. It can successfully grant a malicious approval, trade at a bad price, or call the wrong contract.
Before sending, confirm address, chain, amount, fee asset, nonce handling, and expected state change. Use transaction simulation where reliable and test unfamiliar destinations with a small amount. Developers should handle duplicate broadcasts, reorganizations, finality, failed calls, and delayed indexers. Records should preserve raw identifiers and timestamps for reconciliation and incident review. A transaction hash is the primary tracking identifier, but correct interpretation requires checking the underlying network record rather than trusting a wallet notification alone.
Frequently asked questions
- The wallet encodes and signs the instruction, then broadcasts it to a node. Nodes check basic validity and may relay it through the peer network or hold it in a pending pool. A miner, validator, or sequencer chooses it for a block. After inclusion, applications wait for the level of confirmation or finality appropriate to the network and value.
- Common reasons include a low fee, network congestion, a missing earlier account nonce, sequencer delay, node rejection, or a wallet showing stale data. Inspect the hash and account on a reputable explorer or independent node. A compatible wallet may replace an account-based transaction with the same nonce and a higher fee. Do not submit random duplicates without understanding ordering.
- Open the transaction hash on the correct network's explorer and confirm status, block, sender, recipient, value, fee, input, events, and confirmations. For contract calls, a successful status means execution did not revert, not that the intended business outcome was safe. Compare balance or contract-state changes, and use more than one data source for high-value activity.