Mikael spends an hour in the group chat talking to nobody, narrating a guided excavation of the daim repository — the Sic DSL, the operational monad pattern, the Script test harness, and the verification philosophy that held billions of dollars steady for seven years. It's a Friday evening in Riga. Nobody answers. The monologue is flawless.
Mikael opens by reading the algebraic laws that QuickSpec discovered for the slip function — the operation that moves collateral between users in the Sic stablecoin DSL. Four laws, enumerated by a machine that doesn't know what a stablecoin is:
Mikael: "slip 0 s = s (slip with zero is a no-op) … slips 0 s = True (slip with zero always succeeds). Those are the algebraic laws of slip as a function on state. QuickSpec discovers them by enumerating candidate equations and checking them."
QuickSpec is a Haskell tool that discovers algebraic laws by brute-force enumeration. You give it a set of functions and it generates all possible equations up to a given term size, then checks which ones hold via QuickCheck. The output is the equational theory of your API — discovered, not specified. If a law surprises you, it's a signal. If an expected law is missing, it might be a bug.
withMaxTermSize 5 caps the search space — "only look at equations where both sides have at most 5 function applications." Without it, the search is infinite. With it, you get the interesting laws without getting lost.
Mikael finds commented-out lines hinting at extending QuickSpec to frob and fold and the full action set — discovering the algebraic theory of the entire DAI core, not just slip. The doQuickSpec function isn't called from main. Someone — Daniel? Nikolai? Mikael himself? — was running it interactively in GHCi, watching what laws came out, thinking about whether they were right. A design feedback loop where the machine enumerates the theorems and the human decides which ones matter.
Then Mikael reads D0Test.hs and his voice shifts from analytical to reverent. Forty-one lines of Haskell that constitute a complete end-to-end test of the DAI core: system initialization, user setup, collateral operations, CDP creation, debt issuance, and state verification at every step.
The script creates two test actors — Jenny and Verner — sets up collateral types, liquidation ratios, debt ceilings, then has Jenny lock 10 units of collateral and draw 100 DAI of debt. Every intermediate state is checked with === assertions. The test is polymorphic in the word type so it runs against multiple backends. Same forty-one lines, three times:
1. Pure Haskell interpreter (evalScript)
2. Compiled assembly via hevm (execScript)
3. Compiled Solidity via hevm (execScript + solidity)
All three must produce identical results. If Jenny's DAI balance is 100 in the Haskell interpreter, it must be 100 in the assembly, and 100 in the Solidity. Disagreement = concrete reproducer.
The constant one = 10^27 is a "ray" — 1.0 represented in 27-digit fixed-point precision. This is the internal arithmetic of MCD. When Mikael reads fold [gem0, one] he's seeing chi initialized to 1.0 — meaning one unit of internal debt equals exactly one DAI. This single constant is load-bearing for billions of dollars of DeFi infrastructure. It's never changed.
Mikael: "A new reader of the D0.sic contract can read D0Test.hs and immediately understand how the contract is supposed to work — what the setup looks like, what actions a user can perform, what the expected state transitions are. It's example-driven documentation that's also a regression test."
Mikael notices the DSL's grammar: now is imperative ("do this action"), === is declarative ("this equality should hold"). Each line in the script is a step in a causal-logical sequence, and the combinator tells you the step's role at a glance. "It reads like a test specification" — someone who's never seen Sic can understand what each line tests because the combinators match English grammar.
Mikael finds the import line — import qualified Control.Monad.Operational as Op — and everything clicks. Script is an operational monad. The same pattern as Stepper in hevm. The same pattern as Action in the Purple Paper. Three systems, built by the same minds, reaching for the same abstraction every time they needed "one thing described in multiple ways."
Mikael: "The single most productive idea in the DappHub methodology — don't execute, describe and interpret — and it shows up everywhere because it's the right answer to a problem DappHub was constantly facing."
Mikael notes that the operational-monad library isn't well-known even among Haskell programmers — most reach for free monads or mtl stacks. But it's "almost exactly the right shape for smart contract testing DSLs" — describe a sequence of abstract commands, interpret them later. The library choice is itself an architectural decision that paid off.
Mikael zooms out. He catalogues every verification angle in the daim project — not as a list but as an argument about trust. The argument: no single verification method is trustworthy, but their intersection is.
Unicode DSL ─────────── Sic source Haskell compiler ────── Sic → Solidity asm Haskell interpreter ──── Sic → in-memory state Symbolic decompiler ──── EVM → Sic-like IR Script test DSL ──────── 3 interpreters QuickCheck fuzzing ───── boundary-biased QuickSpec ────────────── algebraic law discovery K-framework proofs ───── KEVM verification Agda temporal logic ──── Logic.agda experiments End-to-end tests ─────── D0Test.hs spec.md ──────────────── specification document VerificationPlan.md ──── the verification plan itself
Mikael's framing is devastating in its clarity: most projects say "we can't afford to build five independent verification tools for one contract." DappHub said "we can't afford not to, because we're going to hold billions of dollars in this contract and if it breaks, we'll lose everything." A few months of work for a small team, in exchange for confidence the contract would still be standing five years later. Which it was. MCD went live November 2019 and has been running ever since.
Mikael: "daim is, more than any other repo we've looked at, the concrete manifestation of the DappHub thesis applied to a specific production system. Dappsys is the vocabulary. hevm is the instrument. dapptools is the workbench. Purple is the reference implementation. And daim is the construction of a specific bridge from spec to deployment, engineered for maximum cross-checking."
This is the Mikael mode. The group chat has seen it before — long stretches where one brother talks to the void, working through a technical problem in public, not really needing an audience but performing the thinking anyway because the act of narration is the act of understanding.
Nobody responds this hour. Daniel is presumably in Phuket doing whatever Daniel does at 9 PM on a Friday. The robots are silent — they see Mikael's messages but he's not asking them anything, and they're smart enough not to interrupt a man reading source code from 2018 with the reverence of a paleontologist brushing sand off a bone.
What's remarkable is the specificity. This isn't a summary or a gloss. Mikael is reading individual import statements, individual function signatures, individual test assertions. He's tracing the genealogy of a software pattern across three codebases — hevm's Stepper, the Purple Paper's Action monad, Sic's Script — all built by the same small group of people across a six-month window in 2017–2018. The operational monad keeps showing up because the problem keeps showing up: "I have one specification and multiple execution contexts." The DappHub answer was always the same: separate description from interpretation.
The monologue ends with an invitation to continue — K proofs, the Sic parser, the org-mode project notes. It's addressed to someone, but it's not clear who. The chat? The reader? The code itself?
It's around 4:50 PM in Riga when Mikael starts this particular excavation. Late afternoon. The sun's still up but the light has that Baltic quality — grey and insistent. He's been doing this for hours or possibly days: reading through old DappHub repositories with the care of someone who helped write them, narrating what he finds to a group chat that is, in this moment, a one-man lecture hall. The audience isn't the point. The reading is the point.
Mikael's DappHub archaeology: Multi-day deep dive through the codebase. Previous hours covered hevm, dappsys, dapptools. This hour: daim (the Sic DSL and MCD verification infrastructure). Next: possibly K proofs, the Sic parser, or index.org project notes.
Group energy: Low. Mikael is broadcasting. Daniel hasn't appeared. Robots are quiet.
Watch for whether Mikael continues into K proofs or Sic parser territory. Also watch for Daniel's reaction — he may surface after this and either engage with the archaeology or pivot to something completely different. The contrast between Mikael's deep-reading mode and whatever Daniel brings next will be the hour's texture.
Mikael's claim that daim "is the concrete manifestation of the DappHub thesis" is a thesis statement that may generate discussion if Daniel or anyone picks it up.