Insurance Logic, On Chain: A Builder's Notes on RaterSpot Programs

Most conversations about insurance and blockchains start with policies, claims or capital. This one starts somewhere more basic: the rating program, the set of rules that turns information about a risk into a price.

At IEC, InsurEco's web3 work, we are looking at what it takes to bring real insurance rating programs on chain. Our concrete case is RaterSpot programs. This post covers what a rating program is, why its logic is a reasonable candidate for an on-chain environment, what the work involves, and what we are deliberately not claiming. The working notes live here: RaterSpot programs on chain.

What a rating program actually is

Strip away the industry vocabulary and a rating program is a function. It takes inputs about a risk, such as the kind of property, where it sits, the coverage chosen and the limits requested. It applies a defined sequence of steps: base rates, factors, tables, adjustments and rounding rules. It returns a number.

The important properties for builders are these:

• It is rule-based. Every step is written down. A program is meant to produce the same answer for the same inputs.
• It is ordered. The sequence matters. Applying a factor before or after a minimum, or rounding at one step rather than another, changes the result.
• It is versioned. Programs change over time, and the version in force when a quote was produced matters.

Those properties are why rating logic is interesting to anyone who works with deterministic execution environments.

Why look at rating logic on chain

A blockchain is, among other things, a shared place to run and record deterministic computation. Rating programs are deterministic computation. The overlap is the starting point, not a conclusion.

The questions worth asking are mechanical ones:

• Can the logic be expressed faithfully? A rating program written for a conventional system has to be translated into a form an on-chain environment can execute. The translation has to preserve every step, every table lookup and every rounding rule.
• Can a result be reproduced? If a rate is computed from a given program version and a given set of inputs, anyone with the same version and inputs should be able to arrive at the same number.
• Can the version be pinned? When a program changes, the record should show which version produced which result.

These are descriptions of mechanisms. Whether they prove useful in practice is what the work is meant to find out.

RaterSpot as the working case

Abstract arguments about "insurance on chain" tend to drift. A real program keeps the work honest, because a real program has all the awkward edges that toy examples leave out: lookup tables with gaps, factors that only apply in certain conditions, minimums and maximums, and rounding conventions that look trivial until a result is off by a cent.

That is why we are using RaterSpot programs as the concrete case. Working from programs built for actual rating means the question is never "could insurance logic run on chain in principle?" It is "does this specific program, step by step, produce the right answer when expressed this way?"

What the work involves

For builders who want to picture the shape of the effort, it breaks into a few recurring tasks.

Translating the rules

Each program has to be read as a specification and re-expressed. That means mapping inputs to typed values, representing rate tables in a form that can be looked up reliably, and encoding the order of operations exactly as written.

Handling numbers carefully

Insurance rating is full of decimals and rounding. On-chain environments generally favour integer arithmetic. Bridging the two without changing results is detailed work, and it is where small discrepancies tend to hide.

Checking against known results

A translated program is only useful if it agrees with the original. The natural test is comparison: run the same inputs through both and confirm the outputs match. Disagreements point to a step that was misread or mis-encoded.

Keeping versions straight

Programs are revised. Any on-chain representation needs a clear way to identify which version is in use, so that a result can always be tied back to the rules that produced it.

What we are not claiming

In keeping with how IEC works, it is worth being exact about the limits of this post.

• We are describing work in progress, not a finished system.
• We are describing mechanisms (translation, reproducibility, versioning), not promising outcomes for any market participant.
• There is no token, no participation programme and no offer of any kind attached to this work. It is engineering.

If you see claims elsewhere that go further than this, they are not ours.

Why builders might care

If you build on chain, insurance rating is an unusually clean example of real-world logic: well specified, heavily tested in its original setting, and unforgiving of small errors. It is a good test of whether on-chain tooling can carry business rules exactly, not approximately.

If you come from insurance, it is a chance to see your own domain's logic examined step by step in a different execution environment, and to judge for yourself where that helps and where it does not.

Follow along

This is a builder's thread, and the work is continuing. We will keep sharing what we learn as RaterSpot programs are worked through: where translation is straightforward, where it is hard, and where the numbers needed a second look.

The working page is RaterSpot programs on chain, and this post lives at news.insureco.io. If you are building in this space, follow along and bring your questions about the mechanics.