Parametric Pulse. Making automatic payouts depend on evidence and reserved capital

Our work

We developed the policy and settlement components for Parametric Pulse. Our work connected external event evidence to coverage terms, reserved underwriting capital and the payout rules enforced by the contracts.

An automatic payout is useful only if the system can establish that the agreed event occurred and still has the capital to pay for it. Those conditions become difficult when the event happens outside the blockchain. A payment report may arrive late. Two data providers may disagree. Meanwhile the investors funding protection may want their capital back. Parametric Pulse brings those dependencies into the policy lifecycle instead of leaving them to be resolved after a claim appears.

The project is infrastructure for parametric insurance, reinsurance and credit-default protection around tokenized real-world assets. Coverage connects a registered exposure to predefined triggers, approved data sources and reserved underwriting capital. Our architectural approach separates event observation from the decision to settle and separates vault custody from permission to realise a loss. The main challenge was making settlement deterministic without treating imperfect external data as unquestionable truth. The second was keeping active coverage funded while allowing the underwriting pools to manage liquidity.

The policy had to fix the decision before the risk began

Parametric protection settles against a specified condition. That condition might be a payment remaining overdue beyond a grace period or a loan pool crossing an agreed default threshold. The architecture therefore begins with a Risk Reference identifying the external obligation. It can carry issuer and servicer commitments, currency, jurisdiction and a payment-schedule root. A Policy then binds that exposure to the buyer, beneficiary, coverage amount, premium, trigger and payout formula. Sensitive external records are referenced rather than copied into public contract storage.

The distinction matters because the same observation can mean different things under different contracts. A missed payment before a grace period ends does not have the same effect as one that remains unpaid afterward. A trigger may require persistence, a confirmation period or agreement among several sources. The policy records those terms before activation. The Policy Factory validates the coverage configuration and the policy becomes active only through the funding and readiness stages. Core economics are immutable or hash-committed once coverage starts, so a later event is evaluated against an existing agreement.

We kept trigger evaluation modular but bounded. Approved evaluator modules handle supported risk types and a constrained composite engine can combine comparisons, time windows, persistence rules and quorum conditions. Its instruction set includes operations such as GT, WITHIN_WINDOW, PERSIST_FOR and QUORUM. It does not allow arbitrary policy scripts. This limits the amount of logic that must be understood to determine whether a trigger is valid and keeps evaluation tied to reviewable modules. Product variation comes from explicit configuration rather than unrestricted code supplied with each policy.

Auto-settlement could not mean trusting the first report

External data crosses the most important trust boundary in the system. An authentic report can still be stale or derived from the same source as another report. The Oracle Router normalises observations before an evaluator sees them. Each observation identifies the metric, source, value and schema alongside observation, publication and ingestion timestamps. Source authenticity, adapter integrity and source independence remain separate checks. Passing one does not establish the others.

The independenceGroup field addresses a subtle quorum problem. Two APIs may expose the same underlying database. Counting them as independent votes would create the appearance of corroboration without a second source of evidence. Grouping related feeds lets the configured quorum distinguish multiple delivery routes from genuinely separate observations. The same care applies to timing. A recent publication may describe an old event, while a late report may still describe a valid event inside the coverage window. Freshness and reporting delay therefore have separate semantics.

Contradictory observations enter a CONFLICTED state and stop finalisation. Missing or stale data also cannot silently become evidence that no trigger occurred. We implemented a bounded unresolved state with a deterministic fallback fixed before policy activation. Unresolved evidence remains a distinct policy state until its configured resolution path completes. It is not recorded as either a settled claim or an expired policy.

A trigger candidate needed its own place in the lifecycle

A threshold crossing may deserve investigation without yet satisfying every contractual condition. Parametric Pulse separates TRIGGER_CANDIDATE from TRIGGERED. Candidate evidence passes through the required confirmation process before settlement becomes available. If confirmation fails the policy can return to active observation. If the trigger is finalised it proceeds toward settlement. This prevents a temporary or unconfirmed signal from being treated as a completed financial decision.

The state machine also makes terminal outcomes explicit. A settled policy cannot return to active coverage and an ordinary post-activation cancellation cannot remove exposure unless that product defined the cancellation right in advance. Emergency suspension has its own treatment. A policy can resume where appropriate, while a trigger finalised before suspension retains a path toward settlement. Those distinctions give operators a precise account of what remains pending without giving them discretion to rewrite the payout condition.

The table shows the core trigger path. Data conflicts and emergency conditions have separate handling rather than being forced into those four states. Keeping them distinct is necessary because a lack of usable evidence is not the same event as a failed trigger.

Deterministic settlement starts before the event occurs. Parametric Pulse records accepted evidence, uncertainty handling and committed capital before coverage begins. Automation can then apply an agreed rule without inventing a decision when data or liquidity becomes difficult.

Capital reservations stay separate from withdrawals

An underwriting vault needs to accept capital and support withdrawals. An active policy needs its reserved capacity to remain available throughout the risk period. If a withdrawal can remove funds already committed to coverage the policy is backed by a promise instead of controlled assets. We separated vault custody, capital allocation and loss realisation so those responsibilities cannot collapse into a single unrestricted withdrawal path.

