Transactions, State and Smart Contracts

Introduction

A blockchain is not merely a sequence of blocks; it is a replicated state machine. Each valid transaction proposes a change to the state of a network, and each participating node independently checks whether that change complies with the protocol. Blocks provide ordering and consensus, while transactions provide the inputs that cause state transitions.

Understanding transactions therefore requires more than learning how to transfer digital assets. A transaction may create and destroy spendable outputs, update account balances, invoke a smart contract, emit events, consume computational resources, and alter the conditions under which later transactions are accepted. This chapter examines the transaction lifecycle, two major state models—UTXO and account-based systems—validation, fees, finality, and smart-contract execution environments.

Learning Objectives

By the end of this chapter, students should be able to:

1. Trace a transaction from creation to confirmation and final settlement.
2. Compare UTXO and account-based state models.
3. Explain transaction validation rules, fee mechanisms, and resource limits.
4. Distinguish probabilistic, economic, and deterministic finality.
5. Describe how smart contracts execute and change blockchain state.
6. Assess practical, security, governance, and regulatory implications of transaction design.

1. The Blockchain as a State-Transition System

Let the complete network state at time or height t be represented by S_t. A valid transaction T_t transforms that state into a new state S_t+1:

Here, F is the protocol-defined state-transition function. The function is deterministic under the same initial state and transaction, although the transaction may be rejected if it violates protocol rules. In practice, a block contains an ordered list of transactions, so a block transition can be represented as:

The order matters. For example, a transaction that transfers tokens may be valid only if an earlier transaction in the same block has created those tokens. Nodes must therefore agree not only on which transactions are valid, but also on their canonical order.

A blockchain state commonly includes:

• ownership or balances;
• account nonces or replay-prevention counters;
• unspent transaction outputs;
• smart-contract code and storage;
• validator, staking, or governance records; and
• protocol metadata such as block height and configuration parameters.

A transaction is an authenticated instruction. It normally contains an intended operation, cryptographic authorization, and information needed to pay for processing. It does not become effective merely because it was broadcast. It must pass local validation, enter a candidate block, be accepted by the consensus process, and reach the relevant degree of finality.

2. The Transaction Lifecycle

2.1 Construction and authorization

A wallet or application first constructs a transaction. In a payment system this may include recipients, amounts, a fee, a change destination, and a sequence or nonce. In a smart-contract system it may include a destination contract, function selector, encoded arguments, a gas or resource limit, and a fee bid.

The transaction is then signed using a private key or another authorization mechanism. A digital signature normally proves that the signer authorized the transaction without revealing the private key. Signature verification establishes authenticity, but it does not by itself prove that the signer has sufficient funds or that the requested contract operation is valid.

2.2 Local validation and propagation

A node receiving a transaction performs inexpensive checks before relaying it. Typical checks include:

• correct serialization and transaction format;
• valid signature or authorization proof;
• acceptable transaction size;
• sufficient balance or valid referenced outputs;
• correct nonce, where applicable;
• fee above the network’s relay threshold; and
• absence of an obvious conflict with transactions already accepted by the node.

Valid transactions are placed in a transaction pool, often called a mempool, and propagated to peers. Mempool membership is temporary and local: different nodes may hold different transactions and may apply different fee or replacement policies.

2.3 Selection and ordering

A block producer selects transactions from its local pool. Selection typically considers fees, size, execution cost, dependencies, age, and policy constraints. The producer must order transactions so that all state changes are valid when executed sequentially.

A transaction may be valid in isolation but invalid in a proposed block because another transaction has already spent the same input, used the same nonce, or consumed a limited resource. A producer may also exclude a transaction that is valid but economically unattractive.

2.4 Block execution and consensus

The proposed block is checked by other nodes. Verification includes the block header, consensus proof, transaction validity, state transitions, and resource limits. Nodes execute transactions according to the protocol and calculate a resulting state commitment, such as a state root or related cryptographic summary.

If the block satisfies consensus rules, nodes extend their local chain or ledger view. In proof-of-work systems, competing blocks may temporarily exist and the chain with the greatest accumulated work is generally preferred. In proof-of-stake systems, validators propose and attest to blocks, and the protocol may impose penalties for equivocation or other misconduct.

2.5 Confirmation and finality

A transaction is confirmed when it is included in an accepted block. Confirmation is not identical to finality. Finality is the point at which reversal becomes impossible or economically, legally, or computationally impractical under the system’s assumptions.

