Amendment Idea: Life Insurance Protocol #377
dangell7
started this conversation in
Ideas (pre standard proposal)
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Life Insurance Protocol
Index
1. Abstract
This amendment introduces a comprehensive insurance framework for the XRP Ledger, extending the existing Vault and Lending Protocol infrastructure. The system provides:
2. Motivation
Current DeFi protocols lack native insurance mechanisms, limiting risk management options for users and protocols. Existing solutions require:
This amendment addresses these gaps by providing:
3. Introduction
The Insurance Protocol extends the Vault infrastructure to support life insurance products with cash value accumulation. Policies accumulate value through premium payments, which can serve as collateral for loans without requiring policy surrender. The protocol guarantees that benefits can always be paid in full through capital locking mechanisms.
3.1. Terminology
Core Components:
Premium Distribution:
Fees:
Capital Protection:
Integration Points:
3.2. Summary
Ledger Objects:
InsuranceBroker
: Manages policies and interfaces with VaultInsurancePolicy
: Individual policy with cash value pseudo-accountTransactions:
InsuranceBrokerSet
: Creates or modifies broker configurationPolicyCreate
: Issues new insurance policy with custom or default ratesPolicyPremium
: Processes premium payment with sequence validationPolicyManage
: Handles surrender/lapse/reinstatement with flagsPolicyClaim
: Processes partial or full benefit claimPolicyRefund
: Handles overpayments4. Specification
4.1. Ledger Entries
4.1.1. InsuranceBroker
4.1.1.1. Object Identifier
Key Space:
0x0049
(capital 'I')The InsuranceBroker object ID is calculated as:
Where:
KeySpace
=0x0049
AccountID
= The broker accountTransactionSequence
= Creation transaction sequence4.1.1.2. Fields
4.1.1.3. Ownership
The InsuranceBroker is owned by the
Owner
account and linked in both the owner's and vault's directories.4.1.1.4. Reserves
Creating an InsuranceBroker increments the owner's reserve by one unit.
4.1.1.5. Broker Flags
lsfBrokerActive
0x00010000
lsfBrokerSuspended
0x00020000
lsfBrokerClosed
0x00040000
4.1.2. InsurancePolicy
4.1.2.1. Object Identifier
Key Space:
0x0050
(capital 'P')The InsurancePolicy object ID is calculated as:
4.1.2.2. Fields
4.1.2.3. Policy Flags
lsfPolicyActive
0x00010000
lsfPolicyLapsed
0x00020000
lsfPolicySurrendered
0x00040000
lsfPolicyExhausted
0x00080000
lsfPolicyCollateralized
0x00100000
4.2. Transactions
4.2.1. InsuranceBrokerSet
Creates or modifies an insurance broker configuration.
4.2.1.1. Fields
Conditional Requirements:
VaultID
, default rates, andMaxCoverageAmount
requiredInsuranceBrokerID
required4.2.1.2. Failure Conditions
For Creation:
temDISABLED
: Amendment not enabledtemINVALID_FLAG
: Invalid transaction flagstemMALFORMED
: Missing required fieldstemMALFORMED
: Default rates don't sum to 10000temMALFORMED
: Invalid amount fieldstecNO_TARGET
: Vault doesn't existtecDUPLICATE
: Broker already exists for accounttecINSUFFICIENT_RESERVE
: Insufficient XRP for reservetecDIR_FULL
: Owner directory fulltecNO_PERMISSION
: Not authorized by VaulttecTEMP_ERROR
: Vault.AssetsAvailable insufficientFor Modification:
temDISABLED
: Amendment not enabledtemINVALID_FLAG
: Invalid transaction flagstemMALFORMED
: Invalid field valuestemMALFORMED
: New default rates don't sum to 10000tecNO_TARGET
: Broker doesn't existtecNO_PERMISSION
: Not the broker owner4.2.1.3. State Changes
On Creation:
On Modification:
4.2.2. PolicyCreate
Creates a new insurance policy with initial premium payment and optionally custom rates.
4.2.2.1. Fields
4.2.2.2. Failure Conditions
temDISABLED
: Amendment not enabledtemINVALID_FLAG
: Invalid transaction flagstemMALFORMED
: Missing required fieldstemMALFORMED
: Invalid amount fieldstemMALFORMED
: PremiumInterval < 86400 (1 day)temMALFORMED
: Custom rates don't sum to 10000temINVALID_ACCOUNT_ID
: Beneficiary same as PolicyHoldertecNO_TARGET
: Broker doesn't existtecNO_TARGET
: Beneficiary doesn't existtecNO_TARGET
: Beneficiary is blackholed accounttecTEMP_ERROR
: Broker suspended or closedtecTEMP_ERROR
: Benefit > MaxCoverageAmounttecTEMP_ERROR
: Vault.AssetsAvailable < Vault.LockedCapital + NARtecINSUFFICIENT_RESERVE
: Insufficient reservetecDIR_FULL
: Directory fulltecUNFUNDED_PAYMENT
: Insufficient XRP for premium and initiation fee4.2.2.3. State Changes
4.2.3. PolicyPremium
Processes premium payment with sequence validation and automatic distribution.
4.2.3.1. Fields
4.2.3.2. Failure Conditions
temDISABLED
: Amendment not enabledtemINVALID_FLAG
: Invalid transaction flagstemMALFORMED
: Invalid PolicyIDtemMALFORMED
: Amount > (PremiumAmount * 3)tecNO_TARGET
: Policy doesn't existtecNO_PERMISSION
: Not the policy holdertecTEMP_ERROR
: Policy not active (lapsed, surrendered, or exhausted)tefPAST_SEQ
: PremiumSequence mismatchtefMAX_LEDGER
: Too early (< 50% of interval since last payment)tecUNFUNDED_PAYMENT
: Insufficient XRP4.2.3.3. State Changes
4.2.4. PolicyManage
Handles policy surrender, lapse, and reinstatement through flags.
4.2.4.1. Fields
4.2.4.2. Flags
PolicyManage transaction flags are mutually exclusive:
tfPolicySurrender
0x00010000
tfPolicyLapse
0x00020000
tfPolicyReinstate
0x00040000
4.2.4.3. Failure Conditions
Common:
temDISABLED
: Amendment not enabledtemINVALID_FLAG
: Invalid or multiple flags settecNO_TARGET
: Policy doesn't existFor tfPolicySurrender: 4.
tecNO_PERMISSION
: Not the policy holder 5.tecTEMP_ERROR
: Policy already surrendered/exhausted 6.tecTEMP_ERROR
: Policy has lsfPolicyCollateralized flag 7.tecUNFUNDED_PAYMENT
: Policy account insufficient fundsFor tfPolicyLapse: 4.
tecTEMP_ERROR
: Policy not active 5.tefTOO_EARLY
: Still within grace period 6.tecTEMP_ERROR
: Policy already lapsed/surrendered/exhaustedFor tfPolicyReinstate: 4.
tecNO_PERMISSION
: Not the policy holder 5.tecTEMP_ERROR
: Policy not lapsed 6.tefMAX_LEDGER
: More than 30 days since lapse 7.tecUNFUNDED_PAYMENT
: Insufficient funds for back premiums and reinstatement fee4.2.4.4. State Changes
For tfPolicySurrender:
For tfPolicyLapse:
For tfPolicyReinstate:
4.2.5. PolicyClaim
Processes partial or full benefit claim.
4.2.5.1. Fields
4.2.5.2. Failure Conditions
temDISABLED
: Amendment not enabledtemINVALID_FLAG
: Invalid transaction flagstemMALFORMED
: Invalid proof hashtemMALFORMED
: Amount > RemainingBenefittecNO_TARGET
: Policy doesn't existtecNO_PERMISSION
: Not beneficiary or authorized executortecNO_AUTH
: Beneficiary not verified (needs DepositPreauth)tecTEMP_ERROR
: Policy already exhausted or surrenderedtecTEMP_ERROR
: Policy has lsfPolicyCollateralized flagtecTEMP_ERROR
: RemainingBenefit = 0tecUNFUNDED_PAYMENT
: Vault has insufficient funds (should never happen with proper locking)tecUNFUNDED_PAYMENT
: Policy account has insufficient cash value4.2.5.3. State Changes
4.2.6. PolicyRefund
Handles overpayments and corrections.
4.2.6.1. Fields
4.2.6.2. Failure Conditions
tecNO_TARGET
: Policy doesn't existtecNO_PERMISSION
: Not policy holder or brokertecTEMP_ERROR
: Amount > CashValuetecUNFUNDED_PAYMENT
: Insufficient funds in policy account4.2.6.3. State Changes
4.3. Premium Distribution
Premium payments use the rates stored in each individual policy:
4.4. Risk Management
4.4.1. Solvency Tracking
Real-time solvency is maintained through Vault-level tracking:
4.4.2. Surrender Penalty and Fee Structure
Surrender Penalties go entirely to the Vault as compensation for early termination:
Fee Structure compensates the Broker for administrative work:
This separation ensures:
4.4.3. Lapse and Reinstatement
Policies lapse when grace period expires:
Lapsed policies:
4.4.4. Loan Collateral Management
When a policy is used as loan collateral:
lsfPolicyCollateralized
during LoanSet transactionlsfPolicyCollateralized
during loan settlement (LoanDelete or LoanManage)The insurance protocol does not provide a separate transaction for uncollateralizing policies. This is handled entirely by the Loan system to maintain clear ownership of state changes.
4.5. Solvency Protection
4.5.1. Capital Locking
Vault capital is locked throughout policy lifecycle:
4.5.2. Invariants
System maintains these invariants:
Vault.AssetsAvailable >= Vault.LockedCapital
Each Policy.NetAmountAtRisk == max(0, RemainingBenefit - CashValue)
Policy rates always sum to 10000 (100%)
Broker.DebtTotal == Σ(Policy.NetAmountAtRisk) for its policies
Policy.TotalClaimed <= Policy.TotalBenefit
Policy.RemainingBenefit = Policy.TotalBenefit - Policy.TotalClaimed
5. Rationale
5.1. Fee and Penalty Structure Rationale
The protocol separates risk compensation from service fees:
Surrender Penalties (100% to Vault):
Service Fees (to Broker):
This clear separation:
6. Backwards Compatibility
This amendment introduces no backwards incompatibilities:
7. Security Considerations
7.1. Guaranteed Solvency
The protocol guarantees full benefit payment through:
7.2. Attack Prevention
Premium Front-Running: Prevented by sequence numbers and timing validation
Rate Manipulation: Each policy stores immutable rates
Fee Manipulation: Fees are set at broker creation/modification
Collateral Double-Spend: Prevented by collateralization flags managed by loan system
Beneficiary Invalidity: Validated at creation
Vault Insolvency: Prevented by capital locking that guarantees availability
Claim Over-Drawing: Amount capped at RemainingBenefit
Surrender Gaming: Full penalty to Vault removes broker incentive to force surrenders
7.3. State Consistency
All state transitions are atomic and validated:
8. Appendix
8.1. FAQ
Q: Why does the surrender penalty go entirely to the Vault?
A: The Vault bears all the insurance risk. When a policy terminates early, the Vault loses expected future risk premiums and must compensate for the capital that was locked. Brokers already receive management fees for their services.
Q: What fees does the broker receive?
A: Brokers receive: (1) Management fees from each premium payment, (2) Initiation fees when policies are created, and (3) Reinstatement fees when lapsed policies are reinstated. This compensates them fairly for administrative work without creating conflicts of interest.
Q: Can the fee structure be changed after broker creation?
A: Yes, the broker owner can modify fees for future policies through InsuranceBrokerSet. Existing policies maintain their original terms.
Q: Can multiple claims be made on a single policy?
A: Yes, policies support multiple partial claims until the RemainingBenefit reaches zero. Each claim is tracked with TotalClaimed and ClaimCount.
Q: What happens when a policy is fully claimed?
A: The policy is marked as exhausted. If there's remaining cash value, the policy stays for potential surrender. If both benefit and cash value are zero, the policy is deleted.
Q: Who manages the collateral flag?
A: The LoanBroker sets and clears the
lsfPolicyCollateralized
flag. This maintains clear ownership and prevents inconsistency between systems.Q: Can policies have different premium rates?
A: Yes, each policy stores its own rates, either custom-specified at creation or copied from broker defaults.
Q: What happens to lapsed policies?
A: They remain in the ledger with cash value intact. They can be surrendered for cash value (minus penalties distributed per the broker's configuration) or reinstated within 30 days.
Q: Can the Vault withdraw capital while policies are active?
A: Only the amount exceeding LockedCapital. Active policies always have guaranteed coverage through the locking mechanism.
Q: How are different risk profiles handled?
A: Through policy-specific premium rates set at creation, allowing actuarial pricing per policyholder.
8.2. Example Lifecycle
8.3. Reference Implementation
The reference implementation will be provided as a pull request to the rippled repository upon advancement to Final status.
Beta Was this translation helpful? Give feedback.
All reactions