Module 11 · Cryptography for Finance

Smart contracts and programmable value

So far the blockchain has recorded one kind of thing: who owns what. But once a decentralized network can agree on the state of a ledger, a tantalizing possibility opens up — what if the ledger could hold not just balances, but programs? Code that lives on the blockchain, runs exactly as written, and moves money automatically according to rules that no one can alter or stop. This is the smart contract, and it turns a system that records ownership into one that can enforce arbitrary financial agreements with no intermediary. You will run a real crowdfunding contract that pays out or refunds entirely on its own, then watch a contract with a bug get drained — and discover you cannot fix it, because "code is law" cuts both ways. Programmable value is the promise and the peril of this module.

33 minute read
8 sections
2 live demos
The Bitcoin stack · 4 of 4
6-question quiz
Section 01

From balances to programs

Everything in the Bitcoin stack so far has tracked one kind of thing: ownership. The ledger records who owns what; keys authorize transfers; consensus keeps everyone agreeing on the balances. It is a remarkable achievement — money with no central authority — but it is, in a sense, a single-purpose machine: a ledger of balances and nothing more.

Now take the idea one step further, the step that defines a whole second generation of cryptocurrency. The network already agrees, through consensus, on the exact state of a shared ledger. What if that shared state could include not just balances but code — small programs stored on the blockchain, which the network runs and whose results it agrees on, just as it agrees on who owns what? Then the blockchain becomes not merely a shared ledger but a shared computer: a machine, run by no one and everyone, that executes programs exactly as written, with results no single party can fake, alter, or stop. This is the founding idea of Ethereum and the platforms like it, often called a "world computer."

Those on-chain programs are smart contracts, and they change what a blockchain can do in a fundamental way. A ledger of balances can answer "who owns what." A ledger that runs code can answer "what should happen to this money when certain conditions are met" — automatically, with no human or institution in the loop to execute it. It turns money from something you merely hold and send into something you can program: value that moves itself according to rules, enforced by the same decentralized consensus that secures the coins. That is what "programmable value" means, and the rest of the module builds it, uses it, and breaks it.

A ledger that runs code

If the network can agree on the state of a ledger, it can also agree on the results of running code — turning the blockchain into a shared "world computer." The on-chain programs are smart contracts. They extend the system from tracking "who owns what" to enforcing "what happens to this money when conditions are met," automatically and with no intermediary — money that moves itself by rule. That is programmable value.

Section 02

What a smart contract is

The name is a little misleading, so let us be precise. A smart contract is not a legal document and not "smart" in any intelligent sense. It is simply a program stored on the blockchain that runs exactly as written. It has its own address (like an account), it can hold funds, it has internal state (variables it remembers), and it has functions that users call by sending transactions to it. When you call a function, every node in the network runs the same code on the same inputs, gets the same result, and updates the contract's state identically — so the network agrees on the outcome just as it agrees on balances.

Three properties make it powerful, and each comes straight from the blockchain underneath. It is deterministic and automatic: the code runs precisely as written, the same way for everyone, with no one able to intervene — if the conditions are met, it executes, full stop. It is autonomous: once deployed, it runs on its own whenever called, with no owner needed to approve or process anything; it is not hosted on a company's server that could go down or be coerced. And it is transparent and tamper-proof: the code is on the public ledger for anyone to inspect, and — crucially — once deployed it generally cannot be changed, because changing it would mean altering the blockchain, which consensus forbids. The contract will do what its code says, forever, exactly, no matter what.

Hold onto that last property, because it is the hinge of the whole module. The fact that a contract runs exactly as written and cannot be altered is precisely what makes it trustworthy — you do not need to trust a counterparty or an institution, only the code, which you can read and which cannot betray you by behaving differently than written. It is also, as we will see, precisely what makes it dangerous: if the code contains a mistake, that mistake is now permanent and unstoppable too. The contract's great strength and its great weakness are the same fact: it does exactly what it says, forever.

A program that runs as written, forever

A smart contract is a program on the blockchain with its own address, funds, state, and functions — run identically by every node, so the network agrees on its results. It is deterministic and automatic (runs exactly as written, no one can intervene), autonomous (no server or owner needed), and transparent but immutable (public to read, and generally unchangeable once deployed). It does exactly what its code says, forever — its greatest strength and its greatest danger.

Section 03