2.6 Settlement and downstream effects

After confirmation, wallets update displayed balances and applications may react to events. Exchanges, payment processors, and bridges often impose additional confirmation requirements. A smart contract call may also trigger internal transfers or events, so applications should not infer the complete result solely from the original transaction fields.

3. UTXO State Model

The unspent transaction output (UTXO) model represents value as discrete outputs created by transactions. Each output contains an amount and a spending condition, commonly expressed through a locking script. An output can be used once; after it is consumed, it is removed from the UTXO set.

A transaction consumes one or more inputs, each referring to a previous output, and creates new outputs. The basic conservation rule for a non-coinbase transaction is:

The sums are measured in the blockchain’s smallest monetary unit, such as satoshis. The rule assumes that no protocol-specific issuance or special exception applies. Coinbase transactions in some systems create new issuance and therefore follow different rules.

For example, a user has UTXOs of 0.70 and 0.45 units and wants to pay 0.90 units with a fee of 0.01 units. The wallet selects both inputs. The change is:

The transaction creates a 0.90-unit payment output and a 0.24-unit change output. The original 0.70 and 0.45 outputs are no longer spendable.

Strengths and limitations of UTXO systems

UTXO systems provide a clear history of value provenance. Double spending is detected by checking whether the same output is referenced more than once. Independent outputs can also support parallel validation, and users may improve privacy by avoiding address reuse, although the public transaction graph can still reveal relationships.

The model creates practical challenges. Wallets must perform coin selection, manage change, and consider transaction-size fees. Many small outputs create a “dust” or consolidation problem. Complex application logic may require additional scripting patterns because the state is represented as outputs rather than mutable account storage.

4. Account-Based State Model

An account-based system records state in accounts. A typical externally controlled account has an address, balance, and nonce. A contract account may also contain code and persistent storage. A payment updates the sender’s and recipient’s balances, while a contract call can update storage and create further state changes.

A simplified conservation relationship for a transfer is:

B_s is the sender’s initial balance, B_r the recipient’s initial balance, V the transfer value, and F the fee. The primes indicate post-transaction balances. The equations assume a successful transfer, sufficient sender funds, no other simultaneous state change, and a fee paid by the sender.

The nonce prevents accidental or malicious replay of a signed transaction and normally imposes an ordering on transactions from the same account. A transaction with an incorrect nonce may be rejected, held, or become unusable depending on protocol rules.

Comparison of models

Neither model is universally superior. UTXO designs offer explicit ownership units and strong transaction-level provenance. Account systems often make programmable applications, token balances, and contract storage more intuitive. Implementation quality, execution model, privacy design, and consensus rules matter as much as the choice of state representation.

5. Validation Rules

Validation operates at several layers.

Syntactic validation

The transaction must be correctly encoded and satisfy field-size, type, and serialization requirements. Malformed data is rejected before expensive execution.

Cryptographic validation

Signatures, multisignatures, threshold proofs, or other authorization data must verify against the required public keys. A valid signature proves control of a key under the protocol’s cryptographic assumptions; it does not prove that the transaction is wise, legal, or economically safe.

State and authorization validation

The transaction must refer to spendable outputs or have adequate account balance. It must use the correct nonce, satisfy access-control rules, and obey restrictions such as timelocks, spending limits, or contract permissions.

Semantic and execution validation

The requested operation must execute within defined limits and produce an allowed result. A contract may reject a call, run out of gas, exceed a storage limit, or revert its state changes. Some systems distinguish a failed transaction that still consumes fees from an invalid transaction that cannot be included at all.

Consensus validation

The transaction must comply with block-level rules, including block size, total execution budget, issuance rules, and ordering constraints. A node may relay a transaction under local policy while later rejecting a block that includes it if consensus rules were violated.

6. Fees and Resource Accounting

Fees compensate block producers, discourage spam, and allocate scarce resources. The resource may be block space, computation, storage growth, bandwidth, or state-access capacity.

In a simple byte-priced model:

If a transaction is 250 bytes and the fee rate is 20 smallest-units per byte, the fee is 5,000 smallest units. This formula applies only where the protocol prices transactions by serialized size and where the stated fee rate is constant.

Smart-contract systems commonly price execution units. A simplified fee equation is:

For example, if 80,000 gas units are consumed at 30 gwei per unit, the fee is 2,400,000 gwei, equal to 0.0024 of the native coin because 1 coin equals 1,000,000,000 gwei. Actual protocols may add a base fee, priority fee, refunds, or separate data charges.

Fee markets create trade-offs. High fees may exclude low-value users, while low fees can encourage spam and overload. Wallet software should estimate fees conservatively, identify whether fees are refundable, and warn users when a transaction’s economic value is small relative to its cost.

7. Smart Contracts and Execution Environments

A smart contract is program code deployed to a blockchain-controlled address or equivalent execution domain. It defines rules that nodes execute deterministically. Unlike a conventional server, a contract cannot normally rely on arbitrary private data, uncontrolled system time, or network calls during consensus execution.

A contract call generally contains:

1. a destination contract;
2. encoded method and arguments;
3. authorization from the caller;
4. an execution limit and fee parameters; and
5. optional transferred value.

Nodes execute the call in a virtual machine or specialized runtime. The environment typically supplies deterministic context such as block height, transaction sender, and permitted cryptographic functions. External information is delivered through oracles, which introduce trust, governance, and manipulation risks.

Gas, determinism, and failure

Gas or an equivalent resource unit limits computation. Without a limit, a malicious or faulty contract could force nodes into unbounded computation. If execution exhausts its limit, the call normally fails; whether state changes are reverted and whether the fee is retained depends on the protocol.

Determinism is essential. If two honest nodes execute the same valid transaction against the same prior state and obtain different results, consensus can fail. Contracts should therefore avoid nondeterministic iteration, uncontrolled floating-point behavior, unverified external calls, and assumptions about transaction ordering.

Contract composition

Contracts often call other contracts. Composition enables decentralized exchanges, lending protocols, games, and token systems, but it also creates risks. A contract may invoke an untrusted recipient before updating its own balance, allowing re-entrant behavior. Safer patterns include checks-effects-interactions, reentrancy guards, pull payments, bounded loops, and explicit access control.

Upgradeability and governance

Some applications use proxy contracts or administrative upgrade keys. Upgradeability supports bug fixes but changes the trust model: users must trust administrators, governance procedures, or timelocks. A professionally designed system documents upgrade authority, emergency powers, quorum rules, and conditions for disabling privileged access.

8. Finality Models

Finality should be analysed according to the consensus design and threat model.

• Probabilistic finality: In many longest-chain systems, additional blocks reduce—but do not mathematically eliminate—the probability of reorganization. The risk depends on attacker resources, network conditions, and confirmation depth.
• Economic finality: Reversal is deterred because an attacker risks losing valuable stake, rewards, or reputation. The guarantee depends on assumptions about rational behaviour and the effectiveness of penalties.
• Deterministic or protocol finality: A protocol declares a block final after a defined voting or certificate condition. Reversal may require violating explicit safety assumptions or causing a severe consensus failure.
• Application finality: A business may impose its own threshold, such as waiting for several blocks or a settlement period, even when the underlying protocol offers stronger finality.

Finality is never an excuse to ignore operational risk. Key compromise, smart-contract bugs, chain reorganizations, governance intervention, and legal orders can affect practical settlement even when protocol consensus is functioning correctly.

9. Applied Case: A Token Payment with Contract Verification

The following is an illustrative case, not a report of a specific real-world organization.

Background

A training institution issues a blockchain-based certificate token. Students pay a small registration fee through a contract, and the contract records a certificate identifier after an administrator-approved verification step.

Problem

During peak enrollment, users report failed transactions and inconsistent application displays. Some users see a failed call but believe they have paid; others submit the same request repeatedly, creating unnecessary fees.

Analysis

The investigation separates three layers. First, the wallet must verify signature, nonce, balance, and fee parameters. Second, the contract must check that the certificate identifier is unused and that the caller has the required role. Third, the application must distinguish a transaction being broadcast, included, reverted, or finalized.

The team discovers that the application treats a transaction hash as proof of success. In reality, the hash only identifies the submitted transaction. Several calls were included but reverted because the identifier had already been registered. Users paid execution fees even though the intended state change did not occur.

Approach and solution

The institution implements the following controls:

• display separate statuses for submitted, confirmed, successful, reverted, and finalized;
• read the contract receipt and emitted events rather than trusting the original request;
• use a unique client request identifier and check contract state before resubmission;
• estimate gas but retain a protocol-compliant safety margin;
• document administrator powers and certificate-correction procedures;
• monitor nonce conflicts and fee spikes; and
• publish a process for handling mistaken payments and privacy requests.

Outcome

Duplicate submissions decline, support staff can distinguish network delay from contract failure, and certificate records become auditable. However, the institution accepts that public transactions expose timing and address information and therefore avoids placing personally identifying data directly on-chain.

Learning points

The case demonstrates that transaction lifecycle knowledge is operationally important. A submitted transaction is not necessarily valid, a confirmed transaction is not necessarily successful, and a successful transaction is not necessarily final under the application’s policy. Reliable systems combine protocol status, contract receipts, event interpretation, and clear user communication.

10. Security, Governance and Professional Practice

Private-key custody remains a central risk. Hardware wallets, multisignature authorization, role separation, transaction simulation, address allowlists, and withdrawal limits can reduce exposure. Organizations should maintain recovery procedures without creating a single point of compromise.

On-chain data is durable and often public. Personal data should generally not be written directly to an immutable ledger unless there is a compelling lawful basis and a carefully designed privacy model. Prefer hashes, commitments, encrypted off-chain storage, or verifiable credentials where appropriate, while recognizing that hashes can become identifying when linked with other data.

Smart-contract systems also raise governance questions. Who may pause a contract? Who can upgrade it? What happens after a discovered vulnerability? How are disputes handled? These questions should be answered before deployment, not after an incident.

Regulatory treatment varies by jurisdiction. Payment tokens, investment-like tokens, custodial services, digital identity systems, and automated financial products may trigger different obligations. Technical teams should involve legal and compliance specialists, maintain audit records, and avoid claiming that decentralization automatically removes accountability.

Artificial intelligence can assist with anomaly detection, code review, fee estimation, and support classification. It must not be treated as an authority for transaction validity. AI-generated contract code requires human review, formal or property-based testing where suitable, dependency auditing, and controlled deployment. Models may produce insecure code or misclassify a reverted transaction as successful.

11. Best-Practice Checklist

For transaction designers and operators:

1. Define the state model and all state-transition rules explicitly.
2. Separate consensus validity from local relay policy.
3. Use nonces, unique identifiers, or output references to prevent replay and double spending.
4. Bound computation, storage, recursion, and external calls.
5. Make failure and fee behavior visible to users.
6. Test conflicting transactions, reordering, chain reorganizations, and fee volatility.
7. Treat contract events as useful evidence but verify them against state and receipts.
8. Minimize sensitive data on-chain.
9. Document privileged roles, upgrade paths, and emergency procedures.
10. Monitor finality assumptions and communicate them to business stakeholders.

Chapter Summary

A blockchain transaction is an authenticated request to transform replicated state. Its lifecycle runs from construction and signing through propagation, validation, selection, block execution, confirmation, and finality. UTXO systems represent value as individually spendable outputs and enforce conservation by consuming inputs and creating outputs. Account-based systems maintain balances, nonces, code, and storage, making mutable application state more direct.

Validation includes syntax, cryptography, authorization, state availability, execution, and consensus rules. Fees allocate scarce resources and may be based on bytes, gas, or multiple resource dimensions. Smart contracts execute in deterministic, resource-limited environments, where failures, external calls, upgradeability, and oracle dependence require careful engineering. Finality may be probabilistic, economic, deterministic, or application-defined. Professional practice must combine technical safeguards with privacy protection, governance, regulatory awareness, and transparent user communication.

Key Terms

State transition: A protocol-defined change from one valid ledger state to another.

Transaction: An authenticated instruction requesting a state change.

Mempool: A node’s temporary pool of transactions awaiting inclusion.

UTXO: An unspent transaction output that can be consumed exactly once.

Input: A reference to a previous UTXO being spent.

Output: A newly created amount and spending condition in a UTXO transaction.

Account model: A state model based on balances, nonces, code, and storage.

Nonce: A sequence value used to order transactions and prevent replay.

State root: A cryptographic commitment to a ledger state.

Validation: Checking whether a transaction or block satisfies protocol rules.

Fee: Payment for scarce network resources and transaction processing.

Gas: A unit used to measure smart-contract execution resources.

Smart contract: Deterministic program code executed by blockchain nodes.

Oracle: A mechanism that supplies external information to a contract.

Reentrancy: Unexpected repeated entry into a contract during an external call.

Confirmation: Inclusion of a transaction in an accepted block.

Finality: The point at which a transaction is considered irreversible under stated assumptions.

Reorganization: A change in the previously preferred chain or ledger history.

State storage: Persistent data maintained by a contract or account system.

Multisignature: Authorization requiring signatures from multiple specified parties.

Review Questions

5 Short Answer Questions

1. What is meant by a blockchain state-transition function?
2. Why is a transaction hash not proof that a contract call succeeded?
3. State the main conservation rule for an ordinary UTXO transaction.
4. What purpose does an account nonce serve?
5. Why must smart-contract execution be deterministic?

5 Long Answer Questions

1. Describe the complete lifecycle of a transaction from wallet construction to finality.
2. Compare UTXO and account-based state models, including their principal strengths and limitations.
3. Explain the different layers of transaction validation.
4. Discuss fee markets, gas, and the allocation of scarce blockchain resources.
5. Explain probabilistic, economic, and deterministic finality and identify the assumptions behind each.

3 Analytical / Application Questions

1. A wallet owns UTXOs of 1.20 and 0.35 units. It makes a payment of 1.40 units and pays a fee of 0.02 units. Calculate the change and explain which outputs are consumed and created.
2. A contract call is confirmed but emits a failure receipt. Analyse what the user may have paid, what state changes may have occurred, and what an application should display.
3. Design a transaction-monitoring policy for an exchange that uses an account-based blockchain. Include nonce management, fee management, confirmation thresholds, reorganization handling, and key-security controls.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a blockchain transaction?

A. A permanent database record that requires no validation

B. An authenticated request to change ledger state

C. A block producer’s private key

D. A network connection between two nodes

Correct Answer: B. An authenticated request to change ledger state

Question 2

In a UTXO system, what happens to an output after it is successfully spent?

A. It remains spendable by the original owner

B. It is converted automatically into an account

C. It is removed from the unspent output set

D. It is placed permanently in the mempool

Correct Answer: C. It is removed from the unspent output set

Question 3

A UTXO transaction consumes inputs worth 5.00 units, creates outputs worth 4.85 units, and pays a fee. What is the fee?

A. 0.05 units

B. 0.10 units

C. 0.15 units

D. 9.85 units

Correct Answer: C. 0.15 units

Question 4

What is the primary purpose of an account nonce?

A. To encrypt the account balance

B. To prevent replay and help order transactions

C. To calculate the block hash only

D. To replace digital signatures

Correct Answer: B. To prevent replay and help order transactions

Question 5

Which statement about a mempool is correct?

A. It is identical on every node at all times

B. It contains only finalized transactions

C. It is a node’s temporary pool of transactions awaiting inclusion

D. It stores contract code permanently

Correct Answer: C. It is a node’s temporary pool of transactions awaiting inclusion

Question 6

If 60,000 gas units are used at 25 gwei per unit, what is the fee?

A. 0.00015 coin

B. 0.0015 coin

C. 0.015 coin

D. 1.5 coin

Correct Answer: B. 0.0015 coin

Question 7

Why are execution limits such as gas important for smart contracts?

A. They guarantee that every contract call succeeds

B. They prevent unbounded computation from consuming network resources

C. They make private keys unnecessary

D. They eliminate the need for consensus

Correct Answer: B. They prevent unbounded computation from consuming network resources

Question 8

Which situation illustrates probabilistic finality?

A. A protocol certificate makes reversal impossible under its safety assumptions

B. Additional blocks reduce the probability of a reorganization

C. A contract call is rejected before signing

D. A user stores a backup of a private key

Correct Answer: B. Additional blocks reduce the probability of a reorganization

Question 9

A confirmed contract transaction has reverted. Which conclusion is most accurate?

A. The transaction hash proves the intended state change occurred

B. The call failed according to execution rules, although a fee may still have been charged

C. The block must automatically be invalid

D. The sender’s private key was necessarily stolen

Correct Answer: B. The call failed according to execution rules, although a fee may still have been charged

Question 10

Which practice most directly reduces reentrancy risk?

A. Updating internal accounting only after unlimited external calls

B. Using checks-effects-interactions and reentrancy protections

C. Removing all transaction signatures

D. Increasing the block timestamp

Correct Answer: B. Using checks-effects-interactions and reentrancy protections