This article is part of a structured beginner-friendly DeFi series.
If you discovered this piece through a timeline or shared link and want the full context, it is recommended to start from the beginning of the series and read in order.

In the previous article, we explained something critical:

Ownership in crypto is key-based.
Your wallet signs. The blockchain verifies.

Now we move one layer deeper.

Because in DeFi, nothing happens without a transaction.
If you do not understand transactions, you do not understand DeFi.

Why This Matters

Most beginner panic in DeFi comes from transactions.

“I clicked confirm but nothing happened.”
“It failed. Did I lose my money?”
“Why did I pay a fee if it failed?”

Understanding transactions removes emotional reactions.

And in DeFi, emotional reactions are expensive.

What Is a Transaction, Really?

A transaction is:

A signed instruction that tells the blockchain to change its state.

When you send tokens, you are changing balances.
When you swap tokens, you are calling a smart contract.
When you supply assets to a lending protocol, you are updating contract storage.

Every action in DeFi is just a state change.

A transaction is not necessarily moving money. It is executing logic.

In fact, a blockchain is often described as a global state machine. Each transaction moves that state machine from one valid state to the next.

Your wallet does not “move money.”
Your wallet creates a message.

That message says:
“I authorize this change.”

The blockchain verifies that message and executes it.

How Transactions, Smart Contracts, and Protocols Connect

In the previous lesson, we introduced three important concepts:

• Smart contracts
• Protocols
• Transactions

Now we connect them clearly.

A smart contract is code deployed on the blockchain.
A protocol is a system of smart contracts working together under a defined set of rules.
A transaction is the mechanism that activates that code.

Nothing inside a protocol happens automatically.

Smart contracts do not “run in the background.”
They only execute when a transaction calls them.

Think of it this way:

• The protocol is the rulebook.
• The smart contract is the automated machine that enforces the rulebook.
• The transaction is the button you press to make the machine run.

If you interact with a lending protocol:

• You send a transaction.
• That transaction calls a smart contract function like "deposit" or "borrow."
• The smart contract checks conditions (collateral, limits, balances).
• If rules pass, state updates.
• If rules fail, it reverts.

This is why understanding transactions is critical.

A transaction is not just a payment.
It is an instruction that tells a protocol which rule to execute.

Without transactions, protocols are just dormant code.
With transactions, protocols become active financial systems.

What Happens When You Click “Confirm”?

Imagine you are swapping $50 worth of tokens.

Step 1: The Wallet Prepares the Transaction

Your wallet builds a data package containing:

• Your address (sender)
• The contract address (destination)
• The function being called (swap)
• Parameters (amount, slippage limit)
• Gas settings
• A nonce (transaction order number)

Nothing has happened yet.

How does the wallet know how to build this package?

It uses the contract’s public interface (called an ABI), the inputs you provided in the application (amount, slippage, etc.), and network defaults (like gas estimation and current nonce) to construct a properly formatted transaction that the blockchain can understand.

Step 2: You Sign

When you click “Confirm,” your wallet:

• Uses your private key
• Creates a digital signature
• Attaches it to the transaction

Now it becomes valid.

This signature proves:
You authorized this action.

Who Actually Sends the Transaction to the Blockchain?

After you sign, something must broadcast the transaction to the network.
In most cases, this is done by your wallet.

The application (for example, a DeFi website) prepares the transaction data. The wallet signs it. Then the wallet sends the signed transaction to a network node through an RPC connection.

So the typical flow looks like this:

Application → Wallet (sign) → Wallet → RPC node → Mempool

What is an RPC node?

RPC stands for Remote Procedure Call.

Your wallet does not usually run a full blockchain node. Instead, it connects to a remote node through an RPC endpoint to read balances and broadcast transactions.

If your RPC provider is slow or temporarily malfunctioning, your wallet may display incorrect balances or fail to send transactions even though the blockchain itself is functioning normally.

Understanding this prevents unnecessary panic when something looks wrong in the interface.

The application does not directly push transactions to the blockchain unless it controls a private key itself.

If a backend service controls a private key (for example, in custodial systems or automated bots), that backend can both sign and broadcast transactions programmatically.

But in standard non-custodial usage, your wallet is the component that broadcasts the signed transaction to the network.

Do You Always Have to Press Confirm Yourself?