Run a contract — crowdfunding

Here is a real smart contract you can operate. It is a crowdfunding campaign: people pledge money toward a goal by a deadline. If the goal is reached, the funds go to the project creator; if not, every contributor can get a full refund. In the traditional world this requires a trusted escrow service to hold the money and enforce the rule. The smart contract is the escrow — it holds the pledged funds and enforces the rule automatically, with no one able to run off with the money or change the terms. Here is its logic, and below it, a working version you can drive:

// Crowdfunding contract — runs exactly as written goal = 100; deadline = block 5; pledged = 0; function pledge(amount) { // anyone contributes require(now < deadline); contributions[sender] += amount; pledged += amount; } function finalize() { // after the deadline require(now >= deadline); if (pledged >= goal) pay(creator, pledged); // goal met → creator paid else enableRefunds(); // goal missed → refunds }
Live demo · a crowdfunding smart contract

Pledge, reach the deadline, and watch the rule enforce itself

Goal: 100. Deadline: block 5. Pledge amounts, advance the blocks, then finalize — the contract pays the creator or opens refunds automatically, with no intermediary deciding.

📦 Contract holds: 0  |  goal: 100  |  current block: 1 / deadline 5
campaign open — accepting pledges

Notice what just happened: a financial agreement — "hold these funds and release them only if the goal is met by the deadline, otherwise return them" — was enforced entirely by code, with no escrow company, no bank, and no possibility of the organizer absconding with the money or quietly changing the rules. The contract held the funds and applied the rule mechanically. Every node ran the same logic and agreed on the outcome. This is the essence of a smart contract: an agreement that enforces itself, replacing a trusted intermediary with transparent, unstoppable code.

Section 04

What it makes possible

Crowdfunding is the simplest taste. The real significance of smart contracts is that any financial arrangement that can be specified as rules can be built as self-enforcing code, removing the intermediary that traditionally executes and guarantees it. This has grown into an entire parallel financial system, usually called decentralized finance (DeFi) — and it directly realizes, in code, several of the innovations the banking tracks described.

  • Lending and borrowing without a bank: contracts that let people deposit assets to earn interest and others borrow against collateral, with the terms, rates, and liquidations all enforced automatically by code rather than by a lender.
  • Exchanges without a broker: contracts that let people swap one asset for another directly, with prices set by formulas and pooled funds, rather than by a company matching buyers and sellers.
  • Stablecoins: the dollar-pegged tokens the banking innovation track discussed are, in many cases, governed by smart contracts that manage their collateral and maintain the peg by rule.
  • Automated agreements of all kinds: insurance that pays out automatically when a verifiable condition occurs, payments that release on delivery, recurring transfers, and far more.

Two features make this more than a list of apps. First, composability: because all these contracts live on the same open ledger and can call one another, they snap together like building blocks — the output of a lending contract can feed an exchange contract can feed a stablecoin contract — earning the nickname "money legos." Anyone can build a new financial product by combining existing contracts, permissionlessly, without asking anyone. Second, permissionlessness: there is no gatekeeper. Anyone, anywhere, can deploy a contract or use one, without an account, an approval, or an institution's blessing — the same censorship-resistant, open-access property that defined Bitcoin, now extended from payments to arbitrary financial logic.

This is a genuinely new capability, and it is easy to see why it generated enormous excitement: it promises to rebuild financial services — lending, trading, insurance, payments — as open, transparent, automatic code that anyone can use or extend, with no trusted intermediary required. Whether it fully delivers on that promise is another matter, and the honest assessment requires looking hard at how it fails, which the next sections do. But the capability itself is real and remarkable: finance as programmable, composable, permissionless software.

Self-enforcing finance

Any financial arrangement expressible as rules can become self-enforcing code, removing the intermediary — this is decentralized finance (DeFi): lending, exchanges, stablecoins, and automated agreements, all enforced by contracts rather than institutions. Two properties amplify it: composability (contracts combine like "money legos") and permissionlessness (anyone can deploy or use them with no gatekeeper). Finance as open, programmable software.

Section 05

"Code is law" — the promise

The phrase that captures the philosophy of smart contracts is "code is law." It means the contract's code is the final, complete authority on what happens — not a court, not a company's terms of service, not anyone's discretion. The rules are written in code, the code executes exactly as written, and the outcome is whatever the code produces, with no appeal and no override. To its advocates, this is the entire point and a profound improvement on the status quo.

