Ask most people about the safety of an on-chain product and the first answer tends to involve an audit. For an institutional allocator, that is the wrong place to start.

It is a reasonable question. Smart contract audits are a genuine control tool, and a protocol handling investor capital without one should raise questions for any professional investor. But it is not the first question an institutional allocator should be asking. A significant share of the largest losses in digital assets have not involved a flaw in contract logic at all: the code behaved exactly as written and the failure occurred somewhere else.

As we see it, a useful framework to think about the risk has several layers, and the code is only one part of that:

-       Smart contract security

-       Operational controls

-       Custody arrangements

-       Governance and permission management

-       Monitoring and emergency controls

-       Risk management

-       Legal structure

An audit provides meaningful assurance over the first layer, at a point in time, within a defined scope. The problem is, it provides very little over the rest. The sections below explain why each of the remaining layers matters, and what to ask about them.

What a smart contract audit actually covers

A competent audit examines contract logic, access-control implementation, accounting, upgrade mechanisms, interactions with other contracts, and known classes of vulnerability. Within that scope the work is valuable and genuinely difficult, and a good auditor can find things the development team might have missed.

The limitation is not the quality of the work, but the scope. To put it in extremely simple terms, an audit assesses whether the code does what it is designed to do. It does not assess who is operating that code, how they are operating it, or what surrounds it.

Consider a straightforward example: A protocol uses a three-of-five multisignature wallet (an arrangement requiring three of five designated parties to approve any transaction) to authorise movements of funds. An auditor may confirm that the protocol’s multisig permissions are implemented as intended and that the required threshold is enforced in the code. That is a real assurance and it is indeed worth having.

It does not – however – tell an investor who controls those five keys. Whether two or three of them sit with the same individual, or for example on the same device. How the keys are stored, and whether any have previously been exposed. Whether the signers independently verify what they are approving, or simply sign what appears in front of them. Whether transactions are simulated before signing. Whether withdrawal addresses are restricted to an approved list. Whether the signing interface itself could be compromised. Or what happens if one part of the operating organisation is compromised while the rest is not.

The lesson here is that the technical control can function exactly as designed while the operational implementation of that control can be a weak one. These are two different questions, and only one of them sits inside the audit's scope.

Why many of the incidents ending in losses are operational before they are technical

This distinction should be made: In a substantial number of major incidents, the contract performed correctly and the loss happened anyway, because an authorised party – or someone who had compromised an authorised party – was able to use the contract in a harmful way. Thus the exploited contract was not itself the primary point of failure.

The recurring patterns will be familiar to anyone who has worked in operational risk.

-       Compromised admin or signer keys.

-       Multisig structures that provide the appearance of distributed control without actually delivering that.

-       Inadequate segregation of duties.

-       Legitimate signers approving transactions that are malicious, or simply incorrect.

-       Upgrade permissions held more broadly than necessary.

-       Weak or absent whitelisting and transaction policies.

-       Compromised front-ends and signing environments.

-       Monitoring that identifies a problem only after funds have already moved combined with emergency controls that cannot stop it once it has.

Many of these are not defects in the underlying contract logic. And some sit at the crossroads of code, system design and operational implementation. Any one of them can result in the total loss of investor assets.

To underline the point: this is why smart contract security and operational security cannot sensibly be assessed in isolation. A protocol with excellent code and poor key management is not a well-controlled environment but a well-written contract inside a poorly controlled one. And after all, from an investor's perspective, the overall situation is the one that matters.

Why an audit describes a moment, not a state

There is a second limitation, and it is easy to overlook. An audit normally covers a specific version of the code at a specific point in time, and what happens afterwards is not covered.

-       Contracts are upgraded.

-       New implementations are deployed.

-       Strategies are added.

-       Oracles (the external data feeds a protocol uses for pricing) are changed.

-       New protocols are whitelisted.

-       Permissions are adjusted.

-       Adapters are introduced to connect the protocol to venues or strategies it did not originally interact with.

-       Risk parameters are altered.

And the list goes on. Any of these can happen without a further audit, and frequently does. The existence of a report on a website, therefore, does not establish that today's production environment matches what was reviewed. In some cases the difference is trivial and in others it is the entire point.