In most beginner scenarios, yes.

When using a standard wallet, nothing happens unless you manually approve and sign the transaction.

The blockchain does not "pull" funds from you automatically.

No protocol can move your assets unless:

• You sign a transaction, or
• You previously granted permission (approval) that allows a contract to act within defined limits.

This second case is extremely important.

When you "approve" a token, you are not sending it. You are granting a smart contract permission to move a specified amount of that token on your behalf.

Some applications request an unlimited approval (often displayed as a very large number). This is called an "infinite approval."

If that contract is later compromised or malicious, it could transfer any amount up to the approved limit without asking you again.

This is why allowance management is a core DeFi safety skill.

Authorization in DeFi is not only about individual transactions. It is also about permissions you grant that remain active over time.

However, there are more advanced models where interaction may look automatic.

For example:

• Smart contract wallets can batch actions after one signature.
• Automated trading bots can submit transactions using keys you control.
• Pre-signed approvals can allow future contract interactions.

But even in these cases, authorization still originates from a signature tied to your key.

The critical principle is this:

No valid blockchain transaction can occur without cryptographic authorization.

If you did not sign, or did not previously authorize permission, the transaction cannot legally execute.

This is why signature awareness is the foundation of DeFi security.

Can an App Press Confirm in the Background?

This depends entirely on where the private key lives.

In a standard browser wallet (like a typical extension wallet), a website cannot secretly press “Confirm” for you. The wallet runs in isolation and requires explicit user interaction to sign each transaction.

However, if an application has direct access to a private key, then it can sign transactions programmatically.

This happens in scenarios such as:

• Backend systems where a private key is stored on a server.
• Trading bots running locally with access to your key.
• Custodial services that control keys on behalf of users.

In those cases, transactions can be signed automatically because the key is already accessible to the software.

For hardware wallets, physical confirmation is required. Even if malware is present on your computer, the device itself requires a button press to authorize the signature.

So the real rule is not about pressing a button.

The real rule is about key access.

If software has access to your private key, it can sign. If it does not, it cannot.

This is why key storage architecture determines your security model more than the interface you see on screen.

Step 3: The Transaction Enters the Mempool

After signing, your transaction is broadcast to the network.
It enters something called the mempool.

Think of the mempool as:

A public waiting room of transactions waiting to be included in a block.

How long does it stay there?

Waiting time can range from a few seconds to several minutes, and in rare congestion events, longer.

It mainly depends on:

• The fee you offered compared to other transactions
• Network congestion at that moment
• Block capacity limits
• Whether your transaction competes with high-priority activity

If your fee is competitive, it is usually included quickly. If it is too low during congestion, it may remain pending until conditions change or you replace it with a higher-fee transaction.

What is this "fee" exactly?

The fee is the amount you pay for block space and computation. It is calculated from the gas your transaction uses and the price you are willing to pay per unit of gas.

Why does a higher fee mean faster inclusion?

Block producers select transactions that maximize the economic return of the block. When blocks are limited in size, they naturally prioritize transactions offering higher fees. This is not arbitrary preference; it is how the network allocates scarce block space under demand.

Who receives the fee?

The fee is paid to the block producer (validator or miner, depending on the network). In many modern networks, part of the base fee may be burned (permanently removed from supply), and the remaining portion goes to the validator as compensation for securing and producing blocks.

Is this capitalism or necessity?

It is an incentive mechanism.

Without fees, validators would have no reason to include and process transactions, and the network would be vulnerable to spam. Fees align incentives, allocate limited block capacity, and compensate those who maintain the system.

Fees also serve as a spam filter.

If transactions were free, malicious actors could flood the network with meaningless activity. By attaching a real economic cost to every transaction, the system makes large-scale abuse expensive.

Step 4: Validators Select Transactions

Block producers choose transactions from the mempool.

They prioritize transactions that:

• Pay higher fees
• Fit within block size limits

This is why gas fluctuates.

You are competing for block space.

Step 5: Execution

When your transaction is included in a block:

• The smart contract code executes
• Conditions are checked
• Balances update
• Events are recorded

If everything passes, the transaction succeeds.
An important property here is determinism.

If two honest nodes execute the same transaction in the same state, they must arrive at the same result.

