← all writing

From Onchain Capital to Onchain Risk: ILWs as a Starting Point

Reinsurance has begun moving onchain, but the models that have performed the best so far have primarily moved the capital layer—not the underlying risk.

OnRe is the clearest example of this capital-first model. Investors provide capital onchain, which then flows offchain and is put to work by their underwriters. The returns then flow back onchain as their token’s net asset value (NAV) increases. It connects crypto capital to real reinsurance risk without requiring the actual contracts to exist on a blockchain.

This is useful infrastructure. It gives onchain investors access to a return stream that was previously difficult to reach, whilst letting underwriting and claims management operate as usual.

Protocols such as Ensuro push further onchain, adding policy representation and automated settlement. Even there, the determination of what actually happened still rests with a trusted party.

Neither of these is the final form. As the space develops, platforms like these (or their successors) and their investors will increasingly expect more of the contract lifecycle to exist onchain. After all, that is what decentralised finance should be.

OnRe’s quick growth to roughly $190 million AUM at double-digit yields demonstrates the demand for access to established reinsurance programs. The constraint is access to the risk, not appetite for it. Decentralised capital currently has to go offchain to meet this exposure; would it be contrarian to assume that this capital would rather allocate to the truly onchain version of it?

A token whose value lives effectively offchain feels, to me, a little like “not your keys, not your crypto.” Once the risk leaves the chain, you can no longer see exactly what is being done with it. You are trusting an institution’s account of the underwriting, the exposures and the claims rather than observing them yourself. That is much of what moving onchain was supposed to fix.

TODAY IS A SPECTRUMmore of the deal moves onchain →Capital onchaine.g. OnReMost of the lifecycle onchaine.g. Ensuro — truth still offchainonchainoffchainInvestor capitalInvestor returnsUnderwriting · contractsclaims · settlementCapitalMarketplaceContractTriggerSettlementLoss index / model(source of truth)the lastcrossingTHE GOALCapitalMarketplaceContractTriggerSettlementVerifiable source of truthonchainoffchainLoss index / modelthe hard part
OnRe puts capital onchain and reaches the desired risks offchain; Ensuro puts more of the lifecycle onchain. What neither fully solves is settlement: getting the determination that a loss occurred and the trigger was met to act directly in the contract, without depending on a trusted data provider.

So how do we progress? How does the traditional (re)insurance market become comfortable with the full risk itself existing onchain?

It likely won't happen all at once. What's more probable is that one strong representation of a real deal onchain creates a path for other risks to follow as infrastructure develops and participants become more comfortable. A foot in the door.

Many reinsurance contracts depend on lengthy policy wordings, detailed assessments of an insured’s loss and claims decisions that involve a not insignificant amount of opinion. The process can be difficult to represent in code because the outcome is not always determined by a single transparent rule. An assessor may need to interpret what happened, decide what damage is covered and estimate its value.

Putting that kind of legal contract into a smart contract would introduce enormous complexity without necessarily creating much additional value. It would also leave the supposedly onchain product dependent on a highly centralised and judgment-based claims process.

Industry loss warranties—ILWs—can be different.

An ILW can be described using a relatively small set of terms:

  • when the coverage begins and ends;
  • which peril and geographic region it covers;
  • the industry-loss threshold;
  • the amount of protection purchased; and
  • whether the payout is binary, linear or follows another predefined structure.

These are discrete parameters. They can be represented in code, agreed before the risk period begins and used to determine exactly how collateral should move under different outcomes.

That makes ILWs unusually legible as onchain financial products. A buyer purchases protection, investors commit collateral, a defined event occurs and the contract either returns the collateral or pays out.

Most of this is straightforward to express in a smart contract.

The difficulty lies in the source of the trigger.

The open questions are who/what decides how much the industry lost, when it is final, and how a public financial contract can use a commercially licensed loss estimate without exposing the data behind it.

To understand why that is difficult—and why ILWs are still compelling—we first need to understand how they work today.

What Is an ILW?

An industry loss warranty is a contract whose payout is linked to the total insured loss caused by an event across the wider insurance industry.

Consider a simplified example:

A reinsurer buys €10 million of protection against European windstorms. The contract pays in full if an eligible storm causes more than €20 billion of insured industry losses during the coverage period.

The reinsurer pays a premium to the protection provider. If the reported industry loss exceeds €20 billion, the provider pays €10 million. If it does not, the provider keeps the premium and has no further obligation.

Industry Loss WarrantyCoverage period1 Jan – 31 Dec 2026TerritoryEuropePerilWindstormTrigger€20bn industry lossLimit€10mPayoutBinarySettlement sourceIndexIndex providerPERILS
The whole contract is a handful of parameters — legible enough to live in code.

Unlike indemnity-based insurance, the payout does not depend on calculating the buyer’s exact share of every loss caused by the storm. Instead, an independent third party estimates the loss suffered across the industry. In Europe, this might be PERILS; in the United States, it will often be Verisk’s Property Claim Services (PCS).

ILWs are generally bought by (re)insurers seeking additional protection against large catastrophes. They can be used to top up an existing reinsurance program, manage exposure to a particular region or peril, or obtain additional cover when traditional capacity is scarce or expensive. Put simply, they act as a hedge.

On the other side sit the capital providers: other reinsurers, ILS funds and other sources of catastrophe-risk capital. They receive a premium for accepting the possibility that they will have to pay out.

This creates a relatively simple transaction:

  1. The buyer pays for protection.
  2. The protection provider commits a defined amount of capital.
  3. An independent index provider estimates the industry loss.
  4. The contract applies its predefined payout formula.
  5. The protection provider either receives its capital back or pays out.

There is still basis risk. A buyer could suffer a large loss without the wider industry threshold being reached. Equally, the industry threshold could be reached while the buyer’s own losses are relatively limited.

Industry index lossBuyer's own loss< trigger≥ triggerlargesmallNo payoutbasis risk bitesPaysand it was neededNo payoutas intendedPaysmore than was lostDashed cells = basis risk: the payout and the buyer's loss disagree.
The trigger pays on the industry number, not the buyer's own loss. Basis risk is the off-diagonal: a large loss with no payout, or a payout with little loss.

That mismatch is part of the trade-off: the trigger is less tailored to the buyer, but it is also simpler and more rules-based than adjusting thousands of individual claims.

That simplicity is what makes the product interesting onchain.

Friction in a Simple Contract

The mechanics of an ILW may be simple, but the market around it is not necessarily efficient.

A buyer may rely on a broker to find capacity, negotiate terms and coordinate the placement — for a share of the premium. ILWs are already among the most standardised reinsurance contracts, with lower frictional costs than a bespoke treaty or a catastrophe bond.1 Even so, that cost is real, and standardisation is exactly what makes it compressible: a uniform contract is the kind of thing software should be able to place and settle at a fraction of the price.

Pricing is the larger inefficiency. It remains manual and opaque, negotiated case by case, and some brokers have even shown different price sheets to buyers and sellers.2 An onchain market could quote and match the same contract in the open.

A placement also has to be documented, collateral arranged and the relevant parties licensed to use the chosen loss index. Each step adds cost, administration and another intermediary.

Settlement is not instant either.

Industry losses cannot be observed immediately after a catastrophe. They must be estimated using claims information collected across the market, and that information develops over time.

PCS commonly provides its first US catastrophe estimate around 15 days after it designates an event.3 PERILS publishes its first estimate six weeks after an event, then revises it after three, six and twelve months, with additional reports where an event’s losses are still developing.4

These estimates do not only increase. They can also fall.

Following Cyclone Alfred in Australia in early 2025, PERILS put the industry loss at AUD 2.568 billion in its first report, then revised it down at every update: AUD 2.250 billion after three months, AUD 1.922 billion after six, and a final AUD 1.877 billion.5 An ILW triggering at AUD 2 billion would have looked comfortably in the money on the first two reports—then dropped below its threshold and stayed there.

trigger · AUD 2bn2.568bn6 weeksApr 20252.25bn3 monthsJun 20251.922bn6 monthsSep 20251.877bnfinalMar 2026
Cyclone Alfred: PERILS industry-loss estimate at each report, against a AUD 2bn trigger. Data: PERILS loss reports.

