Earthquake Parametric (Re)Insurance Infrastructure

1. Abstract

Japan faces the world's hardest-to-price catastrophe peril — and pricing, delegating, and settling specialty reinsurance covers still run on manual, offline processes. Trigger design is non-trivial, accumulation is severe, and bordereaux between cedants, syndicates and brokers are produced offline, weeks or months after bind.

DeIn Labs operates as an MGA / coverholder— the operating layer for Lloyd's parametric catastrophe binders. DeIn connects real-time risk-adjusted pricing, digitally structured policy logic, bordereaux at source, a live accumulation & capacity view for the managing agent, and delegated authority enforced in code — in a single programmable stack on Ethereum. Risk capital stays with the carrier (syndicate); DeIn holds no claims-paying capital in the coverholder model.

Key functions ① (bordereaux / CDR origin generation) and ② (real-time accumulation / capacity dashboard) are implemented. Supporting function ③ (delegated authority as code + continuous audit) is planned for on-chain implementation. Alternative-capital structures — DAO reserve, staking, tokenised yield — are Phase 3 optionality, activated only after regulatory admissibility.

2. The Problem

2.1 Japan Earthquake Context

The Japanese archipelago has entered a period of heightened seismic activity. Major earthquakes with maximum seismic intensity 7 have occurred repeatedly in recent decades, each causing severe human and economic loss:

Sources: USGS & JMA (magnitudes, Mw); Cabinet Office of Japan, World Bank, NOAA/NCEI, Moody's RMS, Gallagher Re (economic & insured losses).

2.2 Three Structural Frictions

3. The DeIn Solution

An earthquake-native parametric reinsurance infrastructure: run delegated catastrophe treaties that are auditable and capital-efficient — through real-time pricing, structured policy logic and automated payout for the wholesale market.

3.1 Why On-Chain, Not an Overlay

AI and Web2 overlays detect and advise on top of today's systems. Three problems can't be observed away — only solved by changing the rail itself.

4. Insurance Concept

A DeIn policy is a parametric cover that pays out a contracted reimbursement multiplier if a qualifying seismic intensity is observed within the policy's validity period, in the policy's designated region. Policies are issued — and re-priced — in real time on a per-prefecture basis.

4.1 Reimbursement Multiplier

The reimbursement (payout) multiplier is derived from four factors:

1. Base multiplier — the reciprocal of the one-year earthquake probability for the designated region.
2. Fee rate — a calibrated buffer fed into the treasury for solvency and operations.
3. Coverage ratio — the insurance fund's payout capacity at the time of issuance.
4. Regional concentration — a diversification penalty applied when exposure is unbalanced across regions.

Earthquake probability inputs are referenced from external models and authoritative sources (e.g. the Earthquake Research Committee of HERP). As each new policy shifts the pool balance and regional concentration — and as capital and seismology inputs update — the pricing engine re-prices the multiplier for new issuances in real time. Policy contracts already on-chain are unaffected.

The rate is computed off-chain, signed on-chain, and locked in the policy NFT at bind. Off-chain compute keeps pricing logic flexible and gas-efficient; the cryptographic signature and the NFT lock make the terms tamper-evident and reproducible from on-chain state for any counterparty or regulator who needs to verify what was agreed at the moment of bind.

5. Design Principles

Three architectural choices make DeIn fundamentally different from any platform retrofitted from legacy systems. They are not features — they are the commitments that earn counterparty and regulator trust.

The principles reinforce one another: Everything as Code is the precondition for One Programmable Stack, which in turn makes Auditable by Default achievable. Together they map directly onto the three frictions — Difficult Peril and Product Launch Friction are addressed by Principles 1 and 3; Settlement & Trust Friction by Principle 2.

6. Product Architecture

DeIn's on-chain infrastructure is composed of eight functional modules across insurance, treasury, yield and governance layers. Each module is deployed as an Ethereum smart contract and exposes explicit, auditable interfaces to stakeholders and external protocols. A 48-hour governance timelock delays all parameter changes, so every adjustment is transparent and auditable before it takes effect.

6.1 Core Modules

6.2 Stakeholders

