Insurance Contracts

TREA ships three ready-to-use insurance contract templates for institutional product flows:

• contracts/products/insurance_single_premium.trea
• contracts/products/insurance_periodic_premium.trea
• contracts/products/insurance_parametric.trea

They model the financial lifecycle of a policy rather than an off-chain document workflow. Premium, reserve and payout are separate accounting effects, claims require explicit authority, and parametric events enter as signed transaction inputs from the configured oracle authority.

Products

SinglePremiumPolicy collects one premium, places the coverage reserve, allows the insured to open a claim, requires a claims authority decision, and pays the beneficiary only after approval.

PeriodicPremiumPolicy follows the same claim path, but renews coverage with recurring premiums. If the next premium is overdue, the insurer can declare Defaulted, and new claims are blocked.

ParametricInsurance replaces manual claim approval with a configured oracle authority. The oracle submits an event_id plus valid_until; stale events, duplicate events and unauthorized callers are rejected.

States

The templates use explicit lifecycle states:

• Quoted
• Covered
• ClaimOpen
• ClaimApproved
• ClaimDenied
• EventTriggered
• Paid
• Expired
• Defaulted
• Cancelled

Not every product uses every state. For example, parametric insurance uses EventTriggered instead of manual claim approval, and only the periodic-premium product uses Defaulted.

Participants

The templates store the relevant parties directly:

• insurer/admin
• insured
• beneficiary
• claims authority, for manual claim products
• oracle authority, for parametric insurance

These fields are visible to ABI, receipts and AI Audit. They also make wallet rendering straightforward: the user can see who pays, who receives the indemnity, and which authority controls the decision.

Accounting Effects

The runtime exposes three insurance posting helpers:

• insurance.premium_lines(asset, insured, insurer, amount)
• insurance.reserve_lines(asset, insurer, amount)
• insurance.payout_lines(asset, insurer, beneficiary, amount)

They map to distinct operation kinds:

• InsurancePremium
• InsuranceReserve
• InsurancePayout

This keeps premium collection, reserve segregation and indemnity payout semantically distinct in simulation, execution effects and receipts.

Receipts

Each lifecycle step emits domain events plus a normalized InsuranceReceipt event:

InsuranceReceipt(
  policy_id,
  claim_or_event_id,
  insured,
  beneficiary,
  decision,
  effect,
  final_state,
  amount,
  asset
)

Examples:

• activation emits decision = "premium_collected", effect = "premium_and_reserve", final_state = "Covered"
• claim denial emits decision = "denied", effect = "claim_decision", final_state = "ClaimDenied"
• payout emits decision = "paid", effect = "payout", final_state = "Paid"

Ledger execution receipts persist emitted events and posting effects, so a downstream wallet, explorer or auditor can reconstruct policy id, claim id, participants, decision, economic effect and final state.

Simulation

Before signing, callers can simulate the next entrypoint and inspect the planned posts:

• activation previews premium debit/credit and reserve movement
• payout previews reserve release to the beneficiary
• denied claims, expired policies, defaults, stale parametric events and duplicate payouts fail without producing posting effects

The E2E tests exercise this by cloning the contract runtime for dry-run execution and asserting that the original state is unchanged.

AI Audit

Predeploy AI Audit sees the authority fields, monetary posting effects, expiry/cancellation surface and lack of external ContractRef dependencies. That gives institutional reviewers a deterministic summary of:

• who controls claims or parametric events
• which entrypoints move value
• whether there is expiry or cancellation protection
• whether the product depends on another on-chain contract

No HTTP or off-chain lookup happens during contract execution. External facts enter only through signed transaction parameters submitted by the configured authority.