The parties must decide in advance which estimate controls the outcome, when settlement becomes final and how long the collateral remains locked. A contract that settles against the first estimate pays quickly but risks relying on an immature number. Waiting for a later estimate may produce a more reliable result, but delays settlement and traps capital for longer.

Disputes can also arise over the event definition, the covered peril or territory, and whether later revisions should be recognised. The trigger may be more rules-based than an indemnity claim, but it is not simply a live number waiting to be read from the internet.

In many cases, the number is also proprietary.

PCS provides its catastrophe data through subscription products. PERILS similarly licenses its indices on a per-transaction basis (a master trading licence plus a term sheet for each deal), and its legal terms restrict use to licensed parties and specific authorised transactions.6 The fact that a headline loss estimate may eventually become public does not mean the data can be freely used or redistributed.

This creates an immediate problem for an onchain ILW.

A smart contract needs an authorised source to tell it whether the trigger has been reached. But a public blockchain is designed to make information observable and replicable, while the index provider’s business depends on controlling access to that information. Wiring the provider in as an authorised oracle can bridge that gap, but it puts a single trusted gatekeeper back at the centre of a system designed to work without one. And as the next section shows, it does little to stop the value leaking once it is used.

Moving the contract onchain may remove friction around placement, collateral and settlement. It does not remove the need to produce a reliable industry-loss estimate, or to solve who is allowed to see it.

A Market, but Not Yet a Public One

Ideally, ILWs would exist within a live market rather than being placed through a chain of private conversations.

Buyers could request protection, capital providers could compete to offer it, and prices would reveal what different participants think the risk is worth. A reinsurer already heavily exposed to US hurricanes might demand a high premium, while another investor may view the same risk as diversifying and offer a lower price.

That variation is not a flaw. It's what creates a market.

But a public market would also reveal information. A company buying protection against particular perils, regions or loss thresholds may expose the shape of its portfolio, where it is concentrated and what it's most worried about.

Settlement creates another problem.

The index value itself is commercially licensed. Publishing it onchain would allow anyone to access information that other participants have paid to use.

Zero-knowledge proofs offer a partial solution. A protocol could prove that an authorised loss estimate exceeded €20 billion without revealing the estimate itself.

But even binary outcomes leak information.

Consider three contracts triggering at €20 billion, €21 billion and €22 billion. If the first two pay and the third does not, the market has learned that the estimate lies between €21 billion and €22 billion.

As more contracts are created, their combined outcomes could reconstruct the licensed value with increasing precision. Zero-knowledge can hide the input to one calculation; it cannot prevent information being inferred from many public outputs.

true loss inferred here19bn20bn21bn22bn23bntrigger €20bnpays ✓trigger €21bnpays ✓trigger €22bnno pay ✗
Three binary contracts, no index published. Yet 'pay, pay, no-pay' places the true loss between €21bn and €22bn — inferred from public outcomes, not revealed.

The outcome itself is just as hard to hide, because the money is a signal. In a fully collateralised ILW the locked capital either moves to the buyer when the trigger is met or returns to the seller when it is not, and anyone watching the chain can read the result from where the funds go. A public ledger of capital is, in effect, a public ledger of outcomes.

Some of this can be blurred if settlement is shielded, so flows are not publicly attributable. But shielding needs volume to work, and volume is exactly what an early market lacks.

There is a simpler observation, though. The providers may not need secrecy at all. They already license the same indices to many participants; what they guard is payment, not exclusivity. And payment is something a blockchain can enforce directly, so the provider can be wired in as a paid oracle whose signature settles a contract only when a licensing fee is collected in the same transaction. The chain becomes another metered channel rather than a threat to one.

Two leaks still remain. The first is the reconstruction seen earlier: if the trigger levels are public, the pattern of which binary contracts pay narrows down the licensed value. Many contracts wait on the same report and settle together, so the whole pattern appears at once and can pin the number to whatever the trigger spacing allows. That is only the binary case; a linear payout leaks more still, since the size of each payment tracks the value directly.