• Policyholders (Premium Payers) — purchase parametric cover and receive automatic payouts on trigger verification.
• Stakers (First-Loss Capital) — deploy underwriting capital and receive DEIN governance tokens.
• DEIN Token Holders (Equity & Governance) — participate in governance and Merkle-tree dividend distribution.
• System Operators (MGA / Admin) — operate the protocol within the bounds set by DAO governance.

6.3 External Protocols

• Chainlink Functions — oracle layer for trigger verification.
• P2P Earthquake API — current demo seismic data source feeding Chainlink; multi-source / official-grade redundancy on the roadmap.
• Lido wstETH — ETH staking yield (planned Phase 3+ integration).
• Ethereum Network — settlement layer.

6.4 Delegated Authority Operations

DeIn's coverholder operating functions — bordereaux / CDR origin generation, live accumulation and capacity oversight, delegated authority as code, and KYC / sanctions gating — are described in detail in Section 7. Key functions ① and ② are implemented; supporting function ③ is planned for on-chain implementation.

7. Coverholder Operating System

7.1 Executive Summary

This section reframes DeIn from a blockchain earthquake insurance product to the operating system for Lloyd's parametric coverholders— delegated underwriting back-office as code. The goal is to align with Cohort 17's Operational Efficiency theme as market-wide infrastructure adoptable across products, not a single policy SKU.

7.2 Why Delegated Authority

Lloyd's delegated authority (DA) accounts for roughly 40–45% of market premium and is still growing. A syndicate grants a coverholder or MGA binding authority to underwrite within defined limits — exactly the role DeIn targets for parametric earthquake cover.

The largest operational pain is the bordereaux bottleneck. Coverholders must report which contracts were bound, at what premium, and what was paid out — typically monthly or quarterly — yet reporting still relies on spreadsheets, copy-paste from legacy systems, and manual formatting. Delays and errors can trigger delegated authority reviews, authority reduction, or contract termination.

Lloyd's is moving toward Core Data Records (CDR) and validation-on-receipt via tools such as the Delegated Data Manager (DDM), rather than month-end reconciliation. Mandatory DDM use has been withdrawn; each firm may choose its own solution — creating room for alternative origin-data platforms.

DeIn issues every policy as structured data (NFT certificates) and records every payout as an on-chain event. The facts required for reporting therefore already exist at source in machine-readable form — the foundation for the functions below.

7.3 Key Function ① — Bordereaux / CDR Origin GenerationImplemented

Problem: Bordereaux reporting is manual, delayed and error-prone — the dominant bottleneck in a channel that represents ~40% of the market.

Function:From policy NFTs and on-chain payout events, DeIn auto-generates Lloyd's-format risk, premium and claims bordereaux and Core Data Record equivalents — with bind-time validation — and delivers them via API to the managing agent or DDM. Structured chain records become reporting data directly: zero re-keying, always reconciled, audit-ready.

Architecture

• Origin layer (on-chain): at bind and payout confirmation, reporting fields are generated from the event.
• Mapping layer (off-chain): an adapter maps to Lloyd's Coverholder Reporting Standards and CDR field definitions; swappable as standards evolve.
• Integration: API delivery to the managing agent's chosen rails (DDM, etc.) for validation-on-receipt.

DeIn does not claim full CDR / Blueprint Two compliance in a prototype. The design goal is origin-data generation routable to market-chosen rails — sufficient for Operational Efficiency demonstration.

7.4 Key Function ② — Real-Time Accumulation & Capacity DashboardImplemented

Problem: Insurers fear accumulation — regional concentration can exhaust syndicate capital in a single event. Today, accumulation is often visible only from delayed bordereaux, forcing reactive portfolio management.

Function: Because DeIn pricing is accumulation-aware, exposure by region and cat zone, modelled loss (PML), and consumed / remaining capacity update on every bind. Syndicates receive a live dashboard instead of a back-mirror view weeks later.

Architecture

• Outputs from the existing off-chain concentration and capital-linked pricing engine feed a portfolio view.
• Regional / cat-zone accumulation and remaining capacity visualised; incremental update on each bind event.
• Read-only managing-agent view with role-based access control.

7.5 Supporting Function ③ — Delegated Authority as Code + Continuous AuditPlanned On-Chain

Concept: Compliance by construction — rules are embedded so violations cannot be issued in the first place.

