Smart Contract Risk in Crypto Custody

Skip key takeaways

Key takeaways: smart contract risk in crypto custody 5

Updated July 29, 2026

What an audit report actually evidences, how upgrade privilege is read on chain, where a proxy admin key meets Article 75(7) and what MiCA leaves unsettled about staking.

• Smart contract risk is the one CSA scope item with no settled evidence practice ESMA names smart contract risks among six DLT-inherent risks in the custody Common Supervisory Action scope, while MiCA Articles 70 and 75 never use the phrase, so no provision says which answer counts.
• An audit report proves a bytecode version, not a live deployment An audit covers one bytecode version at one point in time, so bind every report to a deployed address and the bytecode hash it covers, then record whether the deployed bytecode still matches.
• Upgrade privilege is access control, and access control is where our critical findings cluster Access control is the most frequent critical class across our 130 audits, and whoever holds upgrade privilege can change what a contract does with client balances without touching a signing key.
• A proxy admin key is a segregation question that key management never sees On our reading, an upgradeable contract holding client assets puts the Article 75(7) operational segregation boundary inside a privilege the provider holds, which key management controls never reach because they protect the signing key instead.
• Staking treatment under MiCA is unsettled and this article says so rather than guessing No retrieved MiCA provision names staking, restaking or liquid staking, and whether a third-party staking contract triggers Article 75(9) sub-custody stays open, but rewards, lock state and slashing still belong in the register of positions.

Copy takeaways

If a supervisor asked today what your contracts can do to client assets, we can help you build the evidence before the question arrives.

See our smart contract audit services

Smart contract risk in crypto custody became a supervisory question in July 2026, and nobody yet agrees what proving it looks like. The primary texts describe duties. They do not describe artefacts, so someone has to.

In short: Smart contract risk in crypto custody is the one item on ESMA's Common Supervisory Action scope list with no settled evidence practice behind it. ESMA names it among six risks inherent to distributed ledger technology, and MiCA's custody provisions never name it: Articles 70 and 75 use the phrase "smart contract" zero times, and its single appearance in the act sits in a recital about market abuse. That gap is the problem: a supervisor can ask what your contracts are able to do to client assets, and no provision tells you which answer counts. This article treats each claim a CASP makes about its contracts as a claim under test and names the artefact that proves or falsifies it. Where the link between a contract-level fact and a MiCA duty is our reading rather than the statute's, the sentence that makes the link says so.

Smart contract risk in crypto custody is a supervisory scope item, not a code quality topic

Smart contract risk in crypto custody entered supervisory scope on 8 July 2026, when ESMA launched a Common Supervisory Action "focusing on the digital operational resilience of Crypto-Asset Service Providers (CASPs), with a specific emphasis on custody services". The scope sentence is worth reading whole:

The CSA will assess the maturity of CASPs' digital operational resilience frameworks in relation to custody activities. It will focus on risks inherent to distributed ledger technology (DLT), including governance arrangements, key and storage management, transaction controls, incident detection and response, smart contract risks, and dependencies on third-party providers.

Two framing details carry weight. The list is introduced by "including", so it is open-ended rather than a six-box checklist to close out, and the items are scoped to "risks inherent to distributed ledger technology (DLT)" rather than to a general ICT audit. National competent authorities run the exercise "on a risk-based sample of authorised CASPs", and it "will run from the second half of 2026 to the first half of 2027". The scope list as a subject belongs to our ESMA custody Common Supervisory Action coverage. This article takes the fifth item and nothing else.

MiCA's own text never names the technology

One thing to settle first. MiCA's custody provisions never name the thing a developer calls a smart contract: Articles 70 and 75 contain the phrase zero times, and the act's single occurrence of it sits in recital 96, on order execution and market abuse rather than custody. Article 75 reaches the technology as "distributed ledger" instead, three times in that article and 40 times across the act. So the ESMA scope list is the only primary text here that names smart contract risk directly. Everything below that ties a contract-level fact to a MiCA duty is a reading, ours, labeled as one where it appears.

The claim "our contracts were audited" and what an audit actually evidences

The first smart contract risk claim a custody CASP makes is that its contracts were audited, and it is the weakest one in the pack. Our own delivery data puts the median audit at 27 findings and a median cost of 8,000 US dollars, with 71% of the 130 smart contract audits we ran between 2018 and 2026 surfacing at least one critical or high finding. None of that is broken down by custody relevance, so it is a general rate and not a custody-specific one.

An audit report evidences something narrower than what it gets used for: one bytecode version at one point in time. It says nothing about what is deployed at the address holding client assets today unless somebody checked that the two match, and that gap opens quietly, because nothing on chain announces a stale report.