There is no subjective interpretation. The same input always produces the same output under the same state.

If something fails, it reverts.

Can a Smart Contract Send an Email?

No, a smart contract cannot directly send emails, make HTTP requests, or interact with external systems.

Smart contracts must be deterministic. This means that:

• The same transaction
• Executed in the same blockchain state
• Must always produce the exact same result
• On every honest node

Sending an email requires interacting with the outside world (SMTP servers, APIs, network calls so WEB2). External systems can behave differently across time and environments. They may fail, respond slowly, or return different results.

If smart contracts were allowed to depend on such external behavior, two nodes executing the same transaction could end up with different results. That would break consensus.

For this reason, traditional backend patterns do not apply inside smart contracts and executions.

Gas: What Are You Paying For?

Before going deeper, we need to separate two terms that are often confused:

Gas and Fee are not the same thing.

Gas is a unit of measurement. It measures how much computational work your transaction requires.

Fee is what you actually pay. It is calculated based on:

• How much gas your transaction uses
• How much you are willing to pay per unit of gas

In simple terms:

Gas = how much work is done.
Fee = how much you pay for that work.

Two transactions can use the same amount of gas but cost different fees if network demand is different.

Likewise, a complex transaction will use more gas even if network conditions are calm.

Here is a simple example.

Imagine sending tokens directly to a friend. That transaction might use a small amount of gas because it only updates balances.

Now imagine interacting with a lending protocol:

• It checks your collateral
• It calculates your borrowing power
• It updates internal accounting
• It may mint or burn tokens

All of those operations require additional computation.

So even if network congestion is low, the lending transaction will consume more gas than a simple transfer.

Gas reflects computational complexity. Fee reflects market demand for block space.

But who determines that computational complexity?

It is not decided arbitrarily by a person at the moment of execution.

The smart contract developer defines what operations the contract performs. The blockchain protocol defines how much gas each type of operation costs.

When your transaction executes, the network measures the actual operations performed (storage reads, writes, calculations, etc.) and sums their predefined gas costs.

So three layers are involved:

• The developer defines the logic.
• The protocol defines the gas cost per operation.
• The execution determines how much work was actually performed.

Gas usage is therefore a function of real computational effort under predefined network rules not manual judgment by a validator.

Understanding this distinction removes a common beginner confusion when wallets display both "gas" and "max fee."

Gas itself does not "go" anywhere.

Gas is only a measurement unit for computational work.

What is actually transferred is the fee, which is calculated from gas usage and gas price.

So when people say "gas fee," they mean the total transaction fee paid for computation.

That fee follows the same path described earlier:

• A portion may be burned (depending on the network design).
• The remaining portion is paid to the block producer (validator or miner) as compensation.

Gas is the meter. The fee is the payment.
Gas pays for computation.

When you interact with a smart contract, the network must:

• Execute code
• Perform mathematical operations
• Update storage
• Verify rules

Each of those consumes computational resources.
More complex interactions require more gas.

Example:

Sending tokens directly → low computation
Swapping on a DEX → medium computation
Complex DeFi strategy → high computation

Gas cost increases when:

• Many users are active
• Network congestion rises
• Blocks fill quickly

You are effectively bidding for execution priority.

Here is a simple example:

Imagine a block can only include 100 transactions. At that moment, 300 transactions are waiting in the mempool.

Some users are offering $1 in fees. Others are offering $3. Others are offering $10.

The validator will naturally select the 100 transactions that generate the highest total fees for that block.

If you offered $1 while many others are offering $5 or more, your transaction will likely wait.

If you raise your fee, your transaction becomes more attractive to include in the next block.

It is not personal preference. It is a market mechanism for allocating limited block space.

Now compare this with gas.

Imagine two users both offer the same fee per unit of gas.

User A sends a simple token transfer. User B interacts with a complex lending protocol.

Even if both offer the same gas price, User B’s transaction will consume more total gas because it requires more computation.

So two dimensions are at work:

• Gas determines how much computational work your transaction requires.
• Fee determines how competitively you are bidding for limited block space.

You can think of it this way:

Gas answers: "How complex is this action?" Fee answers: "How urgently do I want this action included?"

Why Transactions Fail

A failed transaction does NOT mean funds disappeared.
It means the smart contract stopped execution.

Common reasons:

1. Slippage protection triggered
2. Insufficient balance
3. No token approval
4. Deadline expired
5. Gas limit too low

When a transaction fails:

State changes are reverted.
But gas is still consumed.

Because the network still performed computation.

Pending vs Failed vs Finalized - States

Pending

Transaction is waiting in mempool.

Usually caused by:

• Low gas fee
• High congestion

Failed (Reverted)

Transaction was executed but conditions failed.

Gas spent. State unchanged.

Confirmed / Finalized

Transaction included in a block.

State permanently updated.

No undo button.

Where Does the State Actually Change?

In a traditional bank, when you make a transfer, a centralized database is updated.

The bank controls the database. The bank decides when the transaction is final. If necessary, the bank can reverse or modify entries.

In a blockchain system, there is no single database owned by one entity.

Instead, thousands of nodes maintain a synchronized copy of the same ledger.

When your transaction is included in a block:

• The block contains a list of transactions.
• Each node executes those transactions independently.
• Each node updates its local copy of the blockchain state.

The "state" means:

• Account balances
• Smart contract storage
• Token balances
• Protocol accounting variables

If all nodes reach the same result after executing the block, the new state becomes the canonical version of truth.

This is not a database update in one place.
It is a coordinated state transition across a distributed network.

Finality occurs when the network reaches consensus that this block is valid and part of the chain.

After enough confirmations, reversing that block would require enormous computational or economic cost, making it practically irreversible.

So the key difference is this:

A bank transaction updates one controlled database. A blockchain transaction updates a globally replicated state machine.

And once finalized, that state transition cannot be edited by any single authority.

Does My Old Data Still Exist After a Transaction?

This is an important conceptual difference between blockchain systems and traditional databases.

When a transaction changes state on a blockchain, the current balances and storage values are updated.

However, previous states are not "deleted" in the traditional sense.

Blockchains are append-only systems.

That means new blocks are added, but old blocks are not erased.

So two things exist at the same time:

1. The current state (latest balances and contract storage).
2. The historical record (all past transactions and blocks).

Your old balance does not remain active.

But the record of what your balance used to be is permanently part of blockchain history.

Every transaction is stored inside a block.
Every transaction is also public.

Even if your identity is pseudonymous, the transaction data amounts, addresses, contract calls can be inspected and analyzed by anyone.

Privacy in blockchain systems is not invisibility. It is pseudonymity. Every block references the previous block.

This creates an immutable chain of history.

If someone looks at a block explorer, they can:

• See your previous balances
• See past transfers
• See contract interactions
• Reconstruct how the current state was reached

What changes is the state.
What remains is the history.

In technical terms:

The blockchain stores a sequence of state transitions. Each block contains transactions that transform the state from one version to the next.

Nodes do not store "multiple active balances" for you. They store the latest state.

But they also store the full transaction history that explains how that state evolved.

So yes: the record of your old information remains in the blockchain history.

But no: it does not remain as an active balance.

This is why blockchains are described as immutable ledgers rather than editable databases.

Does the Blockchain Keep Growing Like a Database?

First Understand Node:

A node is any computer connected to the blockchain network that participates in maintaining, verifying, or accessing the ledger.

It runs blockchain software and follows the protocol rules to stay synchronized with the rest of the network.

In a traditional banking system, every transaction increases the size of the institution’s internal database.

The database grows over time as new records are inserted.

Blockchains grow in a similar structural way but with an important architectural difference
Blockchains are append only systems.

Every new block adds:

• A list of new transactions
• Metadata (timestamps, references, hashes)
• A reference to the previous block

This means the blockchain becomes larger over time as more blocks are added.

However, not every participant stores the blockchain in the same way.

There are different types of nodes:

Full nodes:

• Store the blockchain history
• Maintain and validate the current state

Archival nodes:

• Store the entire historical state at every block
• Used for deep analysis and historical reconstruction

Pruned nodes:

• Keep the latest state
• Discard some older intermediate data to reduce storage requirements

Light clients:

• Do not store full history
• Rely on cryptographic proofs from full nodes

The key distinction is this:

The blockchain’s history grows continuously. The active state remains a current snapshot derived from that history.

So yes: blockchain size increases over time.

But the network distributes storage responsibility across thousands of independent nodes.