• Authority as code: binding limits, accumulation caps, excluded territories and sanctions rules are embedded in bind logic; out-of-authority policies cannot be minted.
• Signed attestation: each bind carries a tamper-proof proof that it was within delegated authority.
• Continuous audit: every transaction is recorded with compliance proof, replacing periodic coverholder audits with always-on verification.

This directly addresses syndicate fear of authority leakage from coverholders — structurally preventing it and proving compliance. It aligns with Theme 1 (vetting / oversight) and the auditable-by-default design principle.

7.6 Supporting Function ④ — KYC / Sanctions ScreeningPlanned Off-Chain

KYC and sanctions screening cannot be executed automatically inside a smart contract. DeIn does not claim “automated KYC.”

DeIn does not invent KYC — it plugs standard KYC/AML rails and makes outcomes verifiable and reusable on-chain. Capital providers (stakers / first-loss) require the strictest screening; corporate policyholders typically onboard through the MGA with sanctions checks. Function ④ is not a demo centerpiece; screening runs off-chain through established providers and is planned off-chain as part of the platform roadmap.

7.7 Theme 3 Bridge — First-Loss Capital × Live Accumulation

Live accumulation (function ②) can be linked to a first-loss tranche so syndicates see that the book always matches committed capital — a capital adequacy module without leading with crypto terminology. Alternative capital is framed as capital discipline (Theme 1) plus an alternative-capital channel (Theme 3 differentiation), gated to Phase 3 with institutional KYC and regulatory admissibility.

First-loss staking models exist in DeFi (e.g. Nexus Mutual). The novelty here is bridging that mechanism to a regulation-aware Lloyd's specialty context — not claiming invention of the staking pattern itself.

8. Trigger-to-Payout Flow

1. STEP 01

   Product Terms & Pricing

   The pricing engine computes the reimbursement multiplier from earthquake probability, regional concentration, capital adequacy and the fee-calibrated buffer.

2. STEP 02

   Policy Logic Structured

   A certificate NFT is minted with explicit terms — region, multiplier, validity period — stored as verifiable on-chain rules.

3. STEP 03

   Trigger Event Verified

   Seismic data is pulled via the oracle-enabled workflow. Intensity, location and time are compared against the certificate's trigger threshold.

4. STEP 04

   Payout Amount Computed

   If the trigger is met, payout is calculated per the policy's multiplier. The computation is deterministic and reproducible from on-chain state.

5. STEP 05

   Payout Executed

   Funds are disbursed automatically from the Payout Engine. The product is designed for next-day settlement, with the full event-to-payout trail transparent and verifiable on-chain.

9. Capital Pool & Yield Architecture (Phase 3)

When operating in Phase 3, DeIn's treasury is organised as three coordinated pools, each with distinct purpose and risk treatment:

9.1 Yield Management

Yield management is integrated through Lido wstETH. Multi-pool treasury rebalancing logic is in progress. Staking participants earn yield not only on their deposited capital, but also from the premium pool's allocations — enabling enhanced returns within explicit, governance-bound risk limits. The final yield-protocol mix for catastrophe-insurance liquidity is among the design questions being refined with practitioners (see Roadmap).

9.2 Impairment & Solvency

If trigger events deplete the Premium Pool, a portion of staked principal may be impaired to fund payouts. After impairment, Capital principal and yield are reallocated to the Premium Pool as a solvency buffer, ensuring continued underwriting capacity. This cascading structure preserves payout integrity for policyholders while making the underlying risk explicit and visible to stakers.

10. Governance & DEIN Token (Phase 3)

The governance framework and DEIN token described here belong to the Phase 3 alternative-capital model. In Phase 1 the protocol operates under coverholder authority with the carrier's governance and capacity.

10.1 DEIN Token — Governance & Utility

DEIN is a governance and utility token. Its purpose is to coordinate underwriting capital and align stakers with the protocol's solvency and discipline — not to serve as a speculative instrument.

• Governance. Token holders vote on-chain over protocol matters (see §10.2). Because governance lives on-chain, investors can decide these matters by vote and have approved resolutions execute automatically through smart contracts — without convening a general meeting or similar corporate procedures. Execution is subject to the 48-hour timelock.
• Capital alignment. Tokens are allocated to investors who provide capital to DeIn Labs.
• Performance-linked distributions. When the capital pool exceeds its solvency threshold, surplus is distributed to stakers via Merkle-tree proofs. Distributions derive from protocol performance — premium and yield net of claims — not from token trading.

