in the spring of 2024, a digital-asset custody firm — name redacted at counsel direction — submitted a claim under what its incumbent brokers had positioned, in good faith, as comprehensive cover for the firm's digital-asset operations. The loss had occurred over a 17-minute window in which a bridge contract between two chains drained to a destination address before the pause-multisig fired. By the time the multisig executed, the contract balance was zero. The forensic walk-through, when it arrived, was conclusive on the root cause: the bridge contract contained a logic defect in its message-verification routine, and the defect was exploited. No key material was ever compromised. No signer was ever phished. The wallets remained intact.
The carrier was notified under the hot-wallet wording. The hot-wallet wording responded in principle to "the unrecoverable loss of Cryptographic Key Material from a Listed Wallet by reason of any of the Insured Events enumerated below." Each of those Insured Events — unauthorised external actor, internal collusion, certain forms of social engineering, specified malware classes — was a peril that operated through compromised key material. None of them addressed a loss that originated from logic in a deployed contract.
The carrier denied. The denial held. The brokers, the client, and a counsel team spent the following six months working through whether the loss might respond on a separately placed cyber tower. It did not. The cyber wording's first-party theft language excluded loss arising from "the function or malfunction of any computer program or code in a smart contract", an exclusion that has become standard market language since 2022 and that the brokers had not flagged at placement.
The client carried the loss. The brokers carried the relationship cost.
I am not writing this to be ghoulish. I am writing it because the case is one of the most common patterns I see when reading brokered programmes for digital-asset operators on referral. The pattern is almost always the same: the buyer was told they had "comprehensive crypto cover", and the wording on the binder responded to one specific peril among five. The other four — cold-storage compromise, smart-contract logic failure, validator slashing, insider fraud — each respond under their own structures. Buyers who treat the hot-wallet binder as the headline of a single product are routinely surprised at claim.
London · 18 May 2026 · 12 minutes
The Atrium 609 wording — read closely
The Atrium Syndicate 609 hot-wallet cover wording, in its publicly reported 2023 form, is one of the best-known hot-wallet binders in the London market and a useful reference point for what hot-wallet cover does and does not do. The Coincover programme, which uses an Atrium 609-backed dynamic-limit policy, has been described in public reporting as covering hot-wallet exposure with policy limits indexed to the price of the underlying digital asset.1
The Insuring Clause of a hot-wallet wording of this kind reads, in substance:
"We shall pay the Insured for the unrecoverable loss of Cryptographic Key Material from a Listed Wallet by reason of any of the Insured Events enumerated below, subject to the Limit of Liability and the Excess specified in the Schedule."2
Two definitions do the work here: Listed Wallet and Cryptographic Key Material. A Listed Wallet is a specific wallet identified on the Schedule by chain, by address (or wallet system), and by the operational controls in place. Cryptographic Key Material is the key material — private keys, mnemonic seeds, signing shares in an MPC configuration — controlling the assets at those wallets. The binder responds when that material is lost (in the sense of being moved to an attacker's control, destroyed, or rendered irrecoverable) by an enumerated Insured Event.
If the assets at a Listed Wallet move because the keys were compromised, the binder is on the hook. If the assets move because a smart contract authorised the move under its own logic, with no key compromise, the binder is not on the hook. The wording is doing what it says, and what it says is narrower than the buyer often understands.
The smart-contract logic exclusion
In parallel, smart-contract logic failure has been written separately. The Native "Risk Collective" framework, anchored on Mosaic and Chaucer, is one publicly reported example of a structure that wraps the smart-contract logic side of the exposure; Canopius Syndicate 4444 has launched a digital-asset Custody product on the Lloyd's Asia platform that addresses the Custody side; and various carriers have been described as writing discrete smart-contract logic binders against a Listed Contract Schedule.3 The mechanics vary. The common element is that smart-contract logic is treated as its own peril, with its own underwriting, its own Listed Contract Schedule, and frequently its own carrier.
In a comprehensive programme, the structure looks something like the following:
- Hot-wallet wording. Listed Wallet Schedule. Responds to key-compromise events on the enumerated wallets.
- Cold-storage / Specie wording. Listed Facility Schedule. Responds to physical and certain mysterious-disappearance events for cold key material.
- Smart-contract wording. Listed Contract Schedule. Responds to defined logic-failure events at the enumerated contracts.
- Cyber tower. First-party and third-party cyber. Responds to non-crypto-direct losses (data restoration, BI, third-party liability).
- Crime / fidelity backstop. Responds to insider dishonesty across the operational footprint.
That is five binders. They are placed across, typically, three to five carriers. They renew on three to five separate cycles. The argument I make to clients is that this is the architecture, and that programmes presented as fewer than this number of binders should be read against this taxonomy clause-by-clause before placement.
Buyers who treat the hot-wallet binder as the headline of a single product are routinely surprised at claim.
Senior Broker · Digital-Asset Practice
What buyers should ask before binding
If you are reviewing a hot-wallet binder, here are six questions to ask before signing:
- Does the binder enumerate smart-contract logic failure as an Insured Event? If silent, assume it does not respond.
- Is there a separate Listed Contract Schedule, or is cover limited to a Listed Wallet Schedule? If the latter, contract logic is uncovered on this wording.
- What is the bridge / oracle exposure? Bridge contracts and oracle dependencies sit outside the standard hot-wallet wording almost universally.
- How does the wording treat insider events that route through credentialed access to a hot wallet? Some wordings treat them as Crime; some treat them as Cyber; some treat them as both, with sub-limits.
- What does the wording say about social engineering of authorised personnel? Coverage and sub-limits vary materially.
- What is the cancellation / renewal language at carrier discretion? Hot-wallet capacity has tightened twice in the last three years; cancellation language is worth reading.
"That is five binders. They are placed across, typically, three to five carriers. They renew on three to five separate cycles."
What the brokerage market should publish more of
I write this in the same register as the Lloyd's Market Bulletin: one practitioner's reading of the wording, sourced to the public form, with the gaps in the public record acknowledged. The broker who placed the cover in the 2024 case at the top of this piece is not named because the broker's identity is not the point; the wording is. The thing the digital-asset insurance market most needs more of in 2026 is published wording analysis. We intend to keep at it.
[ed: a longer version of this walkthrough, with the Coincover programme structure annotated against the schedule, sits in the draft folder for the June primer.]
If you are reviewing your own programme against the taxonomy above and want a second reading of the wording, the RFI form is the fastest route to a same-business-day acknowledgement.