Four questions are consequently more useful than asking whether an audit exists:

-       What exactly was audited?

-       What is deployed today?

-       What has changed since the audit?

-       Who has the ability to change it going forward?

The last is usually the most revealing, because it shifts the conversation from what the code currently does to who is permitted to change what it does. That is, more than anything, a governance question rather than a technical one, and it is not always addressed in an audit report.

Why the contract is only one layer of an investment product

For a professional investor, all of the above sits inside a much longer chain. This matters more and more, because protocols that were built for retail participants are now being marketed to professional investors and institutional asset managers, without the surrounding structure that audience could expect. A tokenised investment product typically involves something like:

Investor → token → smart contract → custody → trading venues and protocols → underlying assets

And, in most cases, simultaneously:

Investor → legal entity → contractual rights → underlying assets

A smart contract audit covers a single link in the first chain and nothing at all in the second. Everything else remains open, and that’s where the major investor protections can either be set up or not.

The questions an allocator needs answered are therefore broader than anything an auditor is able to answer:

-       Who legally owns the underlying assets.

-       Who has custody of them, and under what terms.

-       Who is able to move them, and what is required to do so.

-       How net asset value is calculated, by whom, and with what independence.

-       How subscriptions and redemptions are processed, and what happens when redemption demand concentrates.

-       Whether assets are segregated from those of the manager or issuer.

-       What happens if the manager or issuer becomes insolvent.

-       Which legal entity actually owes obligations to investors.

-       Whether the token represents an enforceable legal claim, or simply a record of one.

Why tokenisation does not remove the need for legal structure

That final question deserves particular attention.

A token can represent an interest in a portfolio. But representation and enforceability are not the same thing, and the important question is what gives that representation legal meaning.

There still needs to be clarity on the issuer, ownership of the assets, investor rights, redemption obligations, asset segregation, insolvency treatment, governing law, custody and enforcement. A blockchain can indeed provide transparency, programmability and automated controls, and these are real advantages over the operational opacity of some traditional structures. But a distributed ledger cannot determine who owns an asset under the law of a particular jurisdiction, or what an investor is entitled to recover if the issuer fails.

Tokenisation changes how ownership is recorded and transferred. It does not change the need for a legal arrangement establishing what is being owned and transferred in the first place.

Where the manager's role sits

Returning to the layers set out at the start: smart contract security, operational controls, custody, governance and permission management, monitoring, risk management, and legal structure. Only when these layers function together does an on-chain product provide a control environment a professional investor can reasonably rely on. Any single layer assessed alone produces a misleading picture. Often, it’s the code layer. And that’s because it is the one with a published report attached to it.

This is where an institutional asset manager’s role extends beyond just the selection of protocol. Identifying an audited protocol is only the beginning; the manager must assess the audit’s quality and relevance, understand the protocol’s dependencies and privileged roles, and build operational, legal and portfolio-level controls, so that a single technical failure or a single compromised actor does not translate directly into a loss of investor assets. That carefully thought out framework is what stands between an isolated incident and a permanent impairment.

Questions worth asking

For allocators conducting diligence on an on-chain product, the following give a reasonable starting structure. They follow the layers set above.

On code: what was audited, by whom, and against which version? What is deployed today, and what has changed since?

On operations: who holds signing authority, how are keys stored, and are signers genuinely independent of one another? Are transactions simulated and verified before approval?

On custody: who holds the assets, under what legal terms, and who is able to instruct their movement?

On governance and permissions: who can upgrade contracts, change parameters or whitelist new venues, and what process governs those decisions?

On monitoring: what would detect an unauthorised transaction, how quickly, and what emergency controls exist?

On risk: how are counterparty, liquidity and concentration exposures measured and limited?

On legal structure: which entity owes obligations to investors, are assets segregated, and what happens on insolvency?

The underlying point is a simple one.

An audit can tell you whether the code appears secure. It cannot, on its own, tell you whether the investment product is secure.

For institutional on-chain asset management, code is just one layer of the bigger topic of risk architecture.

‍