Consider what the promise offers. In traditional finance, you trust an intermediary to follow the rules — and that trust can be betrayed: a bank can freeze your account, a broker can favor itself, an escrow agent can abscond, terms can be changed in fine print, and enforcement depends on courts and institutions that are slow, costly, and unequally accessible. With "code is law," none of that applies. The contract cannot betray you, favor one party, change its terms, or refuse to execute, because it is just code that runs as written, transparently, for everyone to verify in advance. You replace "trust that the powerful intermediary will behave" with "verify the code, then trust the math." For agreements between parties who do not know or trust each other, especially across borders and outside reliable legal systems, this is a genuinely powerful guarantee: the agreement will be kept because it must be, mechanically.

This is the same trust-without-a-trusted-party idea that opened the entire track, now applied to agreements rather than messages. Cryptography let strangers communicate securely with no trusted intermediary; smart contracts let strangers transact and contract with no trusted intermediary. The appeal is real and consistent: remove the fallible, possibly hostile middleman, and replace them with transparent, unstoppable code. But "unstoppable" and "cannot be changed" are double-edged, and the very next section shows the edge that cuts the other way — because if code is law, then a bug is law too.

Verify the code, then trust the math

"Code is law" means the contract's code is the final authority — it cannot betray you, favor a party, change terms, or refuse to execute, because it just runs as written. This replaces "trust the powerful intermediary to behave" with "verify the code, then trust the math" — the track's founding idea, now applied to agreements. Powerful for strangers transacting with no trusted middleman — but "unchangeable" cuts both ways.

Section 06

The double-edge: a bug is law too

Here is the dark side, and it follows inexorably from the strength. If a contract runs exactly as written and cannot be changed, then a contract with a mistake runs the mistake exactly as written and cannot be fixed. The immutability that protects you from a malicious counterparty also protects the bug from you. There is no customer service, no "undo," no patch — once deployed, a flawed contract is a flaw set in stone, often holding real money, waiting to be exploited.

See it happen. Below is a vault contract whose developer intended only the owner to be able to withdraw — but they forgot the check that enforces it. Read the code, spot the missing line, then deploy it (which freezes it forever, as deployment does). Now an attacker, who can read the public code just as you can, sees the missing check and simply calls withdraw. Try to fix the bug afterward and see what happens:

// Vault — meant to let ONLY the owner withdraw function deposit(amount) { balance += amount; } function withdraw() { // BUG: missing require(sender == owner); pay(sender, balance); // sends everything to whoever calls! balance = 0; }
Live demo · the unpatchable bug

Deploy a buggy contract, watch it get drained, try to fix it

The withdraw function forgot to check that the caller is the owner. Deploy it (freezing the code), then let an attacker call withdraw. Then try to patch the bug.

🏦 Vault balance: 100  |  status: not deployed (editable)

The attacker drained the vault by exploiting a missing check anyone could see — and you could not patch it, because a deployed contract is immutable. This is not a contrived scenario; it is the defining risk of smart contracts. Real contracts have lost staggering sums to exactly this kind of flaw. The most famous early example, "The DAO" in 2016, was an investment fund built as a smart contract holding the equivalent of tens of millions of dollars; an attacker found a subtle flaw (a "reentrancy" bug, where a withdrawal function could be tricked into paying out repeatedly before updating its books) and drained a third of the fund. The code did exactly what it was written to do — and what it was written to do was exploitable. Because code is law, the theft was, in a narrow sense, "legal" within the system: the attacker only used the contract as its code allowed. The strength became the catastrophe.

⚠️ Immutability protects the bug too
A smart contract runs exactly as written and cannot be changed — so a contract with a mistake runs the mistake forever, unfixable, often while holding real money. There is no patch, no undo, no support line. Attackers read the public code, find the flaw, and exploit it, and "code is law" means the exploit is permitted by the very rules. Real contracts have lost enormous sums this way, from missing checks to subtle reentrancy bugs like The DAO (2016). The same immutability that stops a malicious counterparty also shields the flaw from its own author.
Section 07

The honest picture: code, law, and the world

An evenhanded assessment of smart contracts has to hold several real tensions at once, beyond the bug risk. Three deserve naming.

