Jordan Hale: Alex, I have to tell you — I had this moment this week where I was trying to explain to my sister what a smart contract actually is, and I got about two sentences in and she just looked at me and said 'so it's just code,' and I could not, like, I could not articulate why that's wrong and also kind of right at the same time.
Alex Mercer: That's a genuinely hard thing to explain, and I think the difficulty is the right starting point for today.
Jordan Hale: Because 'just code' sounds safe and boring, you know, like, code has bugs, you patch them, whatever — but that's not how this works at all.
Alex Mercer: It is not. The DAO hack — 2016, seventy million dollars gone in minutes — that's the illustration your sister needs. The attacker didn't find a bug and exploit it. The contract executed perfectly. The code did exactly what it said. And seventy million dollars was unrecoverable by the time anyone understood what had happened.
Jordan Hale: Wait — so the problem wasn't that the code was broken. The problem was that it worked.
Alex Mercer: That's the core tension. And it traces back to a property called immutability — once you deploy a smart contract, the code is fixed. Cannot be altered, cannot be deleted. That's intentional. That's what makes it trustworthy. But it also means any error present at deployment is permanent. There is no pause button. Self-execution fires when conditions are met, automatically, no human approval required.
Jordan Hale: And this idea is — wait, how old is this actually? Smart contracts aren't, like, a 2015 invention?
Alex Mercer: Nick Szabo coined the term in 1994. He defined it as a set of promises specified in digital form, with protocols for parties to perform on those promises. The concept existed more than a decade before any infrastructure could run it.
Jordan Hale: So he invented the idea and then had to wait twenty years for computers to catch up to him.
Alex Mercer: More or less. Ethereum launched in 2015 and that's when it became real infrastructure — because the Ethereum Virtual Machine is Turing-complete, meaning you can write arbitrarily complex logic, not just simple if-then transfers. That's what turned Szabo's theoretical framework into something that could hold forty, seventy, hundreds of millions of dollars.
Jordan Hale: And the moment it can hold that much money, the fact that nobody can touch it once it's deployed stops being a feature and starts being — terrifying?
Alex Mercer: Both, simultaneously. Immutability is the promise — the logic executes exactly as written, no intermediary can interfere. And immutability is the trap — every error is locked in with the same finality. The DAO didn't teach us that smart contracts are flawed. It taught us that the thing we love about them and the thing that can destroy you are the same thing.
Jordan Hale: Okay but — that same-thing point is what I keep getting stuck on, you know, because I want a concrete image for it. And the one that finally clicked for me is — it's like a vending machine locked behind glass. You put in the right coins, the snack drops, no cashier anywhere near it. That's the whole design. But if the machine is wired wrong, it dispenses the wrong thing with exactly the same certainty, and nobody can reach inside to fix it.
Alex Mercer: That's the right image. And the glass is load-bearing — it's not decorative. The glass is what makes you trust the machine in the first place.
Jordan Hale: Right — but then what actually guarantees the snack drops? Like, what's the mechanism underneath?
Alex Mercer: The Ethereum Virtual Machine. The EVM is the runtime — think of it as the engine room. It runs the contract's code identically across every single node on the network. Not approximately identically. Identically. That identical execution across thousands of machines is what generates the trustlessness guarantee — two parties who've never met can swap digital assets because the result is agreed upon by consensus, not by any single authority.
Jordan Hale: Wait — every node runs the exact same code at the same time?
Alex Mercer: Every node. And they all have to get the same answer. That's the check.
Jordan Hale: So if the machine is wired wrong — to keep the analogy going — every node in the network is simultaneously watching it dispense the wrong snack, and they're all, like, confirming that yes, this is in fact the wrong snack being dispensed correctly.
Alex Mercer: Exactly. And that's — I mean, that's where Turing-completeness becomes the relevant thing. Before Ethereum launched in 2015, blockchains could only run simple logic. Turing-completeness, which the EVM introduced, means you can write arbitrarily complex conditions. The contract isn't just 'transfer ten coins if balance is sufficient' — it can be hundreds of interlocking rules. Which is what makes it powerful enough to hold real financial agreements. And it's what makes the wiring complicated enough to go wrong in ways that aren't obvious until someone's already lost money.
Jordan Hale: So complexity is — wait, no, the complexity isn't the enemy exactly, it's more that complexity is the thing that makes the glass-box valuable and the thing that makes it dangerous.
Alex Mercer: Right. And it all gets written in Solidity — that's the primary language, the thing a developer is actually typing before deployment locks it in. Once it's on chain, whatever Solidity said is what the EVM runs. Forever.
Jordan Hale: Picture someone — a developer, Saturday afternoon, deploying a liquidity contract — and they're checking the Solidity one more time, and everything looks right, and they hit deploy, and that's... that's the moment the glass seals.
Alex Mercer: That's the moment. And the auditors can have signed off, the logic can look clean — but if what the code says diverges even slightly from what the developer meant, the EVM doesn't care about the intent. It runs what's there.
Jordan Hale: And that's the thing I keep bumping into — because everyone sells this as 'no intermediaries, no gatekeepers,' but like... someone wrote that Solidity. Someone decided what the conditions were. So where did the trust actually go?
Alex Mercer: It got relocated. That's the precise word. You're not removing trust from the system — you're moving it from a bank regulator or a lawyer to the developer who wrote the Solidity, to the auditors who reviewed it before deployment, and to the language itself.
Jordan Hale: So different gatekeepers. Not fewer.
Alex Mercer: Exactly. And the dangerous part — I think this gets understated — is that the old gatekeepers were at least visible. You know who your bank regulator is. The developer who holds the deploy key? Often anonymous, or a three-person team with no legal accountability. That's not obviously safer.
Jordan Hale: Okay, make that concrete for me. Like, what does it actually look like when that relocation goes wrong?
Alex Mercer: There's a scenario that I think captures it almost perfectly. A DAO raises $40 million in a liquidity pool contract. The developer intends to cap withdrawals at 10% per day — reasonable risk control. But the Solidity has a typo in the timestamp condition. The code actually allows 100% withdrawal if the transaction hits before noon UTC. Contract deploys Tuesday. Someone notices Thursday. The fix itself? Two hours of work. But the contract has no upgrade mechanism — they chose immutability for credibility. By Friday morning, $8 million is gone, and the developer can see the exact line causing it and cannot touch it.
Jordan Hale: They can see it. They just — they can't do anything.
Alex Mercer: That's a business logic vulnerability. The code is not broken — it executed exactly as written. The EVM did its job perfectly. What failed is the gap between what the developer meant and what the Solidity actually said. And that class of flaw, specifically, tends to pass security audits because audits are scanning for syntax errors and known exploit patterns, not for whether the code encodes the right intent.
Jordan Hale: Wait — so you can have a clean audit and still lose $8 million?
Alex Mercer: Yes. The audit passed. The auditors weren't wrong — they found no known vulnerabilities, no syntax issues. The correctness problem is a different problem. And by 2019 there was academic documentation of mutation testing frameworks built specifically for Ethereum contracts — where you deliberately introduce small code changes to check whether your test suite catches them. The fact that this methodology had to be formally developed is, basically, the industry acknowledging in writing that pre-deployment correctness verification is essential because once you deploy, you cannot fix it.
Jordan Hale: So the formal answer to 'what if we encoded the wrong thing' is a whole testing discipline that nobody was using yet when the money was already on chain.
Alex Mercer: Formal verification can go even further — mathematically proving the contract satisfies a specification. But it requires serious expertise, and it can only verify that the code matches the spec, not that the spec matches what anyone actually wanted. The intent problem is not fully solvable. And there's a layer on top of all this — the 'fix' most teams reach for — that honestly makes the trust question even messier, and we'll get into exactly why those upgrade mechanisms reintroduce the very intermediaries the whole system was supposed to remove.
Jordan Hale: You know, I came into this thinking trustlessness meant something was watching out for you. Turns out someone is always watching — you just might not know who.
Alex Mercer: And that's exactly where the upgrade trap closes around you. Because the obvious fix — the thing every team reaches for — is just make the contract upgradeable. Proxy Pattern. You point a proxy contract at a separate logic contract, so you can swap the logic out after deployment.
Jordan Hale: Okay, that sounds — wait, that actually sounds fine? Like, that's just sensible engineering.
Alex Mercer: It is sensible. And it works. But now you have someone holding the key that controls which logic contract the proxy points to. One entity, or a multisig, with the power to change the code after users have already locked in funds. That is a trusted authority. That's the thing smart contracts were designed to eliminate.
Jordan Hale: So the fix to immutability is — you just re-hire the intermediary.
Alex Mercer: Functionally, yes. And the Diamond Pattern extends this further — one proxy pointing to multiple logic contracts simultaneously, more modularity, more flexibility. But higher gas costs than a simple Proxy Pattern. Which is the part that I think is genuinely perverse.
Jordan Hale: Wait — higher gas costs meaning what, exactly? Like, it costs more money to run the safer version?
Alex Mercer: Every transaction through an upgradeable architecture costs more to execute than through an immutable one. So you're creating a direct economic disincentive to adopt the mechanism that reduces your catastrophic deployment risk. Projects look at that overhead and skip the upgrade pattern to stay competitive on fees.
Jordan Hale: That's — no, I mean, that's genuinely insane. The price of safety is baked into the system as a reason not to buy it.
Alex Mercer: And timelocks, multisignature governance — those help distribute the authority, sure, reduce single points of failure. But a multisig is still a group of humans who can be pressured, compromised, or simply wrong. A contract that can be paused by a keyholder is not, in any meaningful sense, trustless.
Jordan Hale: So does the multisig actually reduce risk or does it just — like, move the risk to a different room nobody's watching?
Alex Mercer: It moves it. Think about my Tuesday lending contract scenario — logic error, users can withdraw more than they deposited. Three options: let it drain, try to convince users to migrate to a new contract voluntarily, or invoke emergency governance through a multisig. The third option works. But the moment you invoke it, you've handed a committee the power to rewrite a financial agreement that users trusted was immutable. That's a bank board meeting with worse PR.
Jordan Hale: You know what that sounds like? It sounds like every solution to the trust problem just — it generates a new trust problem one layer up.
Alex Mercer: That's the actual paradox. Every mechanism that makes a contract correctable quietly recreates the centralized authority the technology was built to escape. The upgradeability vs. finality trade-off isn't a solvable engineering problem — it's a structural contradiction in what the system is trying to be.
Jordan Hale: And then there's the part that — what if the code executes perfectly and you still have no legal recourse? Like, not because the law failed, but because the American Arbitration Association has actually published analysis saying smart contracts aren't always legally binding agreements in the traditional sense. They just... aren't.
Alex Mercer: That's the piece nobody wants to sit with. On-chain execution is not the same thing as a binding legal agreement. The AAA has noted that explicitly. Which means if the code and your intent diverge — if the Solidity said one thing and you meant another — there may be no court, no arbitration panel, no neutral arbiter with jurisdiction over what just happened to your funds.
Jordan Hale: So the loss just... lands on whoever the code disadvantages.
Alex Mercer: With no appeal. That's not a flaw in the implementation — that's the architecture. The trustlessness guarantee and the no-recourse outcome are the same design choice.
Jordan Hale: And every fix brings back a human with a key, which — I mean, that's exactly what Szabo was trying to design around in 1994. You know, the whole point was no trusted party. And here we are.
Alex Mercer: Every practical fix reintroduces centralized trust. That's probably the one thing I'd want someone to actually take away from all of this.
Jordan Hale: It's a genuinely uncomfortable place to land.
Alex Mercer: Yeah. Thanks for working through it — this one didn't resolve cleanly, and I think that's the honest result.