The second is piggybacking. Because a settled contract's result sits on a public chain, anyone can write a new smart contract that watches the first smart contract and pays out whenever it does. Such a smart contract needs no licence and never touches the index. It simply mirrors an outcome that is already public, letting its owner capture the same result without ever paying for the data.

Both leaks have the same fix: keep the contract's terms private. If only the counterparties and the resolver know the peril, trigger and size, a public resolution is an opaque bit. There is nothing to reconstruct and nothing worth piggybacking on, since the bit hedges nothing and redistributes none of the provider's number. The privacy that protects a buyer's book protects the provider's revenue too, and unlike a shielded pool it does not need a crowd to work.

None of this is airtight. A settlement landing just after a major storm plainly concerns that storm, and the capital that moves, read against the going rate-on-line, gives a sense of the position behind it. For a linear payout the flow tracks the value closely enough that it is barely hidden at all. Fully closing that still requires the shielding from before. Fundamentally, a public chain resists secrecy: while settlement plays out in the open, the outcome and the licensed value behind it are hard to hide completely.

Even so, this is somewhere to start, even if not the market I ultimately want. Two parties agree the terms of the ILW onchain privately, its logic and collateral sit onchain, and the provider resolves it against terms only the involved parties can see. Settlement may still depend on the same index providers the market already uses offchain; what changes is that their number settles the contract in onchain code, rather than through a claims process. The cost is centralisation: the resolver sees every position it settles, and the feed remains a trusted input. But it puts real deals onchain. The earliest participants may well be smaller shops: ILS funds and specialist players that feel the efficiency gains most directly, and so have the most reason to try something new.

The market I would rather see is open and decentralised: anyone can list, price and fund risk, and settlement does not rest on a single trusted verifier. That waits on two shifts. The first is a settlement source anyone can check, whose value does not evaporate once it is public, whether that's an openly available loss reference from an index provider or one produced some other way. The second is better privacy, so a public order book does not expose who is buying protection against what. Pseudonymity blunts that a little, since a visible position need not be tied to the name behind it, but it is thin cover, and the timing and size of a trade often give the player away. Until then, a private onchain market is the compromise that moves the deals onchain while that infrastructure catches up.

The Smart Contract Is the Contract

Everything an ILW needs can be encoded in a smart contract: the peril, territory, coverage period, limit, trigger and payout mechanics. Even the messy questions from earlier (which estimate settles the deal, and when it is final) can be written as rules. The contract might settle on the first published estimate, on a fixed later report, or at the point where two consecutive estimates differ by less than an agreed amount, with a hard deadline so collateral cannot be trapped indefinitely.

One objection is that none of this requires a blockchain; the parties could simply write clearer legal contracts.

But that misses the point.

If the trigger logic can be defined precisely enough to govern the deal, it should not sit in a document waiting to be interpreted. It should execute directly.

The smart contract is the contract. Its code defines how the trigger is evaluated, when settlement becomes final and how the collateral moves. There is no separate claims process and no later reinterpretation of the bargain.

A deal that still depends on someone deciding what the contract “really meant” has not truly moved onchain.

Even Ensuro, which goes furthest among today’s platforms, stops at this line. Purchase still mostly happens offchain: the policy is typically sold to a customer offchain and paid for in fiat through a partner. Resolution is often set by a trusted party who prices the risk and later settles the policy, writing the result back onchain. Its oracle-based variants are closer to what this essay has in mind: a chosen feed that settles the contract, rather than a discretionary decision after the fact. What is genuinely onchain is still mainly the capital and its accounting. The harder gap, the source of truth, is the line this essay is really about, and the one an onchain ILW has to cross.

An onchain ILW that crosses that line would also leave an auditable history of how the contract resolved, confirming that the payout followed the rules.

Communication could move from bespoke documents and emails towards standardised, machine-readable terms. Brokers could still provide advice, structuring and distribution, but software could remove much of the fee charged simply for matching known participants and administering a relatively standard contract.

At that point, DeFi is not being added for decoration. It provides the existing rails for holding collateral, executing shared logic and settling value according to predefined rules.

Collateral and Capital Efficiency

For the smart contract to be the contract, the money must actually be there when it needs to pay.