Reinsurance Vaults use ERC-4626-compatible share semantics with risk-aware accounting. The vault tracks total assets alongside allocated capital, withdrawal reserves and a safety buffer. Available capacity follows the explicit relationship freeCapital = totalAssets - allocatedCapital - pendingWithdrawalReserve - safetyBuffer. This makes the difference between assets in the vault and assets available for new risk visible. A vault can hold liquidity without all of it being free to allocate or withdraw.

The Capital Allocator reserves a defined amount for a policy and records its capital domain, priority and release conditions. The policy itself does not gain arbitrary access to the vault. A withdrawal request queues under high utilisation rather than escaping existing commitments. This creates a real constraint for liquidity providers, but it preserves the funding basis on which protection was activated. Unused capacity can return according to the policy lifecycle once the relevant obligations are resolved.

The architecture keeps the following boundaries explicit.

• Vaults hold assets and maintain capital accounting.
• The allocator reserves capacity against identified policies.
• Oracles supply observations without controlling payouts.
• Trigger evaluators apply the committed event rules.
• The Settlement Engine realises authorised losses.

This separation also limits the effect of a failure. A policy contract cannot withdraw unrelated liquidity simply because it has reached a trigger state. Access remains bounded by its allocations and the settlement rules. Capital isolation is therefore an accounting property as well as a contract permission boundary.

The payout formula and loss order had to agree

Finalising a trigger establishes that settlement is permitted. It does not give the caller permission to choose the amount. The Settlement Engine calculates the payout from committed policy terms and finalised observations. Supported models include a fixed amount, a percentage of notional, a capped loss-proportional payment and a shortfall-based payment. A layered policy applies attachment and exhaustion points to define the portion of loss covered. Different protection products can use different formulas without changing who is authorised to supply their inputs.

Funding follows a separate deterministic waterfall. The configured waterfall orders first-loss, junior and senior capital. Each layer pays only within its remaining allocation. The engine records both the amount owed to the beneficiary and the capital domains funding it. Capping the payout alone would not be sufficient if settlement could charge an unrelated vault. Allocation limits and payout limits protect different sides of the same operation.

Settlement records the final trigger set, payment asset, amount, capital sources and any fee deductions while updating vault accounting. The terminal policy state and completed settlement record prevent a repeated attempt from paying twice or realising the same loss again. If no qualifying event occurs, capital release and premium treatment follow the agreed policy terms instead of an improvised closing decision.

A reverting beneficiary keeps a claimable entitlement

Even with a valid trigger and sufficient capital a direct transfer can fail at the recipient boundary. A beneficiary may be another contract whose receiving path reverts. Tying the entire settlement to that immediate delivery could leave the policy unable to complete its accounting. We separated the claimable entitlement from immediate delivery at the recipient boundary. Settlement recognises the entitlement and the beneficiary claims through the defined payment path.

The application distinguishes an established payout entitlement from funds already received. A claim references the recorded entitlement, while settlement and delivery retain separate states. Pull-based delivery contains a recipient-side failure without requiring every beneficiary contract to accept a transfer during the triggering transaction.

Governance needed to respond without rewriting coverage

Shared modules make it possible to maintain the protocol, but an upgradeable pointer can also change what an active policy means. Parametric Pulse pins a policy to its trigger, oracle and payout-formula versions. A governance update to a global module reference cannot silently replace the economics of coverage that is already active. This carries the same commitment principle used for policy terms into the implementation layer.

Sensitive changes pass through a timelock while emergency actions remain faster and narrower. The architecture treats unsafe upgrades and excessive pause authority as operational threats alongside contract and oracle attacks. Governance manages protocol safety configuration without becoming a routine discretionary participant in payouts. That division matters to both buyers and underwriters. Their agreed exposure remains tied to the policy's pinned versions throughout the risk period.

The same caution shapes deployment across networks. We kept solvency accounting local to each chain. Each chain retains its own policy state, capital, settlement assets and oracle finalisation. A local payout does not assume that another chain can deliver liquidity immediately. This sacrifices some flexibility in capital placement but avoids making bridge availability part of every coverage promise. Wider deployment can reuse the architecture without treating remote funds as already available locally.

The settlement record connects evidence, terms and capital

The security model concentrates on the transition from external evidence to capital movement. Oracle manipulation, replayed reports and future-dated timestamps threaten the input side. Reentrancy, rounding errors and unusual token behaviour threaten settlement. Correlated exposures and vault share manipulation affect the capital model. The security boundaries follow these separate input, settlement and capital risks.

We connected active coverage to an explicit capital reservation and the committed payout formula. Each capital layer has an allocation limit, and settlement records distinguish a recognised entitlement from its eventual transfer. Conflicting or missing evidence remains unresolved instead of silently becoming either a trigger or an expired policy.

Parametric Pulse connects those requirements into one auditable lifecycle. A protection buyer can identify the condition that activates payment and the beneficiary entitled to receive it. An underwriter can identify the capital committed to that exposure and its place in the loss waterfall. An operator can distinguish missing observations from a failed confirmation or a pending payout. The settlement record connects the final decision back to the policy terms, evidence and capital sources that made it valid.