The engineering decision is small and it is what makes the artefact worth keeping. Bind every audit report to a deployed address and the bytecode hash it covers, then record whether the deployed bytecode still matches. A report carrying neither cannot be checked against anything, and one carrying both becomes testable. Audit pricing and scoping are covered in our smart contract audit cost analysis.

The claim "no one can change the contract" and how upgrade privilege is proven

The sharpest smart contract risk in crypto custody is the privilege to change a deployed contract, and it is provable on chain rather than by assertion. Access-control bugs are the most frequent critical class we find across those 130 audits, and upgrade privilege is access control at its most consequential: whoever holds it can change what the contract does with client balances without ever touching a signing key.

Four public reads settle the question for any given address.

• A standard upgradeable proxy keeps its admin address at a fixed storage location under EIP-1967, readable by anyone with an RPC endpoint.
• Role registries expose the current holder of every privileged role, including the roles that can pause, sweep or re-point the implementation behind the proxy, which is a wider surface than the admin slot alone.
• Where admin sits behind a timelock, the minimum delay is a public parameter.
• Implementation changes emit events, so the log shows how many upgrades a contract has taken, when and from which address, without anyone needing to be asked.

None of that requires trusting a document. A governance policy stating that upgrades need two approvals proves only that someone wrote a governance policy, and a screenshot of an internal wiki page is not evidence about a deployed address. The on-chain read is the evidence, the policy is the intent, and the supervisory question worth answering is whether the two agree.

The claim "client assets are segregated" when a proxy admin key exists

Segregation is the smart contract risk claim in crypto custody where code and statute meet most directly. Article 75(7) imposes three distinct layers on a custody CASP and our MiCA custody requirements guide defines each one. This section tests them against a single fact instead of restating them: the CASP holds upgrade privilege over the contract that holds client assets.

On-ledger separation survives that fact intact, because client crypto-assets can sit at addresses distinct from the CASP's own and an admin key does not merge the balances. Legal segregation from the provider's estate is a question for applicable law and the insolvency analysis, not for the contract. The pressure lands on the third subparagraph, which requires that "the crypto-assets held in custody are operationally segregated from the crypto-asset service provider's estate".

Our reading of the operational segregation duty

What follows is our reading rather than MiCA's, because MiCA nowhere names upgrade privilege, proxies or admin keys. An address holding client assets behind a contract the CASP can upgrade is an address whose behavior the CASP can change unilaterally. That changes no balance today, but it does mean the operational boundary between client assets and the provider runs through a privilege the provider holds, and a supervisor asking how operational segregation is enforced gets a better answer from an admin slot read than from an org chart.

It is also why key management does not close the question. The controls compared in our key management comparison protect the key that signs a transfer, while upgrade privilege changes what the contract does with the assets rather than who signs for them.

The claim "the loss was not attributable to us" and the Article 75(8) carve out

After an exploit, the smart contract risk claim a custody CASP most wants to make is that the loss was not attributable to it. Article 75(8) makes attributable losses the provider's liability and then defines what sits outside:

Incidents not attributable to the crypto-asset service provider include any event in respect of which the crypto-asset service provider demonstrates that it occurred independently of the provision of the relevant service, or independently of the operations of the crypto-asset service provider, such as a problem inherent in the operation of the distributed ledger that the crypto-asset service provider does not control.

The same paragraph caps liability at the market value of the lost crypto-asset at the time the loss occurred, a derivation our MiCA custody requirements guide works through. The clause that matters here is the final one: a problem the provider "does not control".

Applying the carve-out where the CASP holds the privilege

Our reading, not a statutory statement: an upgradeable contract whose admin key the CASP holds is by construction something the CASP controls. The carve-out is drafted around events independent of the provider's operations, and a privilege the provider can exercise at will is not independent of them. A base-layer consensus failure is a plausible candidate for it. A bug in a contract the CASP deployed, audited and can upgrade is a much harder argument to run.

A contract the CASP does not control runs the argument the other way

The inverse case runs the other way: a contract the CASP does not control can still act on a client position. A third-party stablecoin held in custody may be pausable, freezable or upgradeable by its issuer, which can strand a client balance with no CASP privilege involved anywhere. On our reading that sits closer to the carve-out, and it remains a custody exposure the address inventory should name alongside the privilege holder.

The custody policy duty points the same way from the other side. Under Article 75(3) that policy has to "minimise the risk of a loss of clients' crypto-assets or the rights related to those crypto-assets or the means of access to the crypto-assets due to fraud, cyber threats or negligence". A contract exploit that a control would have caught sits closer to the last of those three causes than to anything in the carve-out.

The claim "staked client assets are still in custody"

