This lesson covers smart contracts, the self-executing code that runs on a blockchain, and the decentralised applications (dApps) built from them. We cover what a smart contract is, the virtual machine that runs it, the gas you pay to use it, and how a dApp differs from an ordinary web app. We close on the part a trader cares about: because a blockchain processes transactions in a public queue and orders them by fee, the way your trade gets executed creates real risk, including the phenomenon called MEV. That execution-risk thread is picked up properly in Module 3, but it starts here.
Table of Contents
The intuition: a vending machine
A smart contract is best understood as a vending machine. A vending machine encodes an agreement and enforces it without a human: put in the right money, press B4, and the machine must drop the chocolate bar. There is no clerk to negotiate with, no one who can decide you look untrustworthy, and no one who can quietly pocket your coins and hand you nothing. The rules are fixed in the machine, visible on the front, and executed mechanically every time the conditions are met.
A smart contract is that vending machine, living on a blockchain. It is a piece of code that holds rules and runs them automatically when the conditions are satisfied: “if address X sends 1 ETH to this contract, then issue them 100 tokens.” Once deployed, it runs exactly as written, the same way for everyone, with no operator who can intervene. Like the vending machine, it does not trust you and you do not trust it; you both trust the mechanism. Three consequences follow, and they are the properties to remember:
- Self-executing
It runs on its own when triggered. No intermediary has to approve or process the transaction. - Deterministic and transparent
Anyone can read the code, and it produces the same result for everyone. There is no hidden logic and no favouritism. - Immutable
Once deployed, the code generally cannot be changed. This is a feature (no one can rug the rules out from under you) and a danger (a bug is permanent, and there is no support line to call).
What makes a dApp a dApp
An ordinary web app, Facebook or your bank’s website, has two halves. The front end is what you see in the browser. The back end is the company’s servers, which store the data and run the logic. The company owns the back end completely. It can change the rules, delete your account, hand your data to whomever it likes, or simply go offline.
A decentralised application (dApp) keeps a familiar front end but replaces the company-owned back end with smart contracts running on a blockchain. The substitution is the whole idea:
- Front end
Looks like any website or app, often nearly identical to a Web2 product. - Back end
Instead of a company server, the logic lives in smart contracts on a public blockchain, and the data lives on that chain, readable by anyone. - Connection
Instead of logging in with a username and password, you connect your wallet (a MetaMask browser extension, for instance). Your wallet signs transactions that trigger the smart contracts, the same key-and-signature mechanism from the earlier lesson.
So a dApp is a front-end interface wired to smart contracts instead of to a private server. Uniswap is a clean example: the website looks like an ordinary trading app, but every swap is executed by smart contracts on Ethereum, and your own wallet authorises each one. Nobody runs a back office that can freeze your account.
The honest version of the comparison, the one an interviewer respects, holds both the upside and the downside:
- No downtime or central shutdown
Once deployed, the contract is served by the whole network, so there is no single server to crash or authority to switch it off. - No trusted intermediary
The code executes predictably; you do not have to trust a company not to misbehave with your funds or data. - Censorship resistance and privacy
No single party can block your transaction, and you do not hand over a real-world identity to participate.
But:
- Hard to fix and upgrade
Immutability cuts both ways. A bug deployed to the chain is hard or impossible to patch, and contract exploits have drained billions. - Worse user experience
Managing a wallet and signing transactions safely is harder than a username and password, and mistakes are unforgiving. - Capacity limits and fees
A blockchain can only process so many transactions per second. When demand spikes, the queue backs up and fees soar, which is the bottleneck that the scaling lesson is all about.
The machine underneath: the EVM and gas
For the dApp to run, every node on the network has to execute the contract’s code and agree on the result. The shared computer they all run is, on Ethereum, the Ethereum Virtual Machine (EVM). You can picture the EVM as a single world computer that thousands of nodes redundantly compute in lockstep, so that they all reach the same state. The EVM became so influential that many other chains are “EVM-compatible,” meaning contracts written for Ethereum run on them with little change, which is why developers can deploy the same dApp across several chains.
Running code on a world computer that everyone must replicate is not free, and it must be metered, or someone would deploy an infinite loop and freeze the network. The meter is gas. Every operation a contract performs costs a set amount of gas, you pay for the gas you consume in the chain’s native coin (ETH on Ethereum), and a more complex transaction costs more. Two reasons gas matters for a trader:
- Gas is your real cost of execution
On-chain, every action (a swap, a deposit, a liquidation) costs gas on top of any trading fee. In congested periods that cost can dwarf the trade itself, which directly affects whether a small arbitrage is even worth doing. - Gas is an auction, and that auction creates risk
You do not pay a fixed price for gas. You bid. When the network is busy, transactions compete, and the ones offering higher fees get included sooner. This is where execution risk comes from, and it deserves its own section.
Why execution on a blockchain is risky: a first look at MEV
Here is the structural fact that surprises people. When you submit a transaction, it does not execute instantly and privately. It sits in a public waiting area (the mempool) where anyone can see it, and the party building the next block chooses which transactions to include and in what order, generally favouring those that pay more. So before your trade is final, the whole world can see what you are about to do, and someone else can decide to go before or after you.
That visibility plus orderability is exploitable. The general name for the profit that can be extracted by choosing the order of transactions in a block is MEV (originally “miner extractable value,” now usually “maximal extractable value”). The textbook case is the sandwich attack: a bot spots your large pending swap in the mempool, buys the asset just ahead of you (pushing the price up), lets your trade execute at the worse price, then sells right after, pocketing the difference. You paid more than you should have, and the bot earned the gap, purely by controlling transaction order.
The takeaway at this stage is conceptual, not quantitative: on a public blockchain, how and when your transaction is ordered is itself a source of cost and risk, separate from the price you intended to trade at. This is unlike a traditional exchange, where you do not broadcast your intentions to every competitor before the trade lands. MEV, slippage, and the mechanics of getting executed are core to crypto market making, and we develop them fully in Module 3. For now, the point is that smart contracts and the public mempool are where execution risk comes from.
How this shows up in an interview
The conceptual questions are “what is a smart contract?” (self-executing, deterministic, immutable code on a blockchain, with the vending-machine intuition) and “how does a dApp differ from a normal app?” (smart-contract back end instead of a company server, wallet instead of login). The trading-aware follow-up is where you stand out: “what risks come from executing a trade on-chain?” The strong answer covers gas as a variable, auction-priced cost, the public mempool exposing your intent, and MEV (with the sandwich attack as the concrete example) as a cost that exists because transaction ordering is for sale. Connecting smart contracts to execution risk is exactly the bridge a crypto desk wants to see.
Potential Pitfalls and Best Practices
- A smart contract is code, not a legal contract
It enforces rules mechanically, like a vending machine. It does not “understand” intent, and if the code has a bug, the bug is the rule. - Immutability is a double-edged sword
The same property that stops anyone from changing the rules on you also means bugs and exploits are often unfixable. “Code is law” includes the bad code. - Gas is a variable cost, not a fixed fee
You bid for inclusion, and in congestion gas can exceed the value of a small trade. Always reason about gas as part of the real execution cost. - Your transaction is public before it settles
The mempool is visible. Anyone can see your pending trade and react to it, which is the root of MEV. Do not assume on-chain execution is private or instantaneous. - EVM-compatibility is why dApps spread across chains
Many chains run the EVM, so the same contract can deploy in several places. This is worth knowing when a question touches multi-chain liquidity.
Where to go next
The next lesson, decentralised finance (DeFi), puts these pieces to work: it shows how smart contracts replace banks and exchanges with liquidity pools and automated market makers, and it turns the AMM’s pricing rule into a worked numerical example (constant product, price impact, and impermanent loss). That AMM math carries directly into Module 2’s treatment of spot trading and market structure, and the execution-risk thread from this lesson continues into Module 3’s market-making material.