There is no single expanding database owned by one institution.

Instead, storage and validation are decentralized across the network.

This architecture allows history to remain immutable while giving different participants flexibility in how much data they store.

What Happens If Billions of People Use Blockchain?

If blockchain size keeps growing, how can it support massive adoption?

Scalability does not come from making the base layer infinitely larger. It comes from architectural layering and role specialization.

• Layer 2 networks process transactions off the main chain and settle results back to it.
• Many users rely on light clients rather than running full nodes.
• Storage and validation responsibilities are distributed across the network.

The base layer prioritizes security and settlement. Higher layers improve speed and cost.

We will explore Layer 2 systems later in this series.

A Subtle but Important Detail: Finality Is Probabilistic

One additional nuance is worth mentioning.

When a transaction is included in a block, it is considered confirmed. However, in most blockchains, finality is probabilistic not absolute in the first second.

Very rarely, a block can be reorganized if the network temporarily disagrees on chain order.

This is why applications often wait for multiple confirmations before considering a transaction fully settled.

For everyday users, this is usually invisible. But conceptually, it reinforces an important idea:

Finality strengthens over time as more blocks are built on top of yours.

Technical Risk vs Economic Risk

Technical risk includes:

• Contract bugs
  Errors in the smart contract code can cause unintended behavior, frozen funds, or exploitable vulnerabilities.
• Failed execution
  The transaction runs but reverts due to unmet conditions, causing wasted gas and interrupted actions.
• Gas miscalculation
  Setting gas limits too low or misunderstanding fee dynamics can cause transactions to fail or remain stuck.

Economic risk includes:

• Price volatility
  Asset prices can change rapidly between the time you initiate and finalize a transaction.
• Slippage
  The execution price differs from the expected price due to liquidity depth and market movement.
• Liquidation
  In lending protocols, collateral value can fall below required thresholds, forcing automatic asset sales.
• Impermanent loss
  Providing liquidity can result in underperformance compared to simply holding assets when prices diverge.

Execution success does not equal financial success.

Common Beginner Mistakes

• Not leaving extra funds for gas
  Gas fees are always paid in the native coin of the network (for example, ETH on Ethereum). Even if you hold only tokens like USDT or USDC, you still need native coin to pay for execution. If you attempt to swap your full token balance without holding enough native coin for gas, the transaction will fail.
• Using wrong network
  Sending or interacting on the wrong blockchain network (for example, being connected to one network while the application expects another) can cause failed transactions or make assets appear missing.
• Signing multiple times when one tx is pending
  When a transaction is pending, it has a specific nonce (its order number). If you submit another transaction with the same nonce but a higher fee, it can replace the original transaction. This is how users speed up or cancel stuck transactions. However, panic-signing without understanding nonce behavior can create confusion or unexpected replacements.
• Panicking when seeing “failed”
  A failed transaction does not automatically mean funds are lost. In most cases, only gas was consumed and the state was reverted. Acting emotionally can lead to additional mistakes.
• Not checking block explorer
  Many users rely only on the application interface. If something looks wrong, checking a block explorer provides the authoritative record of what actually happened.
• Confusing interface error with blockchain failure
  Sometimes a website or RPC provider fails to load properly, but the transaction on-chain was successful. The blockchain is the source of truth, not the user interface.

Safety Checklist Before Every Transaction

Before signing, pause and ask:

• What exactly am I authorizing?
• Is this the correct network?
• Is the destination address the one I expect?
• Am I interacting with the correct contract (not a fake clone)?
• Is the fee reasonable for current network conditions?
• Do I understand whether this is a transfer, approval, or contract interaction?
• Could this approval grant ongoing permissions?
• Do I understand the economic risk of this action?

If you cannot clearly explain what this transaction does, who it interacts with, and what risk it carries, you should not sign it.

Closing Perspective

At this point, you should understand what a transaction is, how it moves through the network, how gas and fees work, where state changes occur, and why execution success does not guarantee financial success.

Transactions are the execution layer of DeFi. Every swap, approval, deposit, borrow, or vote is simply a transaction activating protocol logic.

In the next article, we will build directly on this foundation by exploring tokens how they differ from native coins, how ERC-20 standards work, and why approvals are required before contracts can move your assets.

Originally published on X · 2026-02-27