Section 4 — Wallets, Transactions, Custody, and Safety
Lesson 14 follows a transaction from preparation through confirmation, identifying where address, network, fee, timing, and counterparty errors may occur.
Estimated time: 65–100 minutes
Educational and safety boundary: This lesson provides general education about blockchain transactions. It does not provide individualized financial, investment, legal, or tax advice. It does not recommend a wallet, exchange, network, asset, company, or financial product. You do not need internet access, an account, a wallet, or a digital asset to complete the lesson. Do not create, sign, or broadcast a real transaction for any course activity. Never place a real password, private key, seed phrase, authentication code, account number, wallet address, balance, or transaction record in a course response.
In earlier lessons, I introduced the public treasury associated with the Prison Professors mission. The independent PP token community made activity connected with that treasury visible on BNB Smart Chain. A person can open a blockchain explorer such as BscScan and see records connected with the published address. That visibility can make a transaction look immediate: a line appears on a screen, a status is displayed, and a balance changes.
Behind that line is a sequence of decisions and network actions. Someone or some authorized system prepares an instruction. The instruction identifies a network, addresses, an action, and a fee. An authorized key signs it. A node receives it. The network checks it. A validator may include it in a block. The transaction may succeed or fail during execution. Confirmations develop, and the network eventually treats the record as final according to its rules.
I want you to understand that sequence because a transaction can be technically valid and still be a bad decision. A correct digital signature does not prove that the signer understood the request. A successful status does not prove that the address belonged to the intended person. A public record does not guarantee that an exchange or another company has credited an account. Technology can verify certain facts, but it cannot replace careful judgment.
The most important work often happens before authorization. A person should slow down, verify the network, examine the destination, understand the proposed action, review the fee, and decide whether the instruction matches the intended purpose. Once a valid transaction is broadcast and finalized, changing the result may be difficult or impossible.
You can learn this process without using a device or moving an asset. The offline exercise asks you to arrange transaction stages and identify where errors can enter. The purpose is not to practice sending money. The purpose is to practice thinking in sequence.
Lesson 14 traces a blockchain transaction from preparation through authorization, network processing, confirmation, and final recordkeeping. It separates actions taken by a user or application from actions taken by nodes, validators, and the network.
Essential question: Why do verification and patience matter before and after a person authorizes a blockchain transaction?
After completing this lesson, you should be able to:
Definition: Cryptographic evidence created with a private key to authorize a specific digital message or transaction. A network can use the signature to check that the transaction was authorized by the key connected with the sending account. A valid signature does not prove the signer’s identity, wisdom, ownership rights, or understanding of the transaction.
Sample sentence: The digital signature showed that the transaction was authorized by the required key, but it did not show why the signer approved it.
Definition: A charge paid for network resources used to process a transaction. On many networks, the fee depends on the work requested, network demand, and fee settings. The fee is normally paid in the network’s native asset, even when the transaction involves another token.
Sample sentence: The token transfer required a transaction fee in the network’s native asset.
Definition: To send a signed transaction to a network node so that it can be checked and relayed to other nodes. Broadcasting submits the instruction; it does not guarantee inclusion, success, or finality.
Sample sentence: After the wallet broadcast the signed transaction, the instruction entered the network’s pending process.
Definition: The process of checking whether a transaction follows network rules. Checks may include the signature, account sequence, available balance, fee requirements, transaction format, and rules governing the requested action.
Sample sentence: Validation rejected the instruction because it did not meet the network’s requirements.
Definition: Evidence that a transaction has been included in a block accepted by the network. Additional blocks or network votes may increase confidence that the record will remain part of the accepted history. The meaning of a confirmation differs by network.
Sample sentence: The organization waited for the required confirmation standard before updating its records.
Definition: The point at which a blockchain’s rules provide strong assurance that an accepted transaction will not be reversed. Different networks reach or describe finality in different ways and on different schedules.
Sample sentence: The public record showed the transaction in a block, but the team followed its policy and waited for finality before relying on it.
People sometimes speak as if a digital asset travels through the internet like a package moving through the mail. That description can mislead. On a blockchain, a transaction is better understood as an instruction asking the network to update its shared state.
A simple instruction might ask the network to reduce the recorded balance associated with one account and increase the balance associated with another. A more complex instruction might call a function in a smart contract. It might transfer a token, record an approval, exchange one asset for another, vote in a governance process, or carry out another programmed action.
The instruction normally contains several fields. The exact fields differ by network and transaction type, but they may include:
Some information can be prepared by a wallet or application. The user may see only a summary. That convenience creates a responsibility: the summary should be checked, and any unclear request should be treated cautiously. Signing an instruction that cannot be understood is sometimes called blind signing. A careful person does not assume that a button labeled “confirm” describes every effect.
Preparation begins before a private key is used. A person, organization, wallet, exchange, or application assembles the proposed transaction.
At this stage, the preparer should identify:
These details matter because the same-looking address may be used on more than one compatible network, while an exchange or service may support only one route. A transaction can succeed on the selected network and still fail to produce the intended result at the receiving service. That is not necessarily a network failure. It may be a network-selection or counterparty problem.
Fees also require care. On BNB Smart Chain, BNB is the native asset used to pay transaction fees. A person sending another token may still need enough BNB for the fee. A displayed estimate can change with network conditions or with the complexity of a smart-contract action. An estimate is not a promise.
Review is the last ordinary opportunity to catch an error before signing. The reviewer should compare the proposed instruction with an independent, trusted source of information.
A careful review asks:
Copying and pasting can reduce typing errors, but it does not remove risk. Malicious software can replace a copied address. A familiar beginning and ending are not always enough to establish that a long address is correct. When circumstances permit, a person should compare the complete address or use a trusted address-book process. Organizations should use written verification and approval rules rather than memory alone.
After review, the authorized key holder may sign the transaction. The signature is created from the transaction data and the private key. The private key should remain secret; the signature can be shared with the network.
The signature performs an important but limited job. It allows the network to verify that the required key authorized that exact transaction data. If the transaction data changes after signing, the signature will no longer match.
The signature does not answer every question. It does not prove that the signer:
This distinction connects with Lesson 13. Custody determines who can authorize. Transaction discipline determines how that authority is used.
The signed transaction is sent to a node. The node performs initial checks and may relay the transaction to other nodes. On many networks, valid pending transactions wait in a transaction pool, sometimes called a mempool, until a validator or block producer selects them.
Broadcasting is not the same as completing. A wallet or service may display a transaction identifier, often called a transaction hash, soon after submission. That identifier helps people locate or discuss the transaction. It is not proof that the transaction has been included in a block, executed successfully, credited by a receiving company, or finalized.
A transaction may remain pending because network demand is high, the offered fee is unattractive, a required earlier transaction from the same account is still pending, a node has not relayed it widely, or a service has not actually broadcast the instruction. Some systems allow a pending transaction to be replaced with another transaction using the same sequence number and a different fee. The details vary, so a person should follow verified instructions from the relevant network or service rather than improvising.
Nodes and validators apply network rules. A transaction may be rejected before inclusion if its format, signature, sequence, balance, or fee does not meet those rules. A rejected transaction does not become part of the accepted blockchain history.
A validator may select a valid pending transaction and place it in a proposed block. For a simple transfer, execution may update balances. For a smart-contract interaction, the network executes the contract code with the supplied data.
Execution can succeed or fail. A contract may reject the request because a condition was not met. The transaction may run out of the allowed computational resource. An attempted token transfer may fail because the sending account lacks the token balance or permission required by the contract.
An included but failed transaction can still consume a transaction fee because the network performed work. On Ethereum-compatible networks, including BNB Smart Chain, the exact fee rules depend on the network and transaction. This is one reason a status of “failed” should not be confused with “nothing happened.” The intended state change may have been reversed, while a fee may still have been charged and a public record may still exist.
After inclusion, the network produces a transaction receipt or equivalent record. A block explorer may display information such as:
An explorer translates network data into a readable page. It is useful, but it is not the blockchain itself, and its labels can be misunderstood. A “success” status generally means the network executed the requested instruction without a protocol-level failure. It does not prove that the recipient was correct, that an off-chain company credited the right account, that a token has value, or that the transaction served the mission.
For a transaction involving an exchange, custodian, merchant, or another service, two records may matter. The blockchain records the on-chain event. The company keeps its own account records and may require a memo, supported network, minimum amount, identity review, or a certain number of confirmations. A blockchain success does not force the company’s internal system to credit an account immediately.
Networks use different methods to decide when an accepted block should be treated as final. Some rely on additional blocks, some use validator votes, and some combine methods. BNB Smart Chain uses validator consensus and a fast-finality process. Exact validator counts, block times, and finality timing can change through network upgrades, so they should be checked against current official documentation before publication or operational use.
Patience matters between first inclusion and finality. A careful policy defines what evidence is sufficient before a person or organization relies on a transaction. That policy may depend on the network, value, risk, counterparty, and legal or organizational requirements.
After finality, responsible recordkeeping should reconcile several questions:
Finality answers a blockchain-history question. It does not answer every accounting, legal, tax, ownership, or ethical question.
The independent PP token community has used BNB Smart Chain and a public treasury address associated with the Prison Professors mission. Imagine that a community tracker reports a new community-generated fee transaction connected with that treasury. This simplified teaching scenario does not describe or verify every rule in the token’s smart contract, and it does not promote the token or any digital asset.
An observer might see a new entry on BscScan and say, “The donation is complete.” A more careful analysis separates the stages and the claims.
Preparation: A wallet, contract, or application assembled a transaction on BNB Smart Chain. The instruction identified addresses, data or value, and a fee paid in the network’s native asset.
Authorization: An authorized key produced the required digital signature. If a smart contract initiated part of the process, a prior signed transaction may have called the contract. The public record does not reveal the private key.
Broadcast and validation: A node received and relayed the signed instruction. Network participants checked that it followed BNB Smart Chain rules.
Execution and inclusion: A validator included the transaction in a block. The network executed the requested action and created a receipt showing success or failure.
Confirmation and finality: Later network acceptance increased confidence that the record would remain in the chain’s history.
Reconciliation: Observers could compare the public record with the published treasury address and community report. That comparison could support a limited statement about on-chain activity. It would not, by itself, prove the complete custody arrangement, every contract rule, donor identity, legal ownership, future value, internal accounting treatment, or mission compliance.
This example connects technical discipline with credibility. If I describe the public treasury, I should state what the blockchain evidence supports and avoid claiming more. Participants can practice the same habit in their own work: identify the evidence, trace the sequence, and separate a verified fact from an assumption.
Not every problem has the same meaning. A careful learner distinguishes four categories.
The signed transaction has been submitted but has not yet reached the required inclusion or confirmation status. Possible causes include network demand, fee settings, sequence conflicts, node problems, or a service delay.
The network or submitting service refuses the transaction before it enters an accepted block. Possible causes include an invalid signature, incorrect format, insufficient balance for the amount and fee, an invalid sequence, or fee settings that do not meet network requirements.
The transaction enters a block, but the requested state change does not complete. A smart contract may reject the action, or the transaction may exhaust its computational allowance. The public record may show failure, and a network fee may still be charged for work performed.
The network executes exactly what was signed, but the signer chose the wrong address, wrong network, wrong token, wrong amount, harmful contract approval, or dishonest counterparty. The blockchain may show success even though the human purpose failed.
That final category is especially important. Network validation checks protocol rules. It does not guarantee good judgment.
Estimated time: 25–30 minutes
Materials: Separate paper and a pencil.
The eight cards below are deliberately out of order. Do not create an account or perform a real transaction. On separate paper, write the letters in the order that best represents a typical blockchain transaction.
Card A: A validator includes the transaction in a block and the network executes the requested action.
Card B: The preparer or reviewer checks the network, address, asset, amount, action, and estimated fee.
Card C: The authorized key creates a digital signature for the completed transaction data.
Card D: A node receives the signed transaction and relays it to the network.
Card E: The accepted record gains confirmations and reaches the network’s finality standard.
Card F: A wallet, application, contract, or service assembles the proposed transaction fields.
Card G: Network participants check the signature, sequence, balance, fee, format, and other protocol rules.
Card H: A receipt or explorer record shows the block, fee, and success or failure status.
After arranging the cards, complete these tasks:
Important limitation of the exercise: The cards describe a simplified, typical process. Networks, layers, wallets, custodians, smart contracts, and services may combine, reorder, or label stages differently. The exercise teaches reasoning, not an operational procedure.
A. That the signer made a wise decision
B. That the required private key authorized the specific transaction data
C. That the destination belongs to the intended person
D. That the transaction is already final
A. The transaction has been submitted to a network node, but inclusion and success are not guaranteed
B. The transaction has reached finality
C. The recipient’s company has credited an internal account
D. The fee has been refunded
A. A node rejects a transaction with an invalid signature
B. A wallet has not yet assembled an instruction
C. A valid transaction sends an asset to the wrong address
D. A learner completes the exercise on paper
The practical lesson is simple: slow down before signing, identify what each stage proves, and do not confuse technical success with complete human success.
Write one coherent journal entry of approximately 300–400 words. Write in the first person, as part of the Profile you are building. Do not submit a disconnected list of answers. Use the prompts below to organize a beginning, middle, and conclusion:
Your response should demonstrate reasoning. Do not create, sign, or broadcast a transaction. Do not include any real password, private key, seed phrase, authentication code, account number, wallet address, balance, transaction hash, or transaction detail.
Write your response on separate paper or in an approved institutional messaging system. Include your name or approved Profile identifier, Lesson 14: How a Blockchain Transaction Works, and the date you completed the entry.
Use one of the established Prison Professors Profile methods, subject to your facility’s rules:
Keep a copy when circumstances permit. Never include passwords, private keys, seed phrases, authentication codes, account numbers, real wallet addresses, balances, transaction hashes, transaction details, or other sensitive credentials.