Staking is the smart contract risk in crypto custody where the honest answer is that MiCA does not say. No retrieved provision names staking, restaking, liquid staking or any DeFi position. Three provisions reach the question sideways and none of them settles it.

Article 75(2) requires a register of positions opened in the name of each client and corresponding to that client's rights to the crypto-assets. The movement duty on top of it is conditional: "where relevant" the provider records "as soon as possible in that register any movements following instructions from their clients", and "in such cases" internal procedures must ensure the movement "is evidenced by a transaction regularly registered in the client's register of positions". Under Article 75(4), "any event likely to create or modify the rights of a client shall immediately be recorded in the client's register of positions", and the second subparagraph reaches "any other event likely to create or modify a client's rights". Sub-custody is restricted by Article 75(9) to providers authorised in accordance with Article 59, with a duty to tell clients about it.

Bridging the register duty to staking rewards and slashing

The bridges from there are ours. A staking reward and a slashing penalty both modify a client's rights, so Article 75(4) appears to reach them by reading rather than by name. Whether a third-party staking contract counts as another crypto-asset service provider for Article 75(9) purposes is a question the text raises and does not answer, and no retrieved source answers it either. Both stay open.

The register consequence is not open. If the position exists it belongs in the register, and the register has to move when the position moves. A staked balance whose rewards accrue on chain and whose lock state changes without a matching register entry is a gap however the sub-custody question resolves. Instrument the contract events that change the position and write them into the register.

The claim "we would detect an exploit"

Detection is where smart contract risk in crypto custody stops being a MiCA question and becomes a DORA one. MiCA does not restate ICT requirements, it points at them. Article 68(7) requires CASPs to employ resilient and secure ICT systems "as required by Regulation (EU) 2022/2554" and to hold a business continuity policy including the ICT response and recovery plans set up under DORA Articles 11 and 12. Paragraph 8 of the same article adds the DORA mechanisms, systems and procedures plus systems safeguarding the availability, authenticity, integrity and confidentiality of data.

DORA reaches CASPs directly as well. Its Article 2(1)(f) puts crypto-asset service providers authorised under MiCA inside the definition of a financial entity for the whole regulation. The two application dates are not one date: MiCA applies from 30 December 2024 under Article 149(2) and DORA from 17 January 2025 under Article 64.

DORA Article 17 requires a defined incident management process to detect, manage and notify ICT-related incidents, with all incidents and significant cyber threats recorded and root causes identified and addressed. Six criteria classify impact under Article 18(1): clients and transactions affected, duration, geographical spread, data losses, criticality of the services affected and economic impact. Reporting deadlines are not in DORA at all. Article 19(4) defers the time limits to implementing technical standards under Article 20, so any hour count quoted at you comes from somewhere else.

Four contract-level signals detection actually needs

At contract level, detection means four signals wired into that incident process rather than into a dashboard nobody reads: upgrade events on any contract in the custody path, admin and role changes, pause state transitions and balance drift between the chain and the register of positions. The last one fails closed, which makes it the strongest of the four. When chain and register disagree, something happened whether or not you know what.

Revoking upgrade privilege and evidencing the revocation

Removing smart contract risk from a crypto custody path means removing the privilege, and evidencing the removal is a separate job from performing it. Three routes are available and they are not equivalent.

Renouncing ownership sets the privileged role to an address nobody controls. It is the strongest claim available and it is irreversible, which also removes the emergency patch route. Moving admin to a timelock keeps the ability to change the contract while making every change visible for a fixed delay before it executes. Splitting roles separates the ability to upgrade from the ability to pause or sweep, so no single key holds the whole privilege.

Each route leaves a different artefact behind, and the artefact is the point. Renunciation leaves a transaction hash, an emitted ownership event and a post-revocation read of the role returning the zero address. A timelock migration leaves the admin change transaction, the timelock address and its minimum delay. A role split leaves the current holder of each role as separate reads.

"We removed the key" describes an internal process. "We can show the key is gone" describes something anyone can verify from public data, and a supervisor asking about upgrade privilege is asking the second question even when the first is what gets answered. Recording the transaction hash at the moment of revocation costs nothing. Reconstructing it two years later is a research project.

The evidence pack a CASP should be able to hand an NCA

Everything above collapses into one artefact set, and smart contract risk in crypto custody is auditable only to the extent that set exists before anyone asks for it. The table consolidates it.

Retention here is statutory, not a matter of taste. Article 68(9) requires records "of all crypto-asset services, activities, orders, and transactions undertaken" by the CASP, to be "provided to clients upon request" and "kept for a period of five years and, where requested by the competent authority before five years have elapsed, for a period of up to seven years". We read that as covering a bytecode hash and an admin slot snapshot, because evidence of what a contract can do to a client position is evidence about the service. The paragraph itself does not say so. Article 68(10) mandates ESMA regulatory technical standards further specifying those records, and this article states the mandate only.