10.2 Example Governance Parameters

• Multiplier setting logic
• Expansion of insured regions (incl. overseas)
• Product expansion
• Oracle configuration / changes
• Treasury fund investment destination
• Dividend payment proposals

11. Market Opportunity

11.1 Japan Earthquake Is the Wedge, Not the Endpoint

11.2 Where DeIn Sits in the Value Chain

DeIn enters the specialty (re)insurance market as an MGA / coverholder. The carrier (syndicate) provides underwriting capacity and delegated authority; DeIn structures and operates the product; brokers place coverage with clients; a fronting insurer issues and administers policies; the policyholder receives transparent, rapid earthquake protection.

11.3 Path to Market

A phased go-to-market sequences proof, scale and capital — each stage de-risking the next:

The first step is obtaining specialty-market coverholder authorisation — a proven route that lets DeIn validate the market capital-efficiently in its first three years.

12. Roadmap

1. Product Implementation (Testnet)

   Completed
   • Insurance certificate NFT issuance
   • Earthquake oracle & automatic payout
   • DAO governance implementation
   • Staking & yield function
   • Tranche-based capital pool

2. Feature Enhancement

   In Progress
   • Donation function
   • NFT marketplace (secondary trading of insurance certificate NFTs)

3. Go-to-Market Validation

   In Progress
   • Assess initial market entry route: B2B reinsurance vs. retail
   • Validate B2B (re)insurance entry with cedants, syndicates and underwriting partners
   • Validate retail / domestic launch route under Japan small-amount short-term insurance framework
   • Refine pilot-ready parametric earthquake product structures with practitioners

4. Open Design Questions — To Resolve with Practitioners

   In Dialogue
   • Pressure-test pricing, data & payout assumptions against underwriter feedback
   • Settlement currency strategy — ETH (Web3-native) vs USDC (institutional B2B) vs JPYC (Japanese market)
   • Yield-protocol selection for catastrophe-insurance liquidity (Lido wstETH and alternatives)
   • Web3 × regulatory fit — reconcile settlement currency, yield protocol and on-chain treasury with solvency-capital, liquid-asset and AML frameworks of partner syndicates and regulators

5. Launch Preparation

   Under Discussion
   • Insurance regulatory compliance (Small Amount & Short-Term Insurance / derivatives)
   • Cabinet Office sandbox application
   • Corporate structure
   • International pitch participation
   • Seed round — funds smart-contract audit & Mainnet
   • Smart-contract audit

6. Service Launch

   Planned
   • Specialty (re)insurance market entry — B2B coverholder / MGA route (cross-border first)
   • Japan domestic retail launch — via insurtech partner + Cabinet Office sandbox (small-amount short-term insurance)
   • Stable administration
   • IEO (Initial Exchange Offering)
   • Listing on CEX / DEX

7. Service Expansion

   Planned
   • Other natural disaster / inflation insurance
   • Global expansion
   • DAO autonomation

13. Team

Working professionals — actuarial & derivatives, payment engineering and data science & AI — who built DeIn end-to-end, mentored by the Endowed Chair for Blockchain Innovation, the University of Tokyo. Founders commit the three mandatory in-person weeks at Lloyd's.

14. References

• Swiss Re Institute. sigma 3/2024 — World insurance.
• Headquarters for Earthquake Research Promotion (HERP), Earthquake Research Committee — long-term evaluation, Sept 2025 revision.
• General Insurance Rating Organization of Japan (GIROJ) — household earthquake insurance penetration statistics, 2023.
• Japan Meteorological Agency & Fire and Disaster Management Agency — seismic intensity 7 event records.
• Chainlink Functions — oracle infrastructure documentation.
• P2P Earthquake Information — seismic data API.
• Lido — liquid staking protocol (wstETH).

This document describes a research and development protocol on Ethereum Sepolia testnet. It is provided for informational purposes only and does not constitute an offer of insurance, a solicitation, or financial advice. Production deployment is subject to regulatory review and smart-contract audit.