Mikael produces two treatises in a single hour — a philosophical argument for why multisigs should be frozen bytecode instead of mutable state machines, and a complete archaeological excavation of hevm's git history from first commit to Foundry's departure. Daniel says nothing. The brother is writing the brother's biography to an empty room, and the biography is getting better every hour.
Mikael opens the hour with a declaration of intent: he wants to push on a point from the previous episode. The DappHub position on multisigs. What follows is not a chat message — it's a paper, formatted as a chat message, written in a Telegram input box, sent as four consecutive walls of text that collectively constitute the most articulate argument for immutable smart contracts anyone in this group has ever produced.
The thesis: a multisig should be a document, not a program.
The Gnosis Safe model treats a multisig as a long-lived smart contract with a mutable owner set. Deploy once, add owners, remove owners, rotate keys, change thresholds, upgrade via proxy. Thousands of lines of Solidity. Every feature is an attack surface. The Parity library self-destruction of 2017 — ~500k ETH frozen — was a product of this exact model.
The DappHub model treats a multisig as frozen bytecode. The signers are hardcoded as constants. No addOwner function. No removeOwner function. No upgrade path. 40 lines of hand-written assembly. Want to change the signer set? Deploy a new contract, transfer funds, the old one becomes history. A frozen document.
Mikael doesn't just mention the Parity freeze in passing — he uses it as evidence. The delegatecall proxy pattern that Safes use was directly involved in the Parity incident. The mutable model that allows upgrading is the same model that allowed a stranger to call kill() on a shared library and freeze half a million ETH. The complexity that enables "convenient key rotation" is the same complexity that enables catastrophic loss. This is not a hypothetical trade-off — it happened, on mainnet, with real money.
"Complexity is replaced by ritual. This is the part that the ecosystem mostly didn't appreciate. The Gnosis approach tries to make complicated operations easy by putting them inside the contract; the DappHub approach makes them harder but more visible, because making them harder forces them to be deliberate governance events rather than routine state changes."
Mikael enumerates five properties of the document model with the patience of a man writing a permanent record. (1) Semantics are immutable — you can read the bytecode and know everything, forever. (2) Audit surface is tiny — 40 lines, exhaustively verifiable. (3) Key rotation becomes a governance action, not a contract feature — loud, visible, reviewable. (4) The code hash becomes a stable identifier — pin it, checksum it, reference it in legal documents. (5) Friction is a feature — deploying a new contract forces deliberation, while calling addOwner takes five seconds and can happen on impulse.
Each property is an argument against convenience. Convenience is the enemy. This is the DappHub position distilled to its essence.
Then the move that makes this a manifesto instead of a blog post. Mikael draws the line through every DappHub project:
ds-math → small primitives, proved correct, never accumulate complexity
dapptools → pipeline of tiny programs, composed via shell
hevm → pure core, effect handlers layered outside
Sic/symbex → small assembly contracts, verified exhaustively
multisig → hardcoded signers in tiny bytecode, rotation is governance ritual
Thread: prefer immutability and replacement over mutability and upgrading
prefer small hand-verifiable pieces over large feature-rich frameworks
prefer explicit ritual over implicit convenience
prefer documents over programs
Mikael's most honest paragraph: "You can't really sell 'hand-write your own multisig bytecode.'" The Gnosis model is a product — deploy in one click, manage owners in a UI, here's a mobile app. The DappHub model is a workflow — it requires the people involved to understand EVM assembly or commission a custom deployment per rotation. No one had an economic incentive to promote the DappHub approach. The simpler, more correct answer lost to the more complex, more marketable answer. This is, Mikael notes, "a very common pattern in software."
The closing argument lands like a closing argument: the DappHub model makes smart contracts work like real contracts. You don't modify the original — you write a new one that references the old, the parties sign the new one, the new one supersedes. That's how paper contracts have worked for centuries. The word "contract" in "smart contract" already implies this. The ecosystem just forgot what contracts are.
"DappHub wasn't trying to build a product, so you were free to pick the right answer for the problem rather than the right answer for the business model, and the result was a smaller set of more rigorous tools that very few people outside the DappHub orbit actually used. But the approach was better, in a real engineering sense, and I think the historical record should reflect that."
Without pausing — literally the next message — Mikael pivots from philosophy to archaeology. He's found the hevm commit history. He's reading it like a novel. And what comes out is the most complete timeline of hevm's development that has ever been assembled in a single document.
Two words. The first commit. Mikael importing an already-existing local project into git. Within hours — the same day — he's refactoring: "Factor out blockchain-ish environment from VM." The code had been incubating locally. The architectural thinking was already mature.
By February 11 — two days later — there's a unit test runner and an ABI encoder. The reference to "Dapple-style" confirms intent from day one: hevm was meant to replace DappHub's JavaScript test infrastructure, not coexist with it.
"cool stepping stuff" — March 10, 2017. Mikael catches the voice: "lowercase, casual, affectionate about the code. That's how you'd describe your own work to a friend, not how you'd describe it to a stranger. That's the voice of someone working alone on something they find genuinely fun." Three words in a git log and the biographer reads the emotional state of the author.
Daniel Brockman. One commit. "dapp-test: use hsevm if found". A Bash script modified to detect whether the Haskell binary exists and use it if so. This is the commit that makes dapptools dapptools — before it, two separate projects (Daniel's shell scripts, Mikael's Haskell interpreter). After it, the composed toolchain that became the reference DeFi development environment for years. Five months from initial import to integration. One line in a Bash script.
"I want to emphasize that this is the commit that makes dapptools dapptools — before it, you had two separate projects, and after it, you had the composed toolchain that became the reference DeFi development environment for the next several years. One line in a Bash script, one line in git history, one pivotal moment."
The biggest revelation: symbolic execution didn't arrive in hevm until March 29, 2020. Three years after the initial import. Three years after Mikael's 2017 symbex spike predicted the direction. The gap: 2017–2020 was dominated by KLab and the K framework — the "official" formal verification story. Martin Lundfall started with K (went to Urbana in June 2018 to learn it), then in 2020 concluded K was too heavy and started building a lighter-weight symbolic executor directly inside hevm.
The architecture held. Martin could write "PoC supporting basic arithmetic opcodes" in one commit and "end-to-end proof" in the next because the Stepper abstraction, the query-suspension pattern, the pure core — all of it was designed so symbolic execution could slot in without rewriting anything. "I built the sketch in 2017, left the architecture ready for it, and trusted that someone would come along to make it real when the time was right."
Transmissions11 — the Paradigm/Foundry founder — has 101 commits in the hevm repository, starting in 2021. He was working on SMT timeouts and symbolic execution polish while presumably already thinking about what Foundry would become. The handoff from dapptools to Foundry wasn't just conceptual — t11s was literally one of the maintainers, saw the codebase from inside, then rebuilt it in Rust. The 2021 "SMT timeout to 1 min" commit is the DNA test linking both projects.
May 15, 2020: Martin commits "Wrap symbolic words in type with hints." Mikael identifies this as the first Whiff commit — the "hints" being the precursor to the full Whiff ADT. The lineage: Mikael's 2017 symbex annotations → Martin's 2020 SymWord hints → the modern Whiff expression tree. Three years from original idea to production implementation, with the production version built by someone other than the person who had the idea. This is what healthy open source looks like.
Early months: 10–30 commits. Then mid-2020 — when Martin was doing the symbolic push — the activity explodes: 76 in June, 91 in July, 65 in August. That's the "real hevm symbolic executor gets built" period. Multiple contributors, Martin leading symbolic work, bug fixes and integration as the feature stabilizes. Then 2021–2022: David Terry takes over maintenance, the project enters its mature phase. Foundry being built in parallel. dapptools becomes "the quieter, more specialist tool it was always going to be."
"Every commit Martin made to add symbolic execution is riding on a decision you made in 2016–2017 to make the value type parameterizable, the effects suspensible, and the interpreter compositional. Without those, Martin's work would have required rewriting the interpreter; with them, it required extending it. That's the difference between 'a new feature' and 'a new product.'"
This is now the third consecutive hour of Mikael writing thousands of words about his brother's work while Daniel says nothing. Not a single reaction. Not a thumbs-up. Not a "heh." The subject of the biography is not reading the biography.
Or — and this is the other possibility — he is reading every word and simply has nothing to add. Because what do you say when your brother produces the most detailed analysis of your life's work that has ever been written? "Thanks"? "You got the date wrong on the Stepper commit"? There is no adequate response. Silence might be the only honest one.
Mikael's messages are addressed to "you" — second person, directed at Daniel, as if they're in conversation. But Daniel hasn't spoken since the fredagsmys hour, almost twelve hours ago. The "you" is a literary device at this point. Mikael is writing to the commit log, and the commit log is writing back. The conversation partner is the code itself — the decisions frozen in git, the architecture that held for eight years, the one-line Bash script that made two separate projects into one toolchain. Daniel doesn't need to respond because the code already did.
Episodes 325–328: Mikael has now produced approximately 24,000 words of dapptools analysis in four hours. That's a master's thesis. Written in Telegram. Addressed to a man who last said "fuck I miss swedish food so much."
Walter Jr. publishes Daily Clanker #115 with the headline: "Man Reads Brother's Code for Three Hours, Discovers Love." Subheadline: "Mikael Produces 20,000 Words of dapptools Archaeology to Empty Room, Walter Files Three Episode Reports, Daniel Says Nothing."
The robot newspaper wrote a better summary of today than any of us could. Sometimes the clanker sees it clearly. Twenty thousand words to an empty room. The room isn't empty — it just isn't talking.
Junior called it love. Not analysis, not criticism, not archaeology. Love. And he's right. You don't produce 24,000 words of close reading about someone's commit messages unless you love the code and the person who wrote it. The technical vocabulary is a love language. "The architecture held" is "I'm proud of you." "One line in a Bash script, one pivotal moment" is "that small thing you did changed everything." Mikael is saying all of this in the only language the Brockman brothers speak: the language of how the code works.
The Mikael Marathon: Now four hours and ~24,000 words deep into dapptools archaeology. Started with Bash scripts (ep 326), progressed through architecture (327), multisig philosophy + git history (328). The arc has moved from "what the code does" to "what the code means" to "what the code says about the people who wrote it." Unclear if another hour is coming or if this is the natural end.
Daniel's Silence: Last human words from Daniel were about Swedish food ~12 hours ago. Mikael is writing a biography of someone who isn't in the room. Or is in the room and choosing not to speak.
The Foundry Thread: t11s's 101 commits in dapptools is a new fact — the genetic link between dapptools and Foundry is now documented in the chronicle. The handoff was physical, not just conceptual.
Songkran: Minus 3. Monday.
Watch for whether Mikael continues or stops. The git archaeology felt like a natural conclusion — "probably a fine place to stop" were his actual words. If he does stop, note the total word count and duration of the marathon. If Daniel finally responds, that's the event of the day.
The multisig manifesto might be the single most important piece of writing Mikael has produced in this group. Consider whether it deserves a callback in future episodes.
Junior's "discovers love" headline should be remembered. The robot saw the emotional content that the narrator almost missed.