Learning Objectives
By the end of this course, you will be able to:
- Describe the complete anatomy of a blockchain transaction and each of its components
- Compare and contrast the UTXO model (Bitcoin/Kenostod) with the Account model (Ethereum)
- Explain how digital signatures provide authentication, integrity, and non-repudiation
- Trace the full lifecycle of a transaction from creation to final confirmation
- Understand how the mempool works and how transaction ordering affects confirmation
- Explain gas fees, fee markets, and the EIP-1559 mechanism
- Describe how double-spending is prevented in blockchain networks
- Understand transaction finality, confirmation depth, and probabilistic vs deterministic finality
- Analyze smart contract transactions, cross-chain bridges, and privacy techniques
- Apply transaction knowledge using Kenostod’s UTXO-style model in the simulator
This course is designed for thorough learning. Plan for approximately 2 hours of reading, exercises, and practice. Take breaks between sections. True understanding of transactions is fundamental to everything in blockchain, and the 250 KENO reward reflects that commitment.
Anatomy of a Transaction
A blockchain transaction is a cryptographically signed instruction that transfers value from one address to another. It is the fundamental unit of activity on any blockchain network. Think of it as a digital check that gets permanently recorded in a public ledger that everyone can verify — but unlike a check, it cannot be forged, altered, or bounced.
Every time you send cryptocurrency, interact with a smart contract, or even just approve a token transfer, you are creating a transaction. Understanding their structure is essential for anyone working with blockchain technology.
Core Components of a Transaction
While the exact fields vary between blockchains, every transaction includes these fundamental components:
Transaction Data Structure Example
Once a transaction is confirmed on the blockchain, it cannot be altered or deleted. This is what makes blockchain so secure and trustworthy — there's no "undo" button. However, Kenostod introduces an innovative 5-minute reversal window before final confirmation, which you'll learn about in Course 3!
UTXO vs Account Model
There are two fundamentally different ways blockchains track who owns what. Understanding this distinction is critical because it affects everything from transaction structure to privacy to smart contract design.
The UTXO Model (Bitcoin, Kenostod)
UTXO stands for Unspent Transaction Output. In this model, your "balance" is not stored as a single number. Instead, it is the sum of all the unspent outputs from previous transactions that were sent to your address.
Think of it like physical cash: you don't have a bank account with a number in it. Instead, you have a collection of bills and coins. When you pay for something, you hand over bills and receive change back.
How UTXO Works Step-by-Step
The Account Model (Ethereum)
The Account Model works like a traditional bank account. Each address has a balance that gets debited and credited directly. When you send 65 ETH from an account with 100 ETH, the balance is simply updated to 35 ETH (minus fees).
Comparison: UTXO vs Account Model
| Feature | UTXO Model | Account Model |
|---|---|---|
| Used By | Bitcoin, Cardano, Kenostod | Ethereum, Solana, BSC |
| Balance Tracking | Sum of unspent outputs | Single balance value per account |
| Privacy | Higher — can use new change addresses | Lower — single address shows full history |
| Parallel Processing | Excellent — independent UTXOs can be validated simultaneously | Limited — nonce must be sequential |
| Smart Contracts | More complex to implement | Native support, simple state management |
| Double-Spend Protection | Inherent — UTXO can only be spent once | Via nonce tracking |
| Storage Efficiency | Only unspent outputs stored in active set | All account states stored permanently |
| Complexity | Harder to understand initially | Intuitive for most users |
Kenostod uses a UTXO-style model for maximum privacy and parallel validation performance. Each time you receive change, a fresh UTXO is created, making it harder to link your transactions together. Combined with Kenostod’s capped fee structure (max 10 KENO per transaction), this delivers a best-of-both-worlds approach.
Digital Signatures
A digital signature is cryptographic proof that you authorized a transaction. It is the single most important security mechanism in all of blockchain technology. Without digital signatures, anyone could spend your coins.
Think of it like a handwritten signature on a check, but with three critical improvements: it's mathematically impossible to forge, it proves the check wasn't altered after signing, and the signer cannot deny having signed it.
The Three Properties of Digital Signatures
-
Authentication
Proves the transaction came from the owner of the private key. Only the holder of the private key could have produced this exact signature for this exact transaction.
-
Integrity
Proves the transaction data was not modified after signing. Even changing a single bit (e.g., altering 50 KENO to 500 KENO) would invalidate the signature entirely.
-
Non-Repudiation
The sender cannot deny having authorized the transaction. The mathematical proof is undeniable — if the signature verifies with your public key, you signed it.
The Signing Process (ECDSA with secp256k1)
Blockchain transactions use Elliptic Curve Digital Signature Algorithm (ECDSA) on the secp256k1 curve — the same algorithm used by Bitcoin and Ethereum.
Verification Process
When a node receives a transaction, it performs verification in the reverse direction:
Your private key should NEVER leave your device. The signing process happens locally on your computer or hardware wallet. Only the signature (not your private key) is broadcast to the network. If someone obtains your private key, they can sign transactions as you and steal all your funds.
Transaction Lifecycle
A transaction goes through several distinct stages from the moment you click "Send" to the moment it becomes a permanent part of the blockchain. Understanding this lifecycle helps you troubleshoot stuck transactions and make informed decisions about fees.
The Seven Stages of a Transaction
-
Stage 1: Creation
Your wallet software constructs the transaction data structure with all required fields: sender, recipient, amount, fee, nonce, and input UTXOs.
-
Stage 2: Signing
Your private key signs the transaction hash using ECDSA. This happens entirely on your local device — the private key never touches the network.
-
Stage 3: Broadcasting
The signed transaction is sent to one or more network nodes. These nodes relay it to their peers using a gossip protocol, spreading it across the entire network within seconds.
-
Stage 4: Validation
Each receiving node independently validates the transaction: signature check, balance check, double-spend check, format check, and fee verification.
-
Stage 5: Mempool Entry
Valid transactions enter the mempool (memory pool) — a waiting area for unconfirmed transactions. Each node maintains its own mempool.
-
Stage 6: Block Inclusion
A miner or validator selects transactions from the mempool (typically prioritizing higher fees) and includes them in a new block. The block is then proposed to the network.
-
Stage 7: Confirmation
Once the block is accepted by the network and subsequent blocks are built on top of it, the transaction is considered confirmed. More blocks = stronger finality.
Visual: Transaction Flow
Pending: In the mempool, waiting to be included in a block. Confirmed: Included in a block and part of the blockchain. Failed: Rejected by validation (insufficient funds, bad signature, etc.). Dropped: Removed from the mempool after being stuck too long (usually due to too-low fees).
Mempool & Transaction Ordering
The mempool (short for memory pool) is one of the most important yet least understood components of a blockchain network. It is the waiting room for all unconfirmed transactions, and understanding it is key to getting your transactions confirmed quickly.
How the Mempool Works
Every full node on the network maintains its own mempool. When a transaction is broadcast, it propagates across the network via the gossip protocol. Each node that receives it:
- Validates the transaction independently
- Adds it to its own mempool if valid
- Relays it to connected peers who haven't seen it yet
Because each node maintains its own mempool, the mempools across the network are not perfectly synchronized. This is normal and expected behavior.
Transaction Ordering Strategies
When a miner or validator creates a new block, they must decide which transactions to include and in what order. Common strategies include:
| Strategy | Description | Used By |
|---|---|---|
| Fee Priority | Highest fee-per-byte transactions are included first | Bitcoin, most PoW chains |
| First Come, First Served | Transactions ordered by arrival time | Some private/permissioned chains |
| MEV-Aware Ordering | Validators may reorder transactions to extract maximum value | Ethereum (via Flashbots/MEV-Boost) |
| Fair Ordering | Transactions ordered by a deterministic protocol to prevent manipulation | Kenostod, some newer L2s |
Mempool Congestion
During periods of high network activity, the mempool can grow significantly. When Bitcoin's mempool swells, transactions with low fees can wait hours or even days. In extreme cases (like during NFT mint events on Ethereum), the mempool can contain 100,000+ pending transactions.
Maximal Extractable Value (MEV) refers to the profit that miners/validators can make by manipulating the order of transactions. Examples include front-running (inserting a transaction before yours to profit from the price change) and sandwich attacks (placing transactions before and after yours). Kenostod's fair ordering protocol is designed to mitigate these attacks.
Gas Fees & Fee Markets (EIP-1559)
Transaction fees are the economic engine that keeps blockchain networks running. They serve two critical purposes: preventing spam attacks and incentivizing validators to process transactions honestly.
Why Fees Exist
- Spam Prevention: Without fees, an attacker could flood the network with millions of worthless transactions, grinding it to a halt
- Validator Compensation: Miners and validators spend real resources (electricity, hardware, bandwidth) to process and secure transactions
- Prioritization: During congestion, fees create a market-based system for allocating scarce block space
Fee Models Compared
| Fee Model | How It Works | Pros / Cons |
|---|---|---|
| Bitcoin (Simple Auction) | Users bid fees (satoshis/byte). Miners pick highest-paying transactions. | Simple but unpredictable. Fees spike during congestion. |
| Ethereum EIP-1559 | Base fee (burned) adjusts algorithmically + optional priority tip to validators. | More predictable. Base fee is burned, reducing supply. Still has tip wars during congestion. |
| Kenostod (Capped %) | 0.1% of transaction value. Min 0.01 KENO, max 10 KENO per transaction. | Highly predictable. No fee spikes. Affordable for all transaction sizes. |
Deep Dive: Ethereum’s EIP-1559
Ethereum's EIP-1559 (London Hard Fork, August 2021) revolutionized fee markets. Here's how it works:
Kenostod Fee Structure
Kenostod uses a simple, predictable fee system designed for accessibility:
Unlike Ethereum where a simple token transfer can cost $5–$500+ depending on network congestion, Kenostod’s capped fee structure ensures transactions remain affordable for everyone. A whale sending 100,000 KENO pays the same 10 KENO maximum fee as during quiet periods.
Double-Spending Prevention
The double-spending problem is the fundamental challenge that blockchain was invented to solve. In the digital world, data can be copied infinitely. How do you prevent someone from spending the same digital money twice?
Before Bitcoin, this required a trusted intermediary (like a bank) to keep track of who owns what. Satoshi Nakamoto's breakthrough was solving double-spending in a decentralized way, without any central authority.
How Double-Spending is Prevented
In the UTXO Model (Kenostod)
Each UTXO can only be referenced as an input once. When a transaction consumes a UTXO, it is permanently marked as spent. Any subsequent transaction attempting to use the same UTXO is immediately rejected by the network.
In the Account Model (Ethereum)
Each account has a nonce (sequential counter). Each transaction must use the next nonce in sequence. If two transactions share the same nonce, only one can be confirmed — the other is discarded.
Race Condition Attacks
A sophisticated attacker might try to broadcast two conflicting transactions simultaneously to different parts of the network. This is called a race attack. The blockchain's consensus mechanism (PoW, PoS, etc.) resolves this by eventually choosing one canonical chain, making the other transaction invalid.
The 51% Attack
The only theoretical way to double-spend on a mature blockchain is through a 51% attack — where an entity controls more than half of the network's mining/staking power. This would allow them to secretly mine an alternative chain and reverse confirmed transactions. This is why confirmation depth matters (covered in the next section).
If you accept cryptocurrency payments, you should wait for sufficient confirmations before considering a payment final. For small purchases, 1–2 confirmations may suffice. For large purchases ($10,000+), waiting for 6+ confirmations (about 1 hour on Bitcoin) is recommended.
Transaction Finality & Confirmation Depth
Transaction finality is the guarantee that once a transaction is confirmed, it cannot be reversed, altered, or cancelled. Different blockchains offer different types of finality, and understanding this is critical for anyone receiving payments.
Probabilistic vs Deterministic Finality
| Finality Type | Description | Examples |
|---|---|---|
| Probabilistic | Transaction becomes exponentially harder to reverse with each new block. Never 100% "final" in theory, but practically irreversible after enough confirmations. | Bitcoin (6 blocks ≈ 1 hour), Kenostod PoW |
| Deterministic | Transaction is mathematically guaranteed final once confirmed. No amount of computing power can reverse it. | Cosmos (Tendermint BFT), Solana, Algorand |
| Economic | Reversal is theoretically possible but economically irrational (would cost more than the attacker could gain). | Ethereum PoS (after 2 epochs / 12.8 min) |
Confirmation Depth Guidelines
Kenostod combines probabilistic finality with a user-friendly 5-minute reversal window. During this window, the sender can reverse a transaction (useful for correcting mistakes). After the window closes and sufficient confirmations are reached, the transaction achieves practical finality. This innovative approach is covered in detail in Course 3.
Advanced Transaction Types
Beyond simple value transfers, blockchain networks support several sophisticated transaction types that power DeFi, NFTs, cross-chain interoperability, and more.
Smart Contract Transactions
A smart contract transaction interacts with code deployed on the blockchain. Instead of simply sending value, these transactions execute functions within a smart contract.
Cross-Chain Transactions & Bridges
Cross-chain transactions move assets between different blockchain networks. This is achieved through bridges — protocols that lock assets on one chain and mint equivalent tokens on another.
How a Bridge Works:
- Lock: You send 100 KENO to a bridge contract on Chain A. The KENO is locked in the contract.
- Verify: Bridge validators confirm the lock transaction occurred on Chain A.
- Mint: The bridge mints 100 "wrapped KENO" on Chain B, credited to your address.
- Unlock: When you want to return, you burn the wrapped tokens on Chain B, and the bridge releases your original KENO on Chain A.
Bridges are high-value targets for hackers because they hold large amounts of locked assets. The Ronin Bridge hack ($625M), Wormhole hack ($320M), and Nomad Bridge hack ($190M) are stark reminders. Always research a bridge's security model before using it.
Batch Transactions & Gas Optimization
Batch transactions combine multiple operations into a single transaction, saving gas fees significantly.
| Approach | Gas Cost | Savings |
|---|---|---|
| 10 separate ERC-20 transfers | ~650,000 gas total | Baseline |
| Batched via multicall contract | ~350,000 gas total | ~46% savings |
| Kenostod batch transaction | Single capped fee | Up to 90% savings |
Transaction Privacy
Despite the common misconception, most blockchains are pseudonymous, not anonymous. Every transaction is publicly visible, and sophisticated analysis can often link transactions to real-world identities. Several techniques have been developed to enhance transaction privacy.
CoinJoin
CoinJoin combines multiple users' transactions into a single large transaction, making it difficult to determine which inputs correspond to which outputs.
Stealth Addresses
Stealth addresses allow a sender to create a one-time address for each transaction on behalf of the recipient. The recipient can detect and spend from these addresses, but no one else can link them to the recipient's main address.
Zero-Knowledge Proofs (ZKPs)
ZKPs allow one party to prove they know something (e.g., they have sufficient balance) without revealing the actual information (the balance itself). Networks like Zcash use ZKPs (specifically zk-SNARKs) to enable fully private transactions.
Privacy Comparison
| Technique | Privacy Level | Trade-offs |
|---|---|---|
| UTXO change addresses | Low-Medium | Free, built-in to UTXO model. Only hides change flow. |
| CoinJoin | Medium | Requires coordination. Identifiable by chain analysis firms. |
| Stealth Addresses | Medium-High | Unlinkable receiving. Requires scanning blockchain for deposits. |
| Zero-Knowledge Proofs | Very High | Computationally expensive. Complex to implement and audit. |
| Kenostod UTXO + change | Medium | Automatic change addresses provide baseline privacy for all users. |
There is an ongoing tension between user privacy and regulatory requirements (KYC/AML). Most legitimate privacy tools are designed to protect ordinary users' financial privacy — similar to how a bank doesn't publish your account balance publicly. However, fully anonymous systems can be exploited for illicit purposes, leading to regulatory scrutiny.
Real-World Case Studies
These real events demonstrate critical lessons about transaction mechanics, security, and the importance of understanding how transactions work:
Case Study 1: The Bitcoin Pizza Transaction (2010)
What happened: On May 22, 2010, programmer Laszlo Hanyecz paid 10,000 BTC for two Papa John's pizzas. This was the first known real-world transaction using Bitcoin. At today's prices, those pizzas would be worth over $400 million.
Transaction lesson: This demonstrates the fundamental property of blockchain transactions — immutability. The transaction is permanently recorded on the Bitcoin blockchain and can never be reversed. It also shows how transaction fees work: Laszlo's original transaction included a tiny fee that was worth fractions of a cent at the time.
Key takeaway: Every blockchain transaction is permanent. May 22nd is now celebrated annually as "Bitcoin Pizza Day."
Case Study 2: The $500M Ethereum Fee Error (2021)
What happened: In September 2021, a DeFi user accidentally set a transaction fee of 7,676 ETH (approximately $23 million at the time) for a simple $100,000 transaction. The mining pool that received the fee voluntarily returned most of it.
Transaction lesson: This highlights the critical importance of transaction review before signing. In Ethereum's account model, fees are set by the user (or their wallet software). A bug in the user's custom script set the gas price astronomically high.
Key takeaway: Always verify transaction details before confirming. Kenostod's capped fee model (max 10 KENO) prevents this kind of catastrophic error entirely.
Case Study 3: The DAO Hack — A Smart Contract Transaction Gone Wrong (2016)
What happened: An attacker exploited a reentrancy vulnerability in The DAO smart contract, draining 3.6 million ETH ($60 million at the time). The attacker called the withdraw function recursively before the contract updated its balance, effectively withdrawing the same funds multiple times.
Transaction lesson: Smart contract transactions execute code, and bugs in that code can have devastating consequences. The reentrancy attack exploited the order of operations within a single transaction — the state update happened after the external call, allowing recursive draining.
Key takeaway: Smart contract transactions must be carefully audited. This incident led to the Ethereum hard fork, splitting the chain into ETH and ETC.
Case Study 4: Bitcoin's Double-Spend Scare (January 2021)
What happened: A stale block was mined on Bitcoin, briefly causing the same transaction to appear in two competing blocks. Media outlets incorrectly reported a "double spend" on Bitcoin, causing brief market panic.
Transaction lesson: This was actually normal blockchain behavior — a temporary fork resolved by the consensus mechanism. No actual double-spend occurred. It demonstrated why waiting for multiple confirmations matters. After just 1 additional block, the "competing" transaction was orphaned and discarded.
Key takeaway: Understanding confirmation depth and probabilistic finality prevents panic during normal blockchain events. This is exactly why merchants should wait for sufficient confirmations.
Written Exercises
Complete these exercises to reinforce your understanding. Take your time — thoughtful answers demonstrate true comprehension.
Exercise 1: UTXO Calculation
You have the following UTXOs in your Kenostod wallet: 25 KENO, 40 KENO, and 10 KENO. You want to send exactly 55 KENO to a friend. Describe which UTXOs would be consumed, what the outputs would be, and calculate the exact change you'd receive (remember: 0.1% fee, min 0.01 KENO).
Exercise 2: UTXO vs Account Model Comparison
A company needs to pay 50 employees their monthly salary in cryptocurrency. Compare how this would work using the UTXO model vs the Account model. Which would be more efficient and why? Consider transaction fees, privacy, and complexity.
Exercise 3: Double-Spend Scenario Analysis
You run an online store that accepts KENO payments. A customer sends you 500 KENO for a product. After you see the transaction in the mempool (0 confirmations), you ship the product immediately. The customer then broadcasts a competing transaction sending those same UTXOs to their own second wallet with a higher fee. What happens and how could you have prevented this?
Exercise 4: Fee Market Analysis
During an NFT mint event, Ethereum's base fee spikes to 500 gwei (normally ~20 gwei). Explain using EIP-1559 mechanics why this happens, how the base fee adjusts back to normal, and why Kenostod's fee model would handle this situation differently.
Exercise 5: Bridge Risk Assessment
You want to move 1,000 KENO from the Kenostod blockchain to Ethereum using a cross-chain bridge. List at least 3 specific security risks involved, explain the lock-and-mint mechanism, and describe what due diligence you would perform before using the bridge.
Final Exam (12 Questions)
You must score at least 10 out of 12 correct (80%) to complete this course and earn your 250 KENO reward. Take your time and review the material if needed.
Kenostod Blockchain Academy © 2024-2026