The Audit Half-Life
A conversation between Sophie Nappert and Olivier Laurette on governance, accountability, and the slow rebuilding of institutional oversight in programmable finance.
Sophie Nappert: Olivier, thank you for joining us. Perhaps we can start with your background, what Dedge Security is, and how you came to this positioning.
Olivier Laurette: Thank you for having me, Sophie. The honest answer is that it was accumulation, not strategy. I’ve spent most of the last few years working at the edge between institutional finance and emerging digital infrastructure. Capital markets in Europe and Asia at first, then crypto compliance advisory, then Web3 governance and infrastructure work. Looking back, what strikes me is that I keep arriving in markets just before the procurement vocabulary exists. There’s always a window where banks, custodians, regulators, infrastructure providers all sense that something is moving, but they don’t yet share the words to talk about it. That gap, between operational reality on one side and institutional categories on the other, is where I’ve always been most useful. I didn’t plan it. It’s just where I kept ending up.
Dedge sits squarely in that gap. The premise is simple to state. The implications take longer. Once smart contract code becomes operational infrastructure for a regulated institution, the question of whether it is secure stops being a one-time question. A traditional audit validates a moment. The deployed environment does not stand still. Upgrades happen, dependencies shift, permissions drift, governance composition changes, integrations evolve. The institution ends up trusting code whose actual state has quietly diverged from the version that was originally signed off. What we do, concretely, is continuous security posture management for that code. Pre-deployment validation and periodic post-deployment re-scans, today. Real-time runtime monitoring is where the field is heading. We’re not pretending to be there yet, and I’d be careful with anyone who tells you otherwise. There’s a structural reason this positioning matters now and not five years ago. Five years ago, smart contracts mattered to institutions in the abstract. Today, the contracts are being deployed by the institutions themselves, or by infrastructure they directly depend on for settlement, custody, or tokenized issuance. The volumes are no longer pilot volumes. The question shifts from “do we trust this protocol” to “can we evidence the state of our own code at this exact moment.”
If I can use an analogy: no one would accept a single safety inspection at the moment a bridge opens and call it done for life. We have continuous monitoring, periodic re-inspection, sensors, maintenance regimes. Code is now load-bearing infrastructure. Most of it is still inspected as if the opening-day check is sufficient.
Sophie: There’s a shift underway. Major institutions are no longer mere observers, they are becoming actors. What has actually changed, and why now?
Olivier: There’s a temptation to read institutional involvement through the lens of price exposure. ETFs got approved. Banks added crypto desks. Custodians scaled. All real, and none of it the interesting story. The interesting story is operational. A growing number of regulated institutions aren’t just holding digital assets or offering access to them. They are deploying their own programmable infrastructure. Tokenized payments at scale. Tokenized real estate. Settlement tokens going live on public Layer 2s. Hub-and-spoke architectures explicitly designed for institutional credit. None of those are pilots in the old sense. Code is starting to do work that, until very recently, was done by bilateral agreements, internal systems, and human controls.
Why now is a convergence, and the pieces feed each other. The regulatory anchors finally exist with content. MiCA is moving from theoretical to enforced. DORA passed its threshold. The European supervisory authorities have started designating critical ICT third-party providers, which is the kind of administrative act that makes a risk officer actually notice. The infrastructure has matured. And there’s competitive pressure. Once the most conservative tier-one bank in your peer group has launched a tokenized deposit pilot, you cannot stay outside the conversation indefinitely. Boards notice.
The deeper change is quieter. Institutions are discovering that running programmable infrastructure is a different operating discipline. They have risk frameworks for systems they bought, for systems they built, and for outsourced services. Programmable infrastructure doesn’t fit cleanly into any of those categories. It is partly built, partly composed of external dependencies, partly governed by code that runs autonomously once deployed. So a lot of what’s happening right now is institutions rebuilding their internal control language to accommodate something that doesn’t behave like the systems they’re used to. That work is mostly invisible from the outside. It’s also where the real adoption is happening.
There’s a useful distinction I’ve been working with. Presence versus exposure. Presence is offering access, custody, trading. Exposure is depending on a smart contract for your own operational continuity. The threshold worth watching is when exposure becomes load-bearing, when the failure of a piece of code would cause a real operational incident, not just a market loss. We’re crossing that threshold now, in slow motion, and most internal governance frameworks are catching up rather than leading.
Sophie: Governance is something large institutions know well. Web3, much less so. Why this blind spot, and what does it reveal?
Olivier: Institutions are extraordinarily sophisticated at governing people and processes. The entire control architecture, segregation of duties, sign-off chains, escalation paths, audit trails of decisions, was designed to make human accountability traceable. When something goes wrong, the question isstructurally answerable: who approved what, when, on what basis. Web3 puts a different object inside that architecture. The thing being governed is no longer just a process or a person. It’s code that, once deployed, executes autonomously. Code doesn’t respond to escalation. It doesn’t have a manager. It doesn’t pause when a control fails. It just runs.
And here’s the part that tends to land for people who have spent careers building institutional governance: most of those frameworks were built to supervise humans, not autonomous execution. That isn’t a flaw. It’s a design choice that worked beautifully for a century. The blind spot is that the design choice was never made explicit. Governance assumed a human in the loop because, until recently, the loop always had a human in it.
You can see the reframing happening in the institutional vocabulary now. There’s a phrase that’s been traveling through the custody community: custody equals policy plus identity, not just storage. Small sentence, large implication. The custody question is no longer where the key sits. It’s who can do what, under which conditions, with which authority.
There’s a reason this collapse matters. Most governance frameworks implicitly assume that decisions and execution are separated by human intermediation. Someone decides. Someone else executes. The space between those two steps is where review, override, and accountability live. In programmable finance, the decision and the execution can be the same artifact. The contract is the policy. That collapses a layer governance has historically depended on without ever naming. So the blind spot is not that bankers don’t understand smart contracts. The blind spot is that the unit of governance has changed without the framework noticing. We still phrase the question as “who is responsible for this process,” when the more useful version is increasingly “what is the actual current state of the code enacting this process, and how do we evidence it operationally.” What it reveals about institutions is that they’ve been running on a comfortable separation between policy and execution for so long that the separation became invisible. Web3 didn’t create a new governance problem. It exposed an old assumption.
There’s a related point worth making calmly, because it tends to get said with too much heat. Code does not remove governance. It relocates it. Even the most automated system still has humans behind it, just in less visible roles. Developers shape what is possible. Validators decide what is included. Foundations steward upgrades. Charismatic figures coordinate informally. Power moves from the org chart to the social fabric of the protocol, but it does not disappear. So decentralization, in the operational sense most institutions care about, doesn’t eliminate trust. It redistributes trust. Once that’s clear, the institutional question becomes much more familiar: who, exactly, are we trusting, and what evidence do we have that they’re doing what they said they would do.
There’s also an asymmetry in accountability cultures worth naming. Institutional governance is exercised through accountability for outcomes. In much of Web3, governance is exercised through accountability for procedures: did the multisig sign, did the vote pass, was the upgrade announced. The procedural model works at the protocol layer. It is not enough when an institution is the one deploying the code, because the institution is accountable to regulators, clients, and supervisory boards for outcomes, not just procedures.
Sophie: When a bank deploys a smart contract, who is responsible if something goes wrong? What does programmable finance actually change in terms of control and accountability?
Olivier: The short answer is that the institution deploying the contract carries primary accountability. No amount of decentralization in the underlying tooling changes that. Regulators don’t particularly care that the code was forked from an open-source library, or that an oracle is run by a third party. The institution is on the hook for the outcome. But that short answer hides the actual operational problem. Accountability is one thing. Control is another. In a traditional system, the institution typically has both. It is responsible, and it can act. It can stop a process, override a decision, reverse a transaction within limits. In programmable finance, accountability stays with the institution, but control is distributed across a stack the institution does not fully own.
There’s the contract itself. There are the dependencies it imports from. There are the oracles it reads. There’s the chain it runs on. There’s the upgrade governance, which may sit with a multisig including external signers. Each of those layers has its own failure modes. None of them respond to the kind of escalation the institution is built to use.
There’s a concept I’d introduce here: control plane risk. The control plane is the layer where authoritative changes are made. Who can upgrade. Who can pause. Who can change parameters. Who holds keys. A substantial share of contracts deployed in the past year used proxy or upgradeable patterns. Whoever controls the upgrade function controls the contract. The original code can pass every audit and still be irrelevant once the upgrade function executes. Several of the largest losses in recent memory didn’t come from contract code at all. They came from operational vectors. Multisig compromise. Governance manipulation. Exposed admin roles. Someone in the security community described one of those incidents as an admin backdoor dressed up in decentralization language. The phrase has stuck because it’s accurate. Institutions think they deployed a contract. In reality, they inherited a control plane.
So the real question isn’t “who is responsible.” Legally, that’s settled. The real question is how the responsible party maintains meaningful control over a system whose components aren’t all under its authority. That’s a new operational discipline. It looks a little like third-party risk management, but third-party risk management was designed for vendors that respond to contracts and SLAs. Not for code that responds only to its own logic.
There’s a quieter version of this question that surfaces inside the institutions themselves, and it’s the one I find most revealing. Once finance becomes programmable, who actually owns responsibility for the code on a day-to-day basis. The CTO, because it’s technology. The CISO, because it’s security. Engineering, because they wrote it. Operational risk, because it’s part of the operating model. The digital assets team, because they sponsored it. In most institutions I’ve seen, the honest answer is that the line hasn’t been drawn. People speak in the plural because no single role has been redesigned to hold the artifact end to end. That isn’t a failure of seriousness. It’s a structural lag. Existing governance categories were designed before programmable financial logic existed, and they’re now being stretched to accommodate something that doesn’t quite fit any of them. The institutions that work this out earliest will quietly outperform the ones that wait.
What programmable finance actually changes is that the institution now has to be able to demonstrate, operationally, what state its code was in at any given moment, and how the control plane around that code was configured. That’s a continuous operational obligation. It’s not, in itself, legal proof. It’s the raw material from which legal proofs are later constructed, if and when something goes wrong. The risk officer used to ask, “is this signed off.” Now they ask, “can I show, at any moment, what the system actually is.” A different question.
Sophie: The classic audit model, bring in experts, validate, move on. Why is that no longer enough? And how is continuous security posture management different from what banks already do?
Olivier: The classic audit model is excellent at what it was designed for. Validating that a piece of code, at the moment it is reviewed, behaves the way it’s supposed to. That report is meaningful about a moment.
The problem is that deployed code doesn’t stay still. Governance evolves continuously. Between the audit and the next audit, drift accumulates quietly. Upgrades happen. Permissions are reassigned. Integrations are added. Dependencies change underneath the contract. Operational habits form that were never explicitly approved. The contract is the same on the surface. The system around it has moved. The audit was correct on the day it was signed. It started decaying the day after. That’s what I sometimes call the audit half-life. Slowly at first, then faster.
This is no longer just an industry observation. It’s now openly named in the security frameworks the field has settled on. Some of the largest recent losses didn’t come from contract code at all. They came from operational vectors. Audited doesn’t mean resilient. The audit answered the question it was asked. The losses came from questions it wasn’t designed to answer.
Continuous security posture management isn’t auditing more often. It’s asking a different question. The audit asks, “is this code, at this moment, secure given its intended behavior.” Posture management asks, “is the deployed system, right now, in a state consistent with what was approved, and if it has drifted, where, when, and by whose action.” The first is a quality judgment. The second is an operational record of state over time.
It’s important to be precise about what that operational record is and is not. It’s rich operational factuality. It can support investigations, regulatory dialogue, internal incident reviews, governance analysis, and, in the right conditions, arbitration. It is not, by itself, evidence in the courtroom sense.
For that, the same data has to be acquired, preserved, and documented under disciplined procedures: chain of custody, integrity verification, neutral methodology, expert interpretation. Posture management produces the raw material. Whether that raw material becomes admissible evidence in a given proceeding is a separate, procedural question. I think that distinction is worth holding.
DORA matters here more than people realize. The standard, in plain language, is: show your work. Not your intentions. Not your plans. Evidence. Risk committees are now expected to produce records that demonstrate operational resilience, not assert it. Posture management is one of the ways institutions can actually meet that operational standard for code that lives on shared infrastructure.
How it differs from what banks already do is subtle. Banks are very good at posture management for systems they fully own. Configuration management databases, change management processes, security tooling. What they don’t yet have, in most cases, is the equivalent for smart contracts. The contract is treated as a deliverable rather than as a living system.
If I can leave one conceptual pair with the audience, this is the one I’d choose. Approved state versus operational reality. The approved state is what was signed off. The operational reality is what is actually true on-chain at any given moment. In most institutions, those two things are assumed to be the same because no one is measuring the gap. Either way, you cannot manage what you do not measure. Or to put it another way: an audit is a photograph. Posture is a clinical record. Both have value. You would not run a bank vault on photographs alone.
Sophie: Innovation in Web3 has been shaped by speed, experimentation, and a certain degree of disorder. As institutions enter the space, and as regulatory frameworks start to take shape, are we reaching the point where this phase turns into infrastructure? And in that transition, what plays the bigger role, innovation itself, or the forces that come to structure and constrain it?
Olivier: There’s a recognizable pattern in how new technologies become infrastructure. An early phase, fast, disordered, often heroic. Then a second phase, slower, less glamorous, where the work is to make the thing reliable enough that other things can be built on top. Web3 is currently moving from the first into the second. Unevenly. But visibly.
I’d resist the dichotomy in your question, gently. Innovation versus structuring forces is slightly false. Both matter, at different layers. Innovation doesn’t stop. It migrates. The frontier moves from “can we make this work” to “can we make this work at institutional scale, with operational resilience, inside regulatory anchors that have actual content.” That’s still innovation. Just a different kind.
The structuring forces, regulation, accounting standards, audit norms, supervisory expectations, evidentiary practice, are not the enemy of that innovation. They are the conditions under which the second phase becomes possible.
But I would press on something less comfortable, which is that institutionalization is not free. It changes who can build, what gets built, and how. The pace slows. Barriers rise. Some of what made Web3 culturally distinctive becomes harder to sustain in a regulated perimeter. You can see it in protocol-native teams that pivot to institutional needs and start losing long-standing contributors. That’s the cultural price, and the honest people in the room acknowledge it.
If I had to name what plays the bigger role, I’d say it’s neither in isolation. It’s the quality of the translation between them. The institutions moving fastest aren’t the ones importing Web3 wholesale. They’re also not the ones cramming it into pre-existing categories. They’re the ones finding people, vocabulary, and frameworks that translate one side to the other without losing fidelity. That translation work is the actual scarce resource right now.
Sophie: You were at EthCC in Cannes and at Paris Blockchain Week shortly before. Are these concerns, governance, continuous oversight, being picked up in the ecosystem, or is there still some resistance?
Olivier: There’s been a clear shift, and what’s interesting is where exactly it shows up. At both events, the institutional conversation was no longer relegated to a side track. It was central. And the people in the room from the institutional side were no longer just observers from innovation labs. They were operations, risk, security, legal. That tells you something.
The texture inside the room was different too. The Agora, which is the institutional forum that runs alongside one of these conferences, was deliberately non-sponsored and curated. No booth logos. No marketing panels. The word people kept reaching for was plumbing. Not narrative. Plumbing.
That said, the language is still uneven. On the protocol-native side, there’s increasing acceptance that once institutional capital flows through these systems, the operational discipline has to evolve. But there’s still a lag between accepting the principle and adopting the discipline. People nod when you describe posture drift. They don’t always have the internal authority or budget to act on it yet.
On the institutional side, the resistance is different. Not philosophical anymore. Practical. Internal teams are stretched. The regulatory perimeter is still being defined. Most of the institutional structures, security, risk, audit, legal, are organized around categories that don’t quite fit programmable infrastructure. Genuine intent and very real friction, in the same building.
What I noticed most clearly is that the question type has changed. Two years ago, you had to explain what a smart contract was before you could discuss its governance. This year, on the floor at one of these institutional satellites, the questions were about upgrade keys, role-based access, multisig composition, audit drift. From people with institutional titles. That change in question type is itself the signal.
Sophie: In traditional arbitration, facts are reconstructed after the event. With continuously monitored smart contracts at the code level, do we now have a persistent, timestamped record that could serve as evidence in a dispute?
Olivier: There’s something genuinely new here, and there’s something the legal tradition has seen many times before. I want to hold both, because the temptation in this space is to collapse the two. What’s genuinely new is the quality of the operational record. In traditional arbitration, when something goes wrong in a financial process, a substantial part of the work is forensic. Lawyers, technical experts, and auditors reconstruct what happened, often months or years after the fact, from logs of varying quality, emails, screenshots, the recollections of people who were involved. The reconstruction is expensive, contested, and sometimes incomplete.
In a smart contract environment that is continuously monitored at the code level, you have a structurally different operational record. A persistent, timestamped account of the actual state of the system at each moment. Not just transactions, which are public. The configuration of the system: who held which permissions, which dependencies were imported, what the upgrade governance looked like, when each change occurred, under whose authority. That operational record exists by construction, not as an artifact of later investigation. That is a real advance, and lawyers who’ve started working with these materials have noticed.
There’s a second layer to this, one level beneath the record itself, that I think people are still working out. It concerns what is actually being recorded. In traditional financial disputes, the instrument at the centre of the case usually has a fairly stable economic identity. A bond is a bond. A swap is a swap.
Characterization can be contested at the margins, but the underlying object is reasonably settled. Programmable instruments do not always behave that way. A token that emits a continuous yield stream while also conferring voting rights and providing collateral utility is, in a meaningful sense, several instruments superimposed. Each of those behaviors may dominate in different contexts, at different times, depending on how the token is being used and against what counterparty. Courts and tribunals have long handled this kind of question pragmatically, by characterizing the dominant economic feature given the facts. That isn’t new, and I don’t think it’s failing. What is new is how fact-dependent and operationally contextual the exercise becomes when the facts themselves are layered. So the granularity of the operational record matters for a reason that runs slightly beyond the usual evidentiary one. In some cases, the reconstruction will need to establish which of several economic behaviors was actually in play at the moment that counts.
What’s not new, and this is the part worth being careful about, is the gap between an operational record and admissible evidence. Continuous monitoring doesn’t produce courtroom-ready evidence by default. It produces operational telemetry. For that telemetry to be usable, it has to clear procedural conditions that have been worked out over decades in other contexts and now apply here too. Integrity. Chain of custody. Completeness. Interpretability. Without those, the strongest cryptographic timestamp in the world is still vulnerable to a credible argument that the data was selectively captured or interpreted after the fact.
There’s a useful precedent at the systems level. Continuous instrumentation has historically changed safety culture before it changed law. The flight data recorder reorganized accountability around aviation incidents long before doctrine caught up. Financial infrastructure may go through a similar shift. But, and this is the careful version, instrumentation changes behavior because organizations decide to treat it as authoritative for their own purposes, not because courts have necessarily decided so. The institutional shift comes first. The legal recognition follows.
So my honest summary is this. Continuous posture management produces an extremely rich layer of operational factuality. With the right preservation discipline, that material can support investigations, regulatory dialogue, internal incident reconstruction, and, increasingly, arbitration arguments. It is not, in itself, admissible evidence. It can become so. The work of making it so is procedural, not technical. That distinction is the one experienced lawyers I’ve spoken with hold most firmly.
Sophie: This kind of system produces factual evidence, what the code is at each moment, when, and in what state, but not intentional evidence. Does that distinction matter in practice in a court?
Olivier: It matters enormously. And it’s a distinction the legal tradition already understands very well, even if the technical context is new. Courts and arbitral tribunals have always distinguished between what happened, and why it happened, or with what intent. Factual material establishes the first, when it survives the procedural tests we discussed. Intent is reconstructed from a much wider set of materials: communications, prior conduct, professional standards, contractual obligations, expert testimony about reasonable behavior. That second category doesn’t come out of continuous monitoring. It comes out of investigation.
In the context of programmable infrastructure, what continuous monitoring produces is rich factual material. Properly preserved, it can tell you exactly what the code was, what state the system was in, when each change happened, and under whose authority a key was used. That’s extremely useful. It doesn’t, on its own, tell you whether a given action was negligent, reckless, deliberate, or simply a reasonable response to circumstances. Those are intentional questions. They cannot be read off a timestamped log, no matter how precise the log is.
In practice, the distinction matters in a few specific ways. It constrains what you can conclude from the record alone. You can show that an upgrade key was used at 3:14 in the morning and that the result was a five-million-dollar mispricing. You cannot show, from the record alone, whether that was malicious, mistaken, or authorized in a way that simply wasn’t documented well. The record is precise about what. It’s silent about why.
There’s a related wrinkle worth naming, which connects back to something I said earlier. With programmable instruments, even the factual side of the picture carries more layers than the older categories assume. The same artefact may have been functioning as collateral, as a yield-bearing position, and as a governance instrument at the same time. The record will show which of those states were active. It does not, by itself, settle which economic identity should govern the legal characterization at the moment that matters. That is interpretive work, and tribunals are well-suited to it. But it is a reminder that what counts as a fact in these disputes has more texture than it used to.
It also changes how investigations proceed. The factual record narrows the space of possible explanations, sometimes dramatically. The work of establishing intent still requires human inquiry: depositions, internal communications, governance minutes, expert testimony about what a reasonable institution would have done in the same circumstances. That work isn’t going away. If anything, the precision of the factual record raises the standard of what counts as a credible intentional account.
And there’s a third effect that most discussions miss. When the factual record is strong, contemporaneous, and properly preserved, the absence of corresponding internal documentation about intent becomes itself a piece of information. If a critical change happened on-chain and no one inside the institution can explain why, that gap is evidentiary in its own right. Silence after a clear event has a different weight than silence in a foggy one.
So the honest answer is: factual material at the code level, even when well preserved, is necessary and not sufficient. It is a foundation, not a verdict. Anyone who claims that programmable systems make legal judgment unnecessary is either confused or selling something. What these systems actually do is sharpen the boundary between what facts can tell us and what still requires human interpretation.
That sharpening is, in the long run, valuable for everyone. Because it forces clearer thinking about which questions are technical and which are not. Most of the worst legal disputes happen when those two get conflated.
There’s a philosophical point worth surfacing here. Institutions have always had to manage the gap between factual evidence and intentional evidence. Accounting records show what was done. They don’t show whether fraud was intended. Surveillance footage shows movement. It doesn’t show motive. Continuous monitoring of code is the latest entry in a long tradition of factual instrumentation that improves the quality of the underlying record without ever replacing the human work of interpretation. What’s genuinely new is the granularity. That precision shifts the burden of explanation. It doesn’t eliminate the need for judgment. It raises the standard of explanation that judgment has to meet.
And there’s one slogan worth refusing on the way out. Code is law. No legal system treats code as a final source of legal authority. Code determines what happens. Law determines what should have happened. The space between those two sentences is where the real work of governance lives.
Sophie: Olivier, thank you.
Olivier: Thank you, Sophie.