The cleanest design is therefore fully collateralised: a seller offering €10 million of protection locks €10 million into the contract. If the ILW triggers, the buyer is paid automatically. If it expires, the capital returns to the seller.

That design is also expensive. Locking the maximum payout against every individual deal may be considerably less efficient than traditional reinsurance.

Reinsurers don't usually hold capital equal to the combined limit of every contract they write. They hold capital against the risk of their wider portfolio, taking account of diversification and the likelihood that every contract will not suffer a total loss simultaneously.7

A naive onchain market would lose that advantage.

The answer may be to fully fund the system rather than separately collateralising every deal.

Capital providers could deposit into a shared vault supporting a portfolio of ILWs. When the protocol accepts a contract, it reserves part of the vault’s available capacity based on the deal’s exposure. It could enforce aggregate limits by peril, territory and event, preventing the pool from writing ten supposedly separate contracts that would all pay following the same hurricane.

The total protection written could exceed the vault’s capital, but only within transparent risk and solvency constraints agreed by its participants. This introduces some portfolio insolvency risk, but that risk already exists in traditional reinsurance. The difference is that capacity, concentrations and available collateral could be visible and enforced in code. Because the protocol can see the whole book, it can calibrate that under-collateralisation against diversification it is actually able to audit. That is something a dedicated platform is uniquely placed to offer, and a strong reason to build one rather than leave every deal to fund itself in isolation.

Deal 1 · €10mDeal 2 · €10mDeal 3 · €10mDeal 4 · €10m€40m lockedCollateralise every deal€40m capital · €40m cover · 1×Vault capital€25mcover writtenbeyond capitalOne shared vault€25m capital · €40m cover · 1.6×Diversification + aggregate peril/event limits back more cover per euro —introducing portfolio risk that already exists in traditional reinsurance.
Same €40m of protection. Collateralising each deal locks the full €40m; a shared vault backs it with less capital, bounded by aggregate limits.

Identity checks and under-collateralisation for credible participants may be what brings established players onchain, but they should be a way in, not a gate. The reason to build this in the open is inclusion: anyone able to meet transparent, auditable requirements should be able to take part, rather than a rebuilt version of the closed club that already exists offchain.

There is then a question of what investors actually own.

A token representing a single ILW would be hard to use elsewhere in DeFi: its value may depend on confidential terms, an illiquid contract and a catastrophe exposure another protocol may be unable to assess. A token representing a share of the wider vault is more plausible, with published net asset value, standardised accounting and exposure spread across many contracts. Even then, other protocols would need to understand the vault’s exposures, withdrawal restrictions and potential losses before treating it as collateral.

This may be where composability belongs: not at the level of each ILW, but at the level of the diversified pool supporting them.

The underlying risks can remain private. The capital layer does not have to be.

Modelled Loss

An index-based ILW must wait for the industry’s reported losses to develop. An alternative is to use a catastrophe model to estimate the loss caused by the event.

These are the same models that (re)insurers already use to price catastrophe risk, manage their portfolios and decide how much exposure they are willing to accept. The major vendors are AIR (now part of Verisk), RMS (now Moody’s RMS) and specialists such as KCC.

At a simplified level, a catastrophe model combines four components8:

  1. Hazard (HH): the frequency, location and severity of possible events.
  2. Exposure (EE): the assets and insured values located in the affected areas.
  3. Vulnerability (VV): functions translating hazard intensity into expected physical damage.
  4. Financial terms (gg): the insurance conditions (deductibles, limits, attachment points) applied to the ground-up loss to produce an insured loss.

For a single event, the calculation can be simplified as:

Le=iEi×Vi(He,i)L_e = \sum_i E_i \times V_i(H_{e,i})

Here, EiE_i is the value exposed at location ii, He,iH_{e,i} is the event’s intensity at that location, and ViV_i is the vulnerability function converting that intensity into a damage ratio. This gives the ground-up loss, LeL_e.

Applying the financial terms gg then turns that ground-up loss into an insured loss:

Leins=g(Le)L_e^{\text{ins}} = g(L_e)
Hazardintensity HₑᵢExposurevalues EᵢVulnerabilitydamage Vᵢ(·)Ground-up lossLₑ = Σ Eᵢ · Vᵢ(Hₑᵢ)Financialterms & structureInsured losssettles the ILW
A catastrophe model turns an event footprint into an insured loss. A modelled-loss ILW agrees a specific model version and exposure setup in advance; after the event, the observed footprint is run through that fixed setup and settlement follows the output.

When pricing risk, the model performs this calculation across a large catalogue of simulated events. Each event has an estimated frequency, allowing the model to produce a distribution of possible losses rather than one prediction.

A modelled-loss ILW uses the same machinery differently. The parties agree in advance on a specific model version, exposure data, covered perils and payout formula. After a real catastrophe, an observed event footprint is passed through the agreed model. The resulting modelled loss determines whether the contract pays, resolving the outcome faster than waiting for months of claims reporting.

Its modular structure suggests three routes to onchain settlement, each trading openness against the protection of intellectual property:

  • An open model, whose code and configuration (exposure data, assumptions and payout rules) are fixed before inception, so anyone can rerun it after an event and verify the loss, then submit the result, or a proof of it, onchain.
  • A private but verifiable model, where the parties commit to a hash of a proprietary model beforehand and later prove, in zero-knowledge, that it produced the settlement result without revealing the model itself.
  • A proxy model built for settlement alone. Running a full catastrophe model across many events yields a dataset linking observable event characteristics to modelled losses, to which a simpler function can be fitted:
L^=fθ(x)\widehat{L} = f_\theta(x)

For a hurricane, xx might include its track, wind speed and wind-field size. The proxy can be transparent, reproducible and simple enough for independent parties to verify, or even run directly onchain. For settlement you want it to match the full model well on the deals it covers. A provider can fit a bespoke proxy for a specific deal or market — one peril, region and exposure setup — used almost as a disposable settlement function. It does not have to expose the full model; it only has to stay close enough to what that model would say, within a tolerance the parties are comfortable binding to.

Rather than forcing today’s catastrophe models onto a blockchain unchanged, we may need to extract just enough of them to build a smaller, more credible onchain source of truth. The technical question is how such a model (or an index provider) could supply settlement data to a smart contract without making proprietary inputs, outputs or processes publicly available. I examine possible oracle designs, including verifiable computation, zero-knowledge proofs and proxy equations that approximate proprietary catastrophe models, in Can a Catastrophe Model Become an Oracle?

At first glance, modelled settlement looks almost perfect for an onchain contract: a fixed model and configuration, applied to an observed event footprint, produces a deterministic output.

But the model does not observe the event itself. Someone must still turn the real catastrophe into an event footprint the model can run — a structured account of where it hit and how severe it was. Different data sources, assumptions or interpretations produce different footprints, and even small differences in that representation or in the exposure data can materially change the result.

So the event footprint is really its own source-of-truth problem. Someone still has to produce the authoritative representation of what happened. That might come from a hazard-data provider, a meteorological agency or a modelling firm. And that input can be just as licensed, contested or centralised as the loss index it replaces.

A modelled-loss trigger therefore replaces one uncertainty with another. It avoids waiting for reported claims to mature, but makes the event data, model version and modelling assumptions part of the contract. Even then, the parties still have to choose which model governs settlement — and that choice is not purely technical.

A Common Language

A settlement model is a convention as much as a calculation. Both sides need to treat the same number as final, even if each thinks it overstates or understates the true risk. Pricing can stay private and contested; settlement cannot. So the parties do not need to share a view of the risk — only a reference they are both willing to bind to.

That is what the large catastrophe models and the main industry-loss indices already provide. Not agreement that they are right, but a way to write a contract without first inventing what “European windstorm industry loss” means. A buyer and a seller can argue about the rate-on-line while leaving the settlement reference unspoken, because everyone in the room already knows which one it is.

That convention is hard to challenge because so few alternatives exist.