First, the oracle problem. A smart contract can only see what is on the blockchain; it has no inherent knowledge of the outside world. An insurance contract that should pay out "if the flight is delayed" cannot itself know whether the flight was delayed — someone or something, called an oracle, must feed that real-world fact onto the chain. But then you are trusting the oracle, which quietly reintroduces exactly the trusted intermediary the contract was meant to eliminate. For anything touching the real world, "trustless" code rests on a trusted data source, and that seam is a persistent source of both centralization and exploits.

Second, complexity and scams. The permissionless, composable openness that makes DeFi powerful also makes it perilous: anyone can deploy a contract, including malicious ones designed to look legitimate and steal funds, and the composability that lets contracts build on each other also lets a flaw in one cascade through many. Ordinary users often cannot read the code they are trusting, so "verify the code" becomes "trust whoever audited it" — another intermediary, reintroduced. The space has seen enormous losses to bugs, scams, and exploits, alongside its genuine innovations.

Third, and deepest, the tension that The DAO ultimately exposed. When the attacker drained tens of millions, the Ethereum community faced a wrenching choice: accept that "code is law" and let the theft stand, or intervene. They chose to intervene — executing a hard fork that effectively rewrote the ledger to reverse the theft and return the funds. It worked, but it shattered the purity of "code is law": at the moment of crisis, a human community overrode the code by social consensus, proving that the ultimate authority was not the code but the people running the network. (A minority who disagreed kept the original chain, where the theft stood, as "Ethereum Classic" — so both philosophies literally still exist.) This is the honest heart of the matter: "code is law" is a powerful ideal, but when code produces an outcome a community finds intolerable, the social layer can and sometimes does override it — which both undermines the trustless ideal and, arguably, provides a crucial human safety net the pure version lacks. There is no clean resolution; it is a genuine, unresolved tension at the core of the whole enterprise.

Trustless code, trusted edges

Smart contracts face real limits: the oracle problem (real-world data must come from a trusted source, reintroducing an intermediary), complexity and scams (open, composable code is powerful but perilous, and most users can't audit it), and the "code is law" tension itself. The DAO hard fork showed a human community overriding the code to reverse a theft — undermining the trustless ideal but providing a safety net. A genuine, unresolved tension at the core.

Section 08

Two questions the whole track has postponed

The Bitcoin stack is now complete. Keys give ownership; the blockchain gives a tamper-evident ledger; consensus lets a leaderless network agree; and smart contracts make value itself programmable. From the four primitives of the first half, you have built up the entire technical foundation of cryptocurrency and decentralized finance. But two questions have quietly ridden along, unanswered, beneath everything — and they are exactly the right note to end the track on.

The first is privacy. Everything we have built is radically transparent: every transaction, balance, and contract interaction is public, replicated across thousands of nodes for anyone to inspect. That transparency is essential to how the system verifies itself without trust — but it is terrible for privacy, and finance often demands privacy. Is there any way to prove something is true — that you have enough funds, that a transaction is valid, that you meet a requirement — without revealing the underlying details? Astonishingly, yes: a beautiful and counterintuitive piece of cryptography called the zero-knowledge proof lets you prove a statement is true while revealing nothing beyond its truth. It is reshaping both blockchain privacy and scaling, and it sounds almost paradoxical until you see it.

The second is a threat hanging over everything in this track. All of it — the signatures protecting your coins, the public-key cryptography behind every secure connection, the certificates, the card payments — rests on certain mathematical problems being too hard to solve. But a fundamentally new kind of machine, the quantum computer, threatens to make some of those problems easy, which would break much of the cryptography the financial world runs on. How real is the threat, what exactly would break, and what is being done about it? The final module takes up both questions — zero-knowledge proofs and the quantum threat — the frontier of cryptography in finance, where the field is heading next.

Next module · the finale

Module 12 · Zero-Knowledge Proofs and the Quantum Threat

The frontier, and the close of the track. Zero-knowledge proofs — how you can prove something is true while revealing nothing else, and why that is transforming privacy and scaling in finance — and the quantum threat: what a quantum computer could break, what it could not, how worried to be, and the post-quantum cryptography being built to withstand it. Where the cryptography of finance is heading. With live demos, as always.

Self-examination

Test your understanding

Six questions on smart contracts — what they are, what they enable, "code is law," the immutability double-edge, and the honest tensions. The questions test the concepts you just saw in action.

Module 11 · Self-examination