Claim	Artefact	Where it lives	How it is refreshed	Retention
Our contracts were audited	Audit report bound to a deployed address and the bytecode hash it covers	Release evidence store, linked from the custody policy	Every deployment and upgrade	Five years under Article 68(9), up to seven on a competent authority request made before then
No one can change the contract	Dated read of the admin slot, the role holders and any timelock delay	Attestation job output in version control	Per release and on a fixed cycle	Same clock
Upgrade privilege was revoked	Revocation transaction hash, the emitted event and a post-revocation read of the role	Same store, cross-referenced from the change record	Once, then re-verified each attestation run	Same clock
Client assets are segregated	Address inventory mapping client holdings against the provider's own, naming the privilege holder per address	Register of positions tooling	Every address or contract change	Same clock
Staked positions are recorded	Register entries for rewards, lock state and slashing, naming the contract counterparty	Register of positions	As the events occur	Same clock
We would detect an exploit	Alert definitions for upgrade events, role changes, pause state and balance drift, plus the incident records DORA Article 17(2) requires	Monitoring configuration in version control, incident log	After each incident and each upgrade	Incident records under the DORA process, contract evidence under Article 68(9)
A client can obtain this	Export of that client's position and movement records	Statement of position tooling	On request	Article 68(9) requires the records to be provided to clients upon request

Two columns do the work: refresh separates a live control from a folder of documents, retention turns that folder into a statutory record set.

How Pharos Production helps

Smart contract risk in crypto custody is only as strong as the claim you can evidence, so the ladder above is the shape of the work. The audited-contracts claim holds only when the report is bound to a deployed address and a bytecode hash, which is what our smart contract security audit practice leaves behind and keeps checkable after the engagement closes. Behind the claim that nobody can change the contract sit dated reads of the admin slot, the role registry and any timelock delay, produced by an attestation job our cybersecurity practice builds. Detection holds up only once the contract-level signals reach the incident process a CASP already runs, and that wiring is the same practice's work.

Sources: ESMA press release "ESMA launches Common Supervisory Action on CASPs' digital operational resilience for custody" (8 July 2026), via esma.europa.eu; Regulation (EU) 2023/1114 (MiCA), recital 96 and Articles 68, 75 and 149, via publications.europa.eu; Regulation (EU) 2022/2554 (DORA), Articles 2, 17, 18, 19 and 64, via publications.europa.eu. Both regulations were read as originally published rather than as consolidated texts, so check for later amendments before relying on a quotation. Audit figures are Pharos Production delivery data covering 130 smart contract audits between 2018 and 2026. This article is engineering guidance, not legal advice. Confirm every requirement against the primary text with qualified counsel before you rely on it.

FAQ

Last updated: July 29, 2026 · Reviewed by: Dmytro Nasyrov (Founder and CTO)

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• ★ Featured question. Is smart contract risk part of the ESMA custody Common Supervisory Action?

  Copy link Copies a direct link to this answer to your clipboard.

  Yes, it is one of six DLT-inherent risk categories named in the scope, and the list is introduced by "including" so it is not exhaustive.

• Does a smart contract audit satisfy a supervisor?

  Copy link Copies a direct link to this answer to your clipboard.

  An audit evidences one bytecode version at one point in time; it says nothing about what is deployed today unless it is bound to a deployed address and a bytecode hash.

• Does a proxy admin key break Article 75(7) segregation?

  Copy link Copies a direct link to this answer to your clipboard.

  It does not automatically, but it creates an operational segregation question that key management controls do not answer, because the privilege changes custody semantics without touching a signing key.

• Are staked client assets still in custody under MiCA?

  Copy link Copies a direct link to this answer to your clipboard.

  Unsettled. MiCA Articles 70 and 75 never name staking; Article 75(4) reaches rights-modifying events by reading and Article 75(9) raises a sub-custody question that no retrieved source answers.

• Can a CASP rely on the Article 75(8) liability carve out after a contract exploit?

  Copy link Copies a direct link to this answer to your clipboard.

  The carve-out covers problems inherent in the operation of a distributed ledger that the CASP does not control, which is a hard argument to make about a contract whose admin key the CASP holds.

• How often do audits find something serious?

  Copy link Copies a direct link to this answer to your clipboard.

  Across 130 audits we ran between 2018 and 2026, 71% surfaced at least one critical or high finding, with a median of 27 findings per audit and access control the most frequent critical class.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.