Credible catastrophe models take years of investment and validation to build, and credible industry-loss indices are rarer still, since producing one takes privileged, market-wide data that almost no one else can assemble. The indices make the pattern clearest. PCS and PERILS did not become references by being judged flawless; they became references because reliable alternatives barely existed. When one did emerge (CRESTA's CLIX index for non-US losses), it was absorbed into PERILS in 2025,9 leaving the market with even fewer independent sources. That same scarcity is what lets them license and control the data in the first place.

That makes the incumbents hard to displace. They are both genuinely strong and widely accepted, and a challenger needs both. An open model wins nothing if its output is not credible, and a credible one wins nothing without acceptance. But a new provider does not have to displace them everywhere. It only needs to become the trusted reference for one clearly defined market. And that is really a question of how such a market begins.

How a Market Begins

There are several possible routes, and they probably lead to different kinds of markets.

The most natural starting point is to work with existing index and model providers. Their outputs are already accepted by the industry, which makes it easier for buyers and sellers to trust the resulting contracts.

But that acceptance comes with constraints. Their data and models are proprietary, their licensing may not support open settlement, and they may have little incentive to make their products easier to distribute onchain.

A second route is to work with smaller specialist providers.

A company focused narrowly on wildfire, flood or another specific peril (whose models reinsurers may already use to supplement and refine their main models) may be more willing to experiment. It may license its model for automated settlement, design a trigger that settles in code or allow its outputs to be used more openly.

That could create a smaller market at first, but one built around a source of truth designed for the product rather than adapted to it afterwards.

The third route is open-source models and indices.

An open-source model or community-produced loss index would remove much of the licensing problem. Contracts and settlement outcomes could be public without undermining a proprietary data provider.

That would make a genuinely open market possible: risks listed publicly, capital competing to fund them and settlement visible to everyone.

Open-source catastrophe models and frameworks already exist, but they are rarely treated as a primary industry reference for pricing or settlement; most still sit beside vendor models, or in research and climate work, rather than carrying large financial outcomes on their own. The difficulty is credibility. Who maintains the model? Who validates the event data? Who funds the work? And why should institutions trust it when real money is at stake?

The likely answer is not one system, but several.

Some participants may prefer private markets using established providers. Others may accept public transactions where the trigger data can be openly used. Over time, specialist and open-source providers may support markets that cannot exist under current licensing models.

Encoding and settling the contract onchain is the easier part. The harder question is who will provide the source of truth, and under what terms.

That may ultimately determine whether onchain ILWs become a more efficient private market or something genuinely open.

What Comes Next

ILWs are not the only reinsurance contracts that could move onchain, but they may be the clearest place to start.

Their core mechanics are already relatively simple: defined coverage, defined triggers and defined payouts. The difficult parts are not the smart contract itself. They are the data, licensing, collateral and market structure around it.

A private market between established participants could move much of the lifecycle onchain now, still using the index providers the industry already trusts. A genuinely open market will require more: settlement that does not depend on one centralised verifier — data providers willing to support public settlement, specialist models designed for smart contract usage, or credible open-source alternatives.

The goal should not be to place a token around an otherwise unchanged reinsurance process. It should be to build markets where the underlying risk is represented, funded and settled directly onchain.

I do not think the path there is fully clear yet. But ILWs provide a useful place to test the boundaries, and perhaps the first step from onchain reinsurance capital to onchain reinsurance itself.

References

  1. Nadine Gatzert & Hato Schmeiser, "Industry Loss Warranties: Contract Features, Pricing, and Central Demand Factors", Journal of Risk Finance 13(1), 2012.

  2. "Stonybrook automates ILW price sheets with ILWBroker.com service", Artemis.bm.

  3. Property Claim Services, "PCS Consolidated Methodology", Verisk.

  4. PERILS AG, "Industry Loss Index Service".

  5. PERILS AG, "AUD 1,877m: PERILS releases final industry loss footprint for Cyclone Alfred".

  6. Under Solvency II, EU (re)insurers hold risk-based capital (the Solvency Capital Requirement), not capital equal to the sum of all contract limits. The Institute of Risk Management, "Diversification benefit: understanding its drivers and building trust in the numbers", notes that Solvency II’s diversification benefit can reduce required capital by up to 50% relative to summing standalone risk charges.

  7. National Association of Insurance Commissioners, "Catastrophe Models (Property)".

  8. CRESTA, "CRESTA CLIX Q4 2024 update and integration into PERILS", press release, 2 January 2025.