Transactions, Wallets and Blockchain Operations

Introduction

A blockchain is useful only when participants can transfer value or update shared state in a reliable, verifiable, and resistant-to-censorship manner. Transactions are the operational units through which these changes occur. A transaction is created by a wallet, authorised with cryptographic signatures, propagated through a peer-to-peer network, checked by validating nodes, selected by a block producer, and eventually treated as sufficiently final by users and applications.

This chapter examines that lifecycle and the technologies surrounding it. It compares the unspent transaction output (UTXO) model used by systems such as Bitcoin with the account model used by Ethereum. It also explains wallets, private keys, seed phrases, transaction fees, block explorers, custody arrangements, and operational security. The distinction between controlling an asset and holding a record of ownership is especially important: most wallets do not store coins. They store or manage the credentials needed to authorise transactions recorded on a distributed ledger.

Learning Objectives

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

1. Trace a transaction from construction to confirmation and finality.
2. Explain hashing, digital signatures, nonce management, and transaction validation.
3. Compare UTXO and account-based state models.
4. Distinguish custodial, non-custodial, hardware, software, and multisignature wallets.
5. Explain seed phrases, key derivation, fees, mempools, confirmations, and block explorers.
6. Evaluate operational, regulatory, ethical, and governance risks in digital-asset custody.
7. Apply secure transaction and custody practices in a professional setting.

1. What a Blockchain Transaction Represents

A transaction is a digitally signed instruction that proposes a state change. In a payment system, the change may transfer value from one participant to another. In a smart-contract platform, it may call contract code, deploy a contract, or transfer a token. A transaction normally contains some combination of:

• the source or inputs;
• the destination or outputs;
• an amount and asset type;
• a sequence number, nonce, or time-related field;
• a fee or fee-rate instruction;
• optional data or contract-call information; and
• a digital signature or signatures.

A transaction is not automatically valid merely because it is signed. Nodes also verify that the signer is authorised, the transaction follows protocol rules, inputs have not already been spent, the account nonce is acceptable, and the fee and size requirements are satisfied.

A useful distinction is between authorization and consensus. A signature demonstrates that a holder of a private key authorised a particular message. Consensus determines whether the network accepts that message as part of the canonical chain. A valid signature therefore provides necessary authorization, but it does not by itself guarantee inclusion, finality, or legal ownership.

2. The Transaction Lifecycle

2.1 Construction

A wallet first obtains current state information. In a UTXO system it identifies spendable outputs. In an account system it reads the account balance, current nonce, and network conditions. The wallet then constructs the transaction, selects fees, and encodes the destination address and amount.

A payment transaction should be checked before signing. Important checks include the chain or network identifier, destination address, asset, amount, fee, contract address, nonce, and any memo or data field. Human-readable address displays and independent verification are valuable because malware can replace copied addresses.

2.2 Signing

The wallet hashes a defined transaction representation and signs the resulting message with a private key. A digital signature normally provides authenticity and integrity: anyone with the corresponding public key can verify that the message was signed by the holder of the private key and was not altered after signing.

The private key must never be transmitted as part of an ordinary transaction. The network receives a signature and the public information needed for verification, not the secret key itself. Different blockchains use different signature schemes and serialization rules, so a signature from one network is not automatically meaningful on another.

2.3 Propagation

After signing, the transaction is broadcast to one or more network peers. Nodes perform preliminary checks before relaying it. These may include syntax, signature validity, sufficient balance or valid inputs, acceptable fee, correct network identifier, and absence of conflicts.

Transactions waiting for possible inclusion are commonly held in a mempool. A mempool is not one globally identical queue. Each node may have different policies, capacity limits, fee thresholds, and transaction arrival times. Consequently, a transaction can be visible to one explorer or node while absent from another.

2.4 Validation and Block Inclusion

A block producer selects transactions from its local candidate set and places them in a proposed block. Other nodes independently validate both the transactions and the block. Validation includes checking the block’s link to its predecessor, consensus metadata, transaction rules, state transitions, and any applicable proof or voting requirements.

A transaction’s fee generally compensates the block producer and may help determine selection priority. However, fee payment does not guarantee immediate inclusion. Congestion, replacement rules, transaction dependencies, policy filters, and chain reorganisations can affect confirmation.

2.5 Confirmation and Finality

A transaction has one confirmation when it is included in a block accepted as part of the current chain. Additional blocks may be built on top of that block, increasing confidence that an alternative history will not replace it.

Finality has different meanings. In a probabilistic-finality system, confidence increases with additional blocks but may not become mathematically absolute under every threat model. In a protocol with explicit finality votes, a block may become economically or cryptographically final once specified validator conditions are met. Users should therefore distinguish:

• unconfirmed: accepted or observed by some nodes but not in a block;
• confirmed: included in a block on the currently preferred chain;
• irreversible or final: protected by the protocol’s stated finality mechanism or by an institution’s risk policy.

Exchanges often require a chosen number of confirmations. This is a business-risk threshold, not a universal law of blockchain technology.

3. Transaction Models

3.1 The UTXO Model

In the UTXO model, the ledger records discrete unspent transaction outputs. Each output specifies an amount and a spending condition, commonly represented by a locking script. A later transaction consumes one or more complete outputs and creates new outputs.

The conservation rule for an ordinary transaction is:

The symbol Σ means the sum over all inputs or outputs. Values are denominated in the blockchain’s smallest unit. The equation assumes a standard non-minting transaction; special protocol transactions, such as block rewards, follow additional issuance rules.

If a user controls a UTXO worth 1.00 units but wants to pay 0.30 units, the transaction normally creates a 0.30-unit payment output and a change output. For example, with a 0.001-unit fee:

The 0.699-unit output is change returning to an address controlled by the payer. Wallets often use fresh change addresses to improve privacy, but poor address management can make accounting and recovery more difficult.

UTXO systems offer useful parallelism because independent outputs can often be validated separately. They also make transaction history explicit. Their challenges include change management, transaction-size variability, coin selection, and the risk of creating many small outputs whose future spending costs exceed their value.

3.2 The Account Model

An account-based blockchain maintains state associated with an address. A basic account may contain a balance, a nonce, and other fields. A transaction typically specifies a sender, recipient, value, fee parameters, nonce, and optional data.

The nonce is a sequence value used to order transactions from an account and prevent unintended replay of the same transaction. If a transaction is signed with an incorrect nonce, it may be rejected, delayed, or conflict with another transaction. Wallets therefore need accurate and carefully managed nonce information, particularly when several transactions are submitted quickly.

Account systems are often intuitive for users because the balance resembles a bank account. They are convenient for smart-contract interaction because contracts can maintain persistent state. However, state access, contract execution, gas accounting, and nonce management introduce their own complexity.

3.3 Comparison

Neither model is universally superior. The appropriate model depends on scalability objectives, programmability, privacy design, transaction semantics, and user requirements.

4. Wallets, Keys, and Seed Phrases

4.1 Wallets as Key-Management Systems

A wallet is best understood as a key-management and transaction-authorisation system. It may display balances by querying nodes or service providers, but the ledger remains on the blockchain. A non-custodial wallet allows the user to control the signing keys. A custodial service controls the keys on behalf of customers and records customer balances in an internal database, settling some transactions off-chain.

A typical asymmetric-key relationship consists of a private key, a public key derived from it, and one or more addresses derived through protocol-specific encoding and hashing. The private key is the critical secret. Possession of it may enable irreversible transfer of assets, while loss may make recovery impossible.

4.2 Wallet Categories

• Software wallets run on desktop or mobile devices. They are convenient but exposed to malware, device compromise, backups, and phishing.
• Hardware wallets isolate signing operations in a dedicated device. They reduce exposure of private keys but do not protect users from approving a fraudulent destination or entering a seed into a fake website.
• Paper or offline backups can reduce online exposure but are vulnerable to physical loss, fire, theft, and transcription errors.
• Multisignature wallets require several independent keys for authorization, such as two of three. They reduce single-key risk but increase coordination and recovery requirements.
• Custodial wallets delegate key management to an institution. They may offer recovery and compliance controls, but introduce counterparty, insolvency, access, and regulatory risks.
• Smart-contract wallets implement authorization logic in software, potentially supporting spending limits, social recovery, and multiple signers. Their security depends on contract correctness and upgrade governance.

4.3 Seed Phrases and Derivation

Many wallets use a human-readable recovery phrase as an input to deterministic key derivation. The phrase can regenerate a hierarchy of addresses and private keys. It is not a password reset token and should be treated as a master secret.

A seed phrase should be generated by a trusted wallet, written or stored according to a tested backup policy, and never photographed, emailed, entered into a website, or shared with support personnel. A passphrase added to a seed can create an additional wallet namespace, but forgetting it may make the associated funds unrecoverable. Users must also understand that wallet recovery standards and derivation paths may differ between products; possessing a phrase does not guarantee that every wallet application will automatically display the expected accounts.

5. Fees and Resource Pricing

Fees compensate validators or miners and price scarce block space or computational resources. A simple fee relationship is:

Here, transaction size is measured in the protocol’s relevant unit, such as bytes or virtual bytes, and fee rate is measured in currency units per size unit. This formula applies where the protocol prices transactions primarily by size.

Some smart-contract platforms use a resource model in which:

Gas used measures computational or storage work, while gas price is the amount paid per gas unit. Protocols may add a base component, priority component, or maximum fee instruction. A user’s maximum is not always equal to the amount ultimately charged.

Fee estimation is probabilistic and time-sensitive. A high fee may improve inclusion priority but cannot correct an invalid transaction. A low fee may remain pending, be dropped from a node’s mempool, or require replacement if the protocol supports replacement. Users should verify whether a wallet is estimating total fee, fee rate, maximum possible fee, or an amount including a separate service charge.

6. Block Explorers and Operational Verification

A block explorer is an interface to blockchain data. It may show transaction identifiers, input and output information, addresses, block height, timestamps, fees, token transfers, contract events, and confirmation status. Explorers are useful for investigation but are not themselves the consensus mechanism.

A professional verification process should:

1. Confirm the correct network and asset.
2. Search the exact transaction identifier or address.
3. Check whether the transaction is confirmed and on the canonical chain.
4. Verify destination, amount, fee, and block details.
5. Distinguish a native-asset transfer from a token event or internal contract call.
6. Use more than one trusted data source when the transaction is operationally significant.

A screenshot or explorer page is evidence of displayed data, not proof that a payment is final. The receiving organisation should establish its own confirmation and settlement policy.

7. Security, Custody, and Governance

7.1 Threats

Common threats include phishing, address substitution malware, fake wallet applications, seed-phrase theft, SIM swapping, cloud-account compromise, malicious browser extensions, insider abuse, coercion, and fraudulent smart contracts. Blockchain transactions are often difficult or impossible to reverse, so prevention is more important than post-incident recovery.

7.2 Custody Controls

A sound institutional custody programme separates duties and applies least privilege. Important controls include:

• documented approval limits;
• transaction allowlists for high-value destinations;
• independent verification of addresses;
• dual control or multisignature approval;
• hardware-backed signing;
• encrypted and geographically separated backups;
• rehearsed disaster recovery;
• time delays for large transfers;
• audit logs and anomaly monitoring; and
• tested key rotation and employee-offboarding procedures.

Backups should be tested by restoring a non-production wallet or using a controlled recovery exercise. A backup that has never been tested is an assumption, not a control.

7.3 Ethical and Regulatory Issues

Custody providers may have obligations involving customer identification, sanctions screening, transaction monitoring, consumer protection, tax reporting, asset segregation, and cybersecurity. Requirements vary by jurisdiction and service type. Institutions must not treat a blockchain address as proof of a person’s identity.

Privacy also requires careful treatment. Public transaction histories can expose financial relationships, salaries, donations, or business activity. Organisations should avoid unnecessary address reuse and should establish lawful, proportionate data-retention practices. At the same time, privacy techniques must not be used to evade legitimate legal obligations.

8. Applied Case: Illustrative Treasury Transfer

Background

A fictional regional technology company, Northstar Systems, holds digital assets for vendor payments. Its finance team uses a three-key multisignature wallet requiring two approvals. The operations team proposes paying a contractor on a smart-contract platform.

Problem

A staff member receives an urgent email requesting payment to a “replacement” address. The address differs from the approved vendor record by several characters. The proposed transaction also uses a higher-than-usual fee because the network is congested.

Analysis

The email creates social pressure, while address-substitution malware or account compromise could explain the changed destination. The fee is not necessarily fraudulent, but it requires review. The transaction must be checked for network, asset, recipient, amount, nonce, and total fee. A screenshot supplied by the vendor cannot establish that the vendor controls the new address.

Approach and Solution

Northstar pauses the payment and contacts the vendor through a previously verified channel. The vendor confirms that the original address remains correct. The company then uses its approved address allowlist, independently verifies the hardware-wallet display, and obtains two authorised signatures. A small test transfer is used only if the organisation’s policy and network economics justify it. The final transaction is monitored through two independent explorers and reconciled with the treasury ledger.

Outcome

The attempted payment is rejected before signing. The company rotates credentials for the affected email account, investigates endpoint security, records the incident, and updates its procedure to require out-of-band verification for every new destination.

Learning Points

The case demonstrates that cryptographic validity does not establish business legitimacy. A perfectly valid signature can authorise payment to a criminal. Effective custody therefore combines protocol knowledge, human controls, identity verification, and operational discipline.

9. Contemporary Developments and Limitations

Wallets are increasingly moving toward account abstraction, programmable authorization, passkeys, social recovery, spending limits, and smart-contract-based policies. These developments can improve usability and recovery, but they expand the software and governance surface that must be trusted. Layer-two networks and payment channels may reduce fees and increase throughput, while introducing bridging, liquidity, withdrawal, and finality considerations.

Artificial intelligence can assist with anomaly detection, address clustering, fee estimation, and support triage. It should not be treated as an autonomous authority for signing transactions. AI systems can hallucinate, misclassify addresses, or be manipulated by adversarial inputs. High-value authorization should remain subject to deterministic policy controls and human accountability.

The main limitation of blockchain operations is that technical finality does not eliminate legal, economic, or operational uncertainty. A transaction may be final yet result from fraud, mistaken identity, a compromised key, or an unlawful instruction. Secure systems therefore combine consensus guarantees with governance, controls, and clear accountability.

Best-Practice Checklist

Before signing, verify the network, asset, destination, amount, fee, nonce or inputs, and contract data. Keep signing devices and software updated from trusted sources. Never disclose a seed phrase or private key. Use multisignature approval for material organisational funds. Maintain tested backups and documented recovery procedures. Treat new addresses and urgent requests as high risk. Monitor transactions after broadcast and define confirmation policies before receiving payments.

Chapter Summary

Transactions are signed state-change instructions, not merely messages of payment. Their lifecycle includes construction, authorization, propagation, mempool handling, validation, block inclusion, confirmation, and finality. A digital signature proves control of a key for a particular message, while consensus determines whether the network accepts the resulting state change.

UTXO systems spend discrete outputs and normally create change; account systems update balances and commonly use nonces to order transactions. Wallets manage keys rather than physically storing blockchain assets. Software, hardware, custodial, multisignature, and smart-contract wallets offer different balances of convenience, control, recoverability, and risk. Seed phrases are powerful recovery secrets and must be protected accordingly.

Fees price block space or computational resources but do not guarantee inclusion or validity. Block explorers support operational investigation but do not replace consensus verification. Professional custody requires independent address verification, least privilege, separation of duties, tested backups, multisignature or dual control, monitoring, and incident response. Finally, cryptographic validity must be distinguished from business legitimacy, legal compliance, and ethical responsibility.

Key Terms

Account model: A ledger model in which balances and state are associated with accounts.

Address: A protocol-specific identifier used to receive assets or invoke authorization conditions.

Block explorer: A service or interface for inspecting blockchain data.

Confirmation: Inclusion of a transaction in an accepted block, usually counted from the transaction’s block.

Custodial wallet: A service in which another institution controls the signing keys.

Digital signature: Cryptographic evidence that a key holder authorised a specified message.

Finality: The condition in which a transaction or block is considered protected from reversal under a stated protocol or policy.

Fee rate: The charge per unit of transaction size or computational resource.

Hardware wallet: A device designed to isolate private-key operations from general-purpose systems.

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

Multisignature: An authorization scheme requiring multiple keys or signatures.

Nonce: A sequence value used, especially in account systems, to order transactions and prevent replay.

Private key: A secret cryptographic value used to generate signatures.

Public key: A value derived from a private key and used to verify signatures.

Seed phrase: Human-readable recovery material used to derive wallet keys.

Smart-contract wallet: A wallet whose authorization logic is implemented by programmable contract code.

Transaction: A signed proposal to change blockchain state.

UTXO: An unspent transaction output that can be consumed by a later transaction.

Validation: Independent checking that a transaction or block satisfies protocol rules.

Review Questions

Short Answer Questions

1. What is the difference between transaction authorization and blockchain consensus?
2. Why does a UTXO transaction commonly require a change output?
3. What operational purpose does an account nonce serve?
4. Why should a seed phrase be treated as a master secret?
5. What information can a block explorer provide, and what can it not guarantee?

Long Answer Questions

1. Explain the complete lifecycle of a blockchain transaction from construction through finality.
2. Compare the UTXO and account models, including their advantages and operational challenges.
3. Discuss the security properties and limitations of software, hardware, custodial, and multisignature wallets.
4. Explain how fees are calculated in size-based and gas-based systems and why fee payment does not guarantee inclusion.
5. Design a custody policy for a medium-sized organisation holding digital assets for vendor payments.

Analytical / Application Questions

1. A UTXO worth 2.500 units is spent to create a payment of 0.800 units and a change output of 1.695 units. Calculate the transaction fee and explain the assumption used.
2. An account submits two transactions with the same nonce but different destinations. Analyse the possible outcomes and recommend an operational response.
3. A vendor requests an urgent payment to a new address and provides a transaction screenshot. Evaluate the risks and construct a verification procedure before signing.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a digital signature in a blockchain transaction?

A. It proves that the transaction has already reached finality.

B. It demonstrates authorization by the relevant private-key holder for a specified message.

C. It guarantees that the recipient is legally entitled to the funds.

D. It encrypts the entire blockchain so that nodes cannot inspect it.

Correct Answer: B. It demonstrates authorization by the relevant private-key holder for a specified message.

Question 2

In a UTXO transaction, what normally happens when an input is worth more than the intended payment plus the fee?

A. The excess is automatically destroyed.

B. The excess remains permanently locked in the input.

C. A change output is created for an address controlled by the payer.

D. The recipient receives the entire input regardless of the requested amount.

Correct Answer: C. A change output is created for an address controlled by the payer.

Question 3

What is the principal purpose of a nonce in many account-based blockchains?

A. To determine the recipient’s private key.

B. To order transactions from an account and help prevent replay.

C. To convert a token into a native asset.

D. To calculate the block hash without transaction data.

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

Question 4

Which formula represents a size-based transaction fee?

A. Fee = transaction size × fee rate

B. Fee = account balance ÷ block height

C. Fee = confirmations × public-key length

D. Fee = output value − input value, ignoring all other rules

Correct Answer: A. Fee = transaction size × fee rate

Question 5

What is a mempool?

A. A permanent archive containing every historical transaction on every node.

B. A node’s local pool of transactions awaiting possible inclusion.

C. A hardware device that stores private keys.

D. A voting committee that determines legal ownership.

Correct Answer: B. A node’s local pool of transactions awaiting possible inclusion.

Question 6

Which wallet arrangement reduces reliance on a single signing key by requiring several approved keys?

A. A reused single-address software wallet

B. A custodial exchange account with one administrator

C. A multisignature wallet

D. A public block explorer

Correct Answer: C. A multisignature wallet

Question 7

A UTXO transaction has inputs totaling 1.000 units, outputs totaling 0.300 and 0.699 units, and follows ordinary non-minting rules. What is the fee?

A. 0.001 units

B. 0.299 units

C. 0.699 units

D. 1.999 units

Correct Answer: A. 0.001 units

Question 8

Which statement about block explorers is most accurate?

A. They replace the blockchain’s consensus mechanism.

B. They guarantee that a displayed payment cannot be reversed under any circumstances.

C. They provide interfaces for inspecting blockchain data but should be interpreted with network and confirmation context.

D. They allow users to recover a lost private key from a transaction identifier.

Correct Answer: C. They provide interfaces for inspecting blockchain data but should be interpreted with network and confirmation context.

Question 9

Which practice is most appropriate when a vendor requests payment to a new address by urgent email?

A. Sign immediately because urgency indicates priority.

B. Verify the address through a previously trusted, independent communication channel.

C. Publish the seed phrase so the vendor can confirm ownership.

D. Use a screenshot as the sole evidence of authenticity.

Correct Answer: B. Verify the address through a previously trusted, independent communication channel.

Question 10

Which statement correctly distinguishes confirmation from finality?

A. Confirmation means a transaction is included in a block; finality refers to the protocol or policy protection against reversal.

B. Confirmation means a private key has been backed up; finality means a fee has been paid.

C. Confirmation and finality always have exactly the same meaning on every blockchain.

D. Finality occurs before a transaction is signed.

Correct Answer: A. Confirmation means a transaction is included in a block; finality refers to the protocol or policy protection against reversal.