Economics Design Under Blockchain Insurance
Leon Leng
pic from sherlock.xyz
Traditional Insurance
Necessity: hedging against risks -- project abscond, protocol loophole, regulatory risk and so on
Essence: Financial agreement between both parties, policyholder and insurance company
How traditional insurance operates
1. Law of Large Numbers: Although it is difficult to capture and calculate the probability of insurance losses, as long as the number of units is large enough, random events will be repeated in large quantities, eventually revealing inevitable patterns.
2. Risk Sharing: Insurance loss events occur infrequently but have significant impacts. Therefore, it is necessary to have a sufficient number of participants to spread the risk of potential losses from an individual entity to an aggregate of entities on an average basis.
How traditional insurance earns
1. Interest Differential: the gap between “actual investment revenue” and “expected investment revenue” of the insurance firm.
2. Insurance margin: the gap between “actual claim payout amount” and “expected claim payout amount” when insurance policy expiry
3. Cost differential: the gap between “actual cost when operating one type of insurance which is published” and “the expected cost”
Type of Insurance Company
1. Joint-stock insurance company: Profit-oriented organizations, funded by shareholders, and the ultimate decision-making authority lies with the shareholders' general meeting. Stock-based insurance companies adopt a fixed premium system, where any surplus in premiums is considered as profit. In case of any shortfall, the shareholders are responsible for making up the difference. Policyholders are not obligated to bear the burden of making additional premium payments.
2. Mutual insurance organization: Non-profit Organization formed by insured individuals with a common need for protection against the same type of risk, without shareholders or share capital. Insured individuals have a dual role, serving as owners providing operational funds and having the right to select the board of directors, while also being customers. Mutual insurance organizations adopt a variable premium system, where policyholders can receive dividends when there is a surplus, which can be accumulated to strengthen the organization's financial position. In the event of a loss, policyholders may contribute additional premiums or use previous surplus funds to make up for the shortfall. In China, 阳光农业相互保险公司; 众惠相互、信美相互和汇友相互.
3. Internet mutual assistance: Organized by online mutual aid platforms, utilizing the information matching function of the Internet, enables members to share and bear each other's risk losses.The main area of mutual aid is major medical expenses, where each participating member contributes a small amount of mutual aid fund for each period and receives a larger amount of medical funds formed by the contributions of other members when they themselves fall ill in the future. Online mutual aid has low participation barriers, limited coverage, and non-compulsory payouts.
4. Some derivatives also possess risk hedging features which exist in mainstream financial markets : the key idea for the derivatives in financial market is “pricing and revenue management used to transfer and share risks.” rather than “large number theory”. For example, the credit default swap" (CDS): In a CDS (credit default swap) transaction, there are two parties involved: the protection buyer and the protection seller. The protection buyer pays regular fixed payments, known as the CDS spread, to the protection seller. In return, if a credit event occurs before the CDS maturity, such as bankruptcy, default, or debt restructuring of the reference entity, the protection seller has an obligation to compensate the protection buyer for their losses.
Key points of Traditional Insurance
Insurance subject
Personal and health risks, as well as property risks. The credit risk targeted by CDS can be considered a form of property risk. In mainstream insurance products, the policyholder has a corresponding risk exposure to the insured object. However, in the case of CDS, the protection buyer can purchase related CDS without holding the underlying institution's debt. This is referred to as a "naked position" in CDS, which sparked significant controversy during the international financial crisis.
Organization format: centralized, decentralized, point to point[保险的组织形式]
1. Centralized form: Joint-stock insurance company
2. “Decentralized form”: “Mutual insurance organization” and “Internet mutual assistance”.
3. Point to point: Derivative products represented by CDS
The nature of an insurance contract
Actuarial
Insurance actuarial determines insurance premiums by analyzing the probability of future risk events and their potential financial impacts.
With the application of biotechnology and wearable devices in life insurance, as well as the use of sensing devices in property insurance (such as in-car sensors and usage-based insurance), insurance actuarial based on big data and artificial intelligence algorithms will be able to better reflect individual differences of policyholders and enable dynamic adjustments.
Insurance claims assessment and settlement
It can be seen that stock insurance companies operate in a fully centralized manner in terms of insurance claims settlement and payouts, while mutual insurance organizations and online mutual aid platforms exhibit a decentralized and community-driven approach.
The Realization of DeFi Insurance
Liquidity Pool: Each user can take on the role of an institution, injecting liquidity into insurance projects to form a funding pool. The individuals providing liquidity are attracted by the security of the insurance and thereby earn investment returns.
Insurances Buyer: To purchase insurance for various types of assets, such as centralized institutions being hacked or DeFi protocols being hacked, one selects an appropriate provider and buys insurance based on the type of insurance and the duration. The greater the risk, the higher the cost to be paid..
DeFi Platform Protocol: As a platform, it sets up various insurance pools and opens up insurance purchasing and underwriting functions to the public. Various insurance pairs are formed for users to freely purchase insurance and provide liquidity.
When a claim event occurs, as a neutral third party, the platform utilizes smart contracts for claims settlement and other functions, generating revenue through collecting certain fees.
Underwriter: Anyone can become an underwriter for the insurance pool. Similar to staking as an LP, users can choose to inject funds into different types of insurance on various DeFi insurance platforms, assuming the risk of claims (higher safety factor yields lower returns, while lower safety factor yields higher returns), and earning a portion of the insurance premium as income.
Claim Assessor: When a policyholder submits a claim, traditional insurance relies on the insurance company to assess the damage and determine whether to process the claim. In contrast, DeFi insurance platforms verify claims through two methods:
1.Token holder voting: According to the governance mechanism of the insurance protocol, there are designated claims assessors (who need to hold tokens). These assessors vote on the claim proposals, and if approved, the claim is processed.
2. Automated verification: Claims are automatically verified through the use of oracles.
Smart Contract
Difficulties of DEFI Insurance
1. Insurance coverage is limited in scope
Apart from offline insurance like flight delay insurance offered by platforms like Etherisc, the existing DeFi insurance mainly focuses on providing coverage for smart contract vulnerabilities in on-chain protocols (e.g., Nexus Mutual) and insurance against price fluctuations of crypto assets. The coverage is limited in terms of scenarios and scope. For the majority of users, the most concerning risks are wallet hacks and uncompensated losses due to unexpected incidents. However, there is currently no dedicated platform offering DeFi insurance for these high-risk events.
2. Insurance protocols are distributed across different blockchains
Currently, DeFi insurance protocols are scattered across different public blockchains. Nexus Mutual is built on ETH, while Helmet on Binance Smart Chain. Typically, DeFi users interact with one or two familiar blockchains, and the decentralization of insurance protocols across multiple chains makes it difficult for users with insurance needs to compare different insurance products and find the most suitable one.
3. Actuarial challenges
Currently, for DeFi insurance, The insured risks (cryptocurrencies) lack a fixed and independent distribution, making it difficult to quantify the associated risks. Insurance, fundamentally, involves claims in uncertain states, thus the pricing model for risk premium is similar to that of financial derivatives. For web2 insurance, they typically use Monte Carlo methods to simulate and estimate the fair premium of insured assets. With the increasing availability of price records, continuous-time pricing models such as the Black-Scholes formula can also be applied. According to NodeDAO, currently for web3 insurance, the most popular method is still use Monte Carlo methods.
4. Verification challenge
A unique challenge in DeFi insurance is the verification of losses. In the real world, losses can be verified by centralized insurance companies and centralized governments with certain information costs. But in the crypto world, the anonymity feature of digital wallets makes it difficult, and sometimes even impossible, to verify claims effectively. For example, if an insured person claims that their NFT has been stolen, it is nearly impossible to differentiate between genuine theft and insurance fraud, as the insured person can simply create another digital wallet and transfer the crypto assets without being identified.
5. Liquidity and return rate challenge
The primary challenge faced by DeFi insurance or the entire DeFi industry is liquidity. In the early stages of DeFi development (DeFi 1.0), liquidity was primarily provided by liquidity miners who constantly switched between different projects to maximize their returns. As a result, a DeFi project cannot sustain its liquidity unless it offers higher yields to compete for liquidity. A revolutionary solution is needed to address the liquidity challenge, and one emerging possibility is DeFi 2.0, which involves establishing a treasury or "war chest" outside of liquidity pools to support liquidity demands. Once a higher yield is offered in alternative projects, users seeking higher returns are motivated to withdraw funds from existing projects, resulting in rapid depletion of the old liquidity pool. This solution was initially developed by other DeFi projects such as Olympus (a reserve currency project) and adopted by DeFi insurance projects like NodeDAO. Through various incentive designs, the treasury in DeFi 2.0 can stabilize the liquidity of DeFi insurance projects. Some DeFi insurance protocols also offer a third option, which is to become a "bond holder" and purchase bonds with a fixed APY from the reserve or "treasury".
6. Scale Challenge
The reason for DeFi market is small can be divided into two parts:
Current DEFI Insurance Situation
Token Value Locked: 1.29% of the whole DeFi Industry -- info from 2022 Mar.
The insurance industry exhibits a lag effect in the financial sector
Many Difficulties
Difficulties
Copyright @ Internet
High Threshold
Liquidity Challenge Actuarial Challenge Verification Challenge
Return Rate Challenge Malicious Attack Legislative Challenge
Problems
High User Education Costs
High Development Threshold
High Design Threshold
TVL Ranking for DeFi Insurance Protocols – End by 2023/06/21
Name
Product Comparison Analysis
Feature
Company Nature
KYC
Product Categories
Reward
Claim Assessment
Nexus Mutual
InsurAce
Unslashed
Guard-Helmet
Ease.org
Sherlock
Tidal Finance
Yes
Mutual Company
Common Capital Pool
Tokenomics
Highlight
Mutual Company
No
Common Capital Pool
1. Protocol Cover; 2. Custody Cover;
3. Yield Token Cover; 4. ETH Staking Cover; 5. Excess Cover
1. Protocol Cover; 2. Custodian Cover; 3. Yield token Cover
4. Post-Audit Cover
5. Bridge Cover
1. No upper limit for the total amount.
2. Two types of tokens: $NXM is the main one, which can not be traded on second markets. $NXM price depends on the price formula. 3. Governance Token related to the voting weight. 4. The amount of $NXM related to how many ETH/DAI go into the system.
1. Have upper limit.
2. One type of token
3. Can be bought from second market.
1. Only member who stake $NXM can be the claim assessors who is able to vote 🡪 If the number of people are not enough, then the size can extend to all the members. However, if one is not member, then she can not vote.
2. The advisory board has the supreme right to decide if voting is controversial and can punish voting cheating.
1. The advisory board investigate at first and give an announcement and a report.
2. I f it’s a risk event, the claim assessors (who stake $INSUR tokens) can vote (no need kyc).
3. If the vote process do not fulfill the requirement, then up to advisory board finally.
1. Product Format: Portfolio-based (Insur Ace provide a set of insurance products rather than only one to the customer in order to decrease the total price and risk)
2. Investment Arm and Cover Arm: The Investment Part and Cover Part can interact with each other.
3. The insurance pricing: Insur Ace use two models (risk model and frequency model to estimate the real loss)
4. The token price: decided by the market
1. Staking(mining) can get reward, (staking for claim assessors, staking for underwriter and so on)
2. Governance Participating
3. Investment
1. Insurance Pricing: Auction, dynamic pricing 🡪 from a high price to low price, and related to the capacity
2. Token Price: Not affect by the market, the token price bonded by the formula
3. Whitelist: only members who approve for the KYC can be on the list and only the list members can trade $NXM with each other
4. Voting: The claim assessors decide the claim approved or not.
1. Stake as an underwriter
2. Stake as a claim assessor
3. Governance Participating
Name
Product Comparison Analysis
Feature
Company Nature
KYC
Product Categories
Tokenomics
Capital Pool
&
Liquidity
Highlight
Reward
Cozy Finance
Insure DAO
RiskHarbor
Bridge Mutual
Uno Re
Bright Union
Amulet Protocol
Claim Assessment
Categories of DEFI Insurance I
Common Capital Pool Nexus Mutual
DeFi Insurance
(by function)
Prediction Market Augur
Financial Derivatives Convexity
Decentralized Insurance Protocol Etherisc
Social Proof for gathering guarantees VouchForMe
CDx: In CDx program, the CDS called “Swap”
Convexity: using the concept of the “Put Option”, the option buyer has the choice to purchase Tokens to obtain insurance against a sharp decline in ETH. The option seller, on the other hand, collateralizes their ETH and sells options to earn a certain premium.
4. Decentralized Insurance Protocol: Platform based product, for example, in Etherisc, the core team of Etherisc has developed a decentralized insurance application platform that allows developers to quickly create new insurance products. They have built generic insurance infrastructure, product templates, and Insurance-as-a-Service (IaaS) to enable anyone to create their own insurance products. Currently, the Etherisc community has designed a set of basic insurance products, covering areas such as flight delay insurance, hurricane insurance, as well as insurance for cryptocurrency wallets and loan collateral.
5. Social Proof for gathering guarantees : For example, VochForme, which aims to collect endorsements from trusted individuals within social networks and social relationships to lower the cost of insurance. By having endorsers vouch for you, the insurance company is convinced that you meet the requirements, resulting in reduced premiums. A financial commitment, linked to insurance claims, is required when providing endorsements. The more endorsers you have, the lower the premium. In the event of a claim, endorsers bear a proportionate share of the liability.
Categories of DEFI Insurance II
DeFi Insurance
(by parameter)
Parameter Insurance
Non Parameter Insurance
Parameter Insurance
1. Crop Insurance: For example, the blockchain-based parametric insurance platform Arbol has introduced weather insurance worldwide utilizing smart contract technology. Farmers can purchase weather insurance to hedge against drought risks, where their crops require a minimum rainfall of 20 inches to be marketable. In the event that the rainfall falls below 20 inches, automatic compensation is provided. The insurance parameters and protocols are tamper-proof and executed automatically.
2. Flight Insurance: For example, Etherisc is a blockchain insurance project that offers various insurance products such as flight insurance, hurricane insurance, and weather insurance.
Logistics of Creating Parameter Insurance(take flight insurance as an example):
(1) Collect policy parameters and transfer customer risk-related data to the insurance smart contract on the blockchain. This step can be easily accomplished by integrating an oracle into the frontend infrastructure.
(2) Policy pricing also needs to transfer to the chain for customer verification. Whether the pricing is calculated on-chain or off-chain, the oracle needs to submit the result to the smart contract in a tamper-proof manner, validating that the price is based on the on-chain parameters established in the previous process.
(3) Automate the claims process and make payments to the customers. To trigger automatic payment, real-time data needs to be obtained from the real-world and transferred to the on-chain smart contract. The smart contract initiates a new data request to the oracle to obtain the expected arrival time of the flight. If there is a flight delay, the smart contract automatically initiates the payment process
Non-Parameter Insurance, for example, “Borrower Insurance”: Assisting borrowers in hedging default risks and systemic risks associated with on-chain loans.
Current DEFI Insurance Product Drawback
Deficient Product Accessibility
Inadequate Risk Management
Capital Inefficiency
Future of DEFI Insurance
Insurance subject: on-chain risk or off-chain risk
When the insurance subject is off-chain risk, we need to think more on
1. Currency Mismatch and System Incompatibility Issues: Off-chain risks are priced in fiat currency, while insurance claims are settled in on-chain digital assets.
2. Insurance actuarial calculations and claims assessment for off-chain risks can only be performed off-chain, requiring the use of an oracle to record the relevant results on-chain.
The field of DeFi oracles is still emerging, with considerable room for improvement in terms of accuracy and efficiency. In the absence of well-developed DeFi oracles, one may consider utilizing more centralized oracles that possess a higher degree of centralization.
When the insurance subject is on-chain risk, we need to think more on
Expand the scope of risk coverage: Currently, insurance primarily focuses on the risks arising from smart contract vulnerabilities and hacker attacks in DeFi. In the future, DeFi insurance should expand its coverage to include risks related to flaws in the DeFi economic model design, inaccuracies and delays in oracle price feeds, delayed processing of on-chain transactions, high gas fees, losses due to collateral liquidation, unexpected progress in Ethereum 2.0 transition, and even security risks associated with the underlying blockchain.
DeFi insurance actuarial and claims settlement methods
In the field of DeFi insurance, there are currently four main methods for actuarial analysis and claims settlement:
(1) Conducting initial off-chain processing through centralized means and subsequently writing the results into the blockchain using an oracle. This approach is more suitable for DeFi insurance covering off-chain risks.
(2) By on-chain algorithms, this method is suitable for DeFi insurance targeting on-chain risks and situations where the probability of risk occurrence and economic impact can be easily quantified and evaluated.
(3) On-chain voting: Assessing risks through on-chain voting reflects the spirit of community governance, but it requires ensuring high participation and credibility of the voting results. Pre-voting staking is commonly required to mitigate the "Nothing at Stake" issue. However, even with these measures in place, allowing non-professional individuals to decide on technical matters through voting still presents significant challenges.
(4) By market trading: Gathering information about the probability of risk occurrence and the extent of losses through market mechanisms. Markets are inherently decentralized, but it is necessary to ensure sufficient market liquidity and a well-functioning price discovery mechanism.
These four methods can be used together or by combination.
Nexus Mutual
Case1: Nexus Mutual
Basic Information
1. Set up from 2017, the best-performing DeFi insurance protocol in the current cryptocurrency market, accounting for over 67% of the entire on-chain insurance industry.
2. A Community Interest Company, where users are required to pay 0.002 ETH and complete KYC to become members before they can purchase its policies.
Agent Type
Only members can take a role in Nexus Mutual and once one become a member than she is also a member of Nexus Mutual DAO
The business process of Nexus Mutual involves three primary user roles: Risk Assessors, Insurance Buyers, and Claims Assessors
Risk Assessors (as known as the Liquidity provider or Underwriter): After conducting an assessment to determine the security of a particular contract, funds are pledged in the form of NXM. When others purchase insurance for this contract, corresponding premium income can be obtained. In the event of a claim, the pledged NXM is used to pay the corresponding insurance amount.
Insurance Buyers: need to select the contract, currency, amount, and duration for their coverage and pay the premium using NXM. If a risk event occurs, users need to submit a claim application, which will be reviewed by claims assessors. Compensation can only be obtained upon approval of the claim.
Claim Assessors: To participate in the assessment of a claim by staking NXM, a "consensus" judgment with a majority agreement of over 70% is required. [If can not reach to 70% consensus or the total number of voting is smaller than the required minimal number, then it proceeds to a vote by all members in the Nexus Mutual DAO, including non-claim assessors, for the final decision]
1. If the assessors' evaluation aligns with the consensus judgment of the community, they receive certain incentives.
2. Conversely, if their evaluation differs, they face penalties in the form of a longer lockup period for their staked NXM.
Token Flow(when buying one insurance)
Insurance Buyer
90% of NXM Token the user paid will be burnt, which means will disappear from the insurance buyer side. But the corresponding same value amount NXM (AKA Insurance Premium) will be minted as a reward for other roles people in the nexus mutual. Naively, you could think it’s like the money transferring (burnt and mint at the same time)
Buy Insurance
Member use DAI or ETH to buy insurance, the system will change the amount of DAI/ETH to the NXM unit according to the price ratio. Further, the amount of NXM will be separated in two parts as shows below:
10% of NXM Token the user paid are kept in user wallet and will be used as the deposit when she submit the claim. If finally the one don’t submit any claim, then this part of Token will be back to users
Insurance Premium
(AKA the remaining 90% NXM)
40% of NXM: reward to the claim assessors, if there is one claim, then reward for one round for 40% of NXM, if there are two claims then reward for 2 round, each one is 20% reward. Not everyone who participate as a claim assessor can earn the reward unless one’s voting decision aligns with the majority which win the consensus.
50% of NXM: reward to the risk assessors, i.e. who stake for the NXM and be the underwriter. If a claim event occurs, the tokens pledged as collateral will be burned proportionally, and if the amount exceeds the pledged quantity, the entire amount will be burned.
User Flow(when buying one insurance)
1. On the insurance purchase page, users can select the desired smart contract they want to insure or enter the smart contract address.
2. Enter the insurance amount and insurance period, which can be denominated in DAI or Ether
3. Get the corresponding quote, the upper bound of the “quote” is restricted with the token model
4. can be paid with DAI, Ether, or NXM. If you choose to pay with DAI or Ether, the system will automatically convert them to NXM tokens for payment.
Cover Products
Currently, the mutual offers a variety of cover products for crypto-native risks. The protocol does support product development for new types of cover, such as cover for real world risk and other types of crypto-native risk.
Current five crypto-native cover products
1. Protocol Cover 2. ETH Staking Cover 3. Custody Cover 4. Yield Token Cover 5. Excess Cover
1. Protocol Cover (For crypto assets deposited in a single protocol deployed on EVM-compatible networks)
# Covered risks
# Proof of Loss
When holding Protocol Cover and suffer a loss of funds, you can file a claim and claims assessors will review the claim submission to determine whether the claim is valid:
# For Protocol Cover claims, on-chain proof of loss is required, you need prove you own and control the address
# When proving is done, claims assessors can review the on-chain history associated with the address to determine:
(1) If funds were deposited when the loss event occurred
(2) If the cover was active when the loss event occurred
(3) If you suffered a loss of funds and, if so, the amount of funds that were lost
# Claim Process
After an exploit occurs, you will need to wait 72 hours for the cool-down period to pass.
(1) If you hold Protocol Cover at the time the exploit occurs, you can submit a claim with supporting evidence, otherwise referred to as proof of loss.
(2) Claims assessors will review, discuss, and vote to approve claims where proof of loss shows that you have indeed suffered a loss of funds
2. Custody Cover (For crypto assets deposited on a centralized crypto custodian)
# Covered risks
(1) Custodial wallet hacks where you lose more than 10% of your funds
(2) The custodian halting withdrawals for more than 90 days
# Proof of Loss
# For Protocol Cover claims, off-chain proof of loss and off-chain account verification is required 🡪 user need file a claim, provide screenshots of account statements etc.
# When proving is done, claims assessors can review the off-chain account system:
(1) if funds were deposited in the custodial account when the loss event occurred
(2) If the cover was active when the custodial loss event occurred
(3) If you suffered a loss of funds, and, if so, the amount of funds that were lost
3. Yield Token Cover (For crypto assets deposited into a vault strategy that is exposed to multiple protocols)
# Covered risks
When you have crypto assets deposited into a protocol that is integrated with other DeFi protocols on the Ethereum network, Yield Token Cover protects against:
the yield-bearing token depegging in value by more than 10% for any reason. So generally, this cover protect against the loss of a value, and the reason why the value loss can be caused by many reasons, such as exploits in the protocol, oracle failures and so on.
# Typical Examples
1. One that protects yield-bearing tokens that are backed by stablecoins pegged to USD
2. one that protects yield-bearing tokens that are backed by synthetic ETH tokens such as Lido's stETH or Synthetix' sETH
# Proof of Loss
With Yield Token Cover, the yield-bearing token itself represents your proof of loss.
When group claim events are approved, you will be able to swap your yield-bearing token for 90% of the cover amount if you held active Yield Token Cover when the depeg event occurred.
# Claim Process [Special]
When a yield-bearing token depegs by more than 10%, the Advisory Board creates a group claim event, which is subject to the regular Claims Assessment process.
Unlike other cover products, Yield Token Cover is assessed on a group basis, where all covered members for a particular covered token will be assessed together for a claim event:
Capital Pool
Cover Fees: All cover fees are paid into the capital pool in full. Cover can be purchased in either DAI or ETH terms, with the DAI or ETH flowing directly into the pool.
Claims: All claims are paid from the capital pool in either DAI or ETH terms, as per the covers purchased.
Investment Earnings: Members discuss, propose, and vote on capital pool investment allocations, which generate a return for the mutual.
Capital pool
The capital pool is jointly owned by all Nexus Mutual members.
Buy NXM: Members can contribute ETH directly to the mutual to generate new NXM. Members can contribute ETH at any time, and any ETH contributed flows into the capital pool.
Sell NXM: Members can redeem NXM for ETH directly from the mutual, but only when the minimum capital requirement ratio (MCR%) is above 100%. The "MCR lock" ensures the mutual has enough funds to pay valid claims.
The Whitelist structure: The NXM smart contract incorporates a whitelist structure where the whitelisted addresses represent the addresses of all members. Only addresses that have been validated through the whitelist are allowed to perform the Transfer operation. Only members can obtain NXM tokens, and NXM cannot be transferred to any Ethereum address that is not a member. That is why there is no native trading market for NXM on major exchanges, avoiding the impact of speculative trading in the secondary market and the risk of malicious manipulation of funds.
On-chain and Off-chain
On-chain:
# 1. Fundraising[筹资] 2. Governance[治理] 3. Risk Assessment[风险评估] 4. Claim Assessment[索赔评估]
# Emergency control[紧急控制权], KYC Whitelist Rules[白名单规则], Penalties for Malicious Insurance Fraud[恶意骗保惩罚] are made by Nexus‘s Advisory Board[顾问委员会]
Off-chain:
# Funding Model[资金模型], Token Price Model Calculation[Token 定价模型], due to the factors such as computational complexity, real-time requirements, and gas fees
# The Pricing Strategy, Investment Management, and Product Development are handled by the Nexus Mutual team
Tokenomics
NXM: governance and utility token
NXM
Staking
Underwriter
Claim Assessors
Members who stake NXM are the underwriters
There is no upper bound for the total NXM! Just as the left write, there are multiple ways to supply NXM and use or burn NXM. But the key idea of how NXM come to the system can be said in two sources:
# (1) Initial Distribution: 3 million is distributed at first.
# (2) When ETH/DAI come into the system, will generate NXM:
When someone contributes ETH or DAI to the capital pool in the Nexus Mutual user interface, NXM is minted and transferred to their wallet.
# For example, we assume 1 ETH = 10 NXM currently. Leon take 1 ETH to buy 1 insurance(the insurance price target on his situation is 1 ETH), then the 1 ETH will be sent to the capital pool, meanwhile, 10 NXM will be minted to Leon. Because Leon buy an insurance, which will cost 9 NXM. So 9 NXM will be burnt from Leon side and the remaining 1 NXM will be staked, when Leon need a claim, he will use it. If no claim, then this 1 NXM will go back to Leon account. What’s more, the 9 ETH burnt from Leon side will give to the claim assessors and risk assessors as a reward.
# If we do not consider the price change during this period, then
(1) Leon use 1 ETH to buy an insurance and will receive 0.1 value ETH (i.e. 1NXM) finally
(2) Capital Pool will receive 1 ETH
(3) Other agents will receive some NXM rewards
On-chain Govern
DAO Govern
Supply and Demand of NXM
Supply
(1) Initial token distribution: When the contract is deployed, 3 million NXM tokens are generated and allocated to the founders and early contributors.
(2) Purchase through token price model: Any member can purchase at any given time through the token price model.
(3) Reward for claim assessors: 20% of insurance premium
(4) Reward for risk assessors: 50% of the insurance premium
(5) Governance Reward: 100 NXM for participating
Demand
(1) Buy insurance: Token burning for insurance purposing: 90% of the tokens are allocated for burning, the remaining 10% tokens are locked and reserved for claims submission.
(2) Stake for being claim assessors
(3) Stake for being risk assessors
(4) Redeem: Users can swap NXM back to ETH by fulfilling certain conditions 🡪 1. MCR% >1; 2. there’s a maximum redemption amount for each transaction, the upper bound is (MCR%-100%)*2000; 3. The liquidity pool must have sufficient ETH liquidity; 4. the redeem has a discounted price for 2.5% (detail in the next slides)
Total Amount
Token Model (Continuous token model)
The continuous token model Refer to as a bonding curve, which ensures achieving capital efficiency. Users can purchase and redeem NXM tokens on the official website, and the price is calculated based on the project's funding situation.
(2) Make sure has enough funds to confidently pay all claims
(1) Not sitting on excess capital that isn't required
Bonding Curve
Token Price
Drivers of Growth
Aim to
capital efficiency
Token Price
price varies based on two primary parameters controlled by the bonding curve
# TP = Token Price in Ether
# A and C: constant values, which were calibrated at launch, A = 0.01028, C = 5800000
# MCR: the value of the minimum capital requirement in ETH, which grows as the number of covers grows. Regularly, MCR is calibrated to a solvency level of 99.5%.
# MCR%: ratio of the capital pool to the MCR 🡪 In the Nexus Mutual system, it is maintained that the MCR% value remains greater than 1.
When the MCR% is equal to or less than 1, NXM cannot be redeemed for ETH and DAI.
The capital pool model is complex, so it undergoes off-chain processing and on-chain attestation every 4 hours to validate the results.
generally
Nexus Mutual design a continuous token model which can be draw in a bonding curve of price, the design of the model can find a balance to make sure there is money in the capital pool but not overloaded.
Drivers of Growth
The token price is controlled by the bonding curve, which reflects the two fundamental drivers of growth: funds in the capital pool and cover sales.
MCR higher means the capital requirement increases (covers amount increase)
MCR% higher means that the funding level of mutual goes up, i.e., more money in the capital pool
Redemption and purchase restrictions
Restrictions are in place to ensure the mutual always has sufficient funds to confidently pay members' claims.
1.MCR% related limits:
2. Transaction limits caps:
Redemptions and purchases are limited per transaction to 5% of the MCR.
3. Redemption price:
To discourage speculative buy/sell behavior, the redemption price will be set at 2.5% lower than the purchase price derived from the token model.
Along with the money amount in capital pool increases 🡪 price of NXM increasing slowly 🡪 (1) when NXM price reach out to some value, i.e. MCR% bigger than some value which represents the amount of the money is sufficient, price of NXM increasing fast which encouraging user to sell the NXM; (2) When a claim occurs and the capital pool decreases, resulting in a decrease in MCR%, the NXM price may also decline, encouraging more people to exchange NXM. 🡪 When the amount of coverage increases, both the capital pool and MCR will grow, but the capital pool will grow at a faster rate. This leads to an increase in the NXM price.
MCR
99.5% Rules
MCR Model
The capital model is structured in multiple modules, where each module represents a product and currency pair. In addition, there is a currency module (fx) to account for currency risk. The modules are then combined at a total level to get the MCR. In its simplest form, with one product and one currency there are three modules, M1, fx and CM. The base calculation currency is Ether as the pool will be Ether dominated to start with. The MCR of each individual module is calculated in its currency (ie ETH or DAI) and then converted to Ether in the combining module.
Total MCR
Convert each individual module MCR to the total MCR
Module one, product one
Module two, product two
Account for currency risk
Simplest Model
The total MCR will need to be calculated regularly, probably at least once per day, as it is needed as a reference item for funding triggers.
A minimum MCR value will be set when the pool launches and the MCR value can never drop below this
Product means the cover type
Pricing
Previously, off-chain pricing module was used for cover products. Now pricing has now moved on-chain, with a dynamic pricing model that determines the price of cover products.
Spot Price
The spotPrice decreases linearly from bumpedPrice to targetPrice, depending on the # Speed(PRICE_CHANGE_PER_DAY) and the # time since the last cover buy
Formula: spot Price = MAX(bumped Price – price Drop, target Price)
& Bumped price = spotPrice + capacity% of the pool to be used / 1% x 0.2
& Price Drop = “time Since Last Cover Buy” * “speed”
& speed = “PRICE_CHANGE_PER_DAY” / “1 day In Seconds”
(price change per day is the variable of “speed function”)
& target price = set by the staking pool manager and can be updated at any time
When a cover product is added to a staking pool, the price starts at the initial price and decreases over time toward the target price set by each staking pool. The initial price for each cover product is determined by the Advisory Board and the target price is set by members running staking pools, who are referred to as staking pool managers.
With this approach, the price - per pool per risk - starts high and decreases to the minimum a staking pool is willing to accept, like a Dutch auction. This allows for price discovery; should risk be mispriced, demand at a given price will signal the willingness of members to buy cover at that price floor.
bumped Price
Bumped Price gets updated after each cover buy and is used to calculate the spot price of the NEXT cover:
# Note: when a cover product is first added to a staking pool, the BumedPrice is equal to the Initial Price set by the Advisory Board.
E.g.: Spot Price = 2.5
capacity % of the pool to be used = 15%
bumped Price = 2.5 + 15% / 1% x 0.2 = 5.5 price per year
# Key points: bumped price is related to the pool capacity. When the pool space is used increase 1%, then the spot price increase 0.2%.
Price drop
Price Drop is determined by taking the “time Since Last Cover Buy” multiple “speed”
E.g.: speed = 0.5% per day
Time Since Last Cover Buy = 3 days
Price Drop = 3 * 0.5% = 1.5%
Calculation Example
E.g.: speed = 0.5% per day
Time Since Last Cover Buy = 3 days
Price Drop = 3 * 0.5% = 1.5%
Bumped Price = 6.5%
Target Price = 4%
Spot Price = MAX(6.5% - 1.5%, 3%) = 5.0%
Surge loading
When the capacity for a cover product falls between 90% to 100%, surge pricing, referred to as loading, is applied to a cover product’s price.
If the cover product has 90% to 100% of capacity reserved for existing covers, then loading is applied, where loading is a linear function related to capacity used post cover purchase. For loading of 2% per 1% of capacity used above 90% (when above 90%, increase 1% usage of capacity will increase 2% surge fee)
Price Formula (including surge fee)
If the cover product has 90% to 100% of capacity reserved for existing covers, then loading is applied, where loading is a linear function related to capacity used post cover purchase. For loading of 2% per 1% of capacity used above 90% (when above 90%, increase 1% usage of capacity will increase 2% surge fee)
# Key idea: premium = base Premium + surge Premium | Surge Premium = cover amount * surge Loading / 2
# Surge Loading calculation (assume loading = 0.02 for every 1% of capacity over 90% )
E.g.1: capacity starts at 88% and goes to 95% 🡪 surge loading factor at 95% = (95% - 90%) / 1% * 0.02 = 5 * 0.02 = 0.1
E.g.2: capacity starts at 91% and goes to 95% 🡪 surge loading factor at 91% = (91% - 90%) / 1% * 0.02 = 1 * 0.02 = 0.02;
# premium = base Premium + surge Premium 🡪 (1) base premium = cover amount * spot Price; (2) surge Premium = surge Premium 90% to 95% - surge Premium 90% to 91%; (3) surge Premium 90% to 95% = amount * surge loading factor at 95% / 2; (4) ) surge Premium 90% to 95% = amount * surge loading factor at 91% / 2 🡪 can be calculated
Benefits of Pricing Mechanism
# High utilization, high price to signal demand
When the perceived risk associated with a single cover product increase in a short period of time 🡪 more cover buying for this product 🡪 cover price will be higher.
When the above happens, the mutual captures more revenue as exposure to any single risk increases. If the utilization for one cover product rises above 90%, then surge pricing is applied to the cover product’s price. Rising prices and surge pricing can serve as a signal to staking pool managers that the risk needs to be re-evaluated to determine:
# Low utilization, Low price
Cover products in a staking pool with ample capacity but infrequent cover buys will decrease in price toward the target price set by the staking pool manager. If a smaller amount of staked NXM is allocated to a cover product, the target price can still be achieved, though when additional cover is purchased, the cost of cover will move up in price faster than a pool with a larger number of staked NXM allocated to the same risk.
Decentralized Risk Assessment Mechanism
Nexus Mutual let many “Smart Contract Security Auditor” (i.e., the traditional Risk Assessors) participate in the assessment of specific risks by staking tokens, they are also able to earn token rewards provided by the system: The risk assessor think one smart contract is safe 🡪 She will stake NXM on it to give an endorsement of it 🡪 If the smart contract is deemed unsafe and a security breach occurs, as a penalty, the tokens previously staked by the risk assessor will be burned. Actually, for an insurance, more staking, more safe, less premium.
Pricing Mechanism (white paper)
# Factors influencing pricing:
The pricing of Nexus Mutual's contract insurance is determined by a specialized calculation formula and is primarily influenced by the following factors: 1. The amount of NXM staked for the contract 2. The coverage amount 3. The duration of the insurance. 🡪 larger amount of NXM staked, less coverage amount, shorter insurance duration will lead cheap premium.
# Pricing and Security:
Due to the lack of hacker attack testing, the insurance cost for a new smart contract will initially be very high (or even unavailable), and it will only decrease after multiple rounds of testing. However, this process takes a considerable amount of time, which most users are not willing to tolerate. They expect to insure their smart contracts immediately. So what Nexus Mutual do:
Capacity
Staking Pool Manager allocate staked NXM to individual products to create open capacity, which is the amount of cover that can be sold over a given period of time for a given product.
[Open Capacity is a very important concept, it represents the amount of the cover can be sold. By gut feeling, more NXM stake, can lead to more open capacity because when claim happens, they need to make sure there’s enough money to pay out]
Capacity Formula
Individual staking pools can determine which cover products they will allocate staked NXM against to open up capacity. The correlation risk between all staking pools needs to be managed on a global level within the protocol.
Capacity Factors
total stake = active stake + expired stake
# active stake: all NXM in active staking periods
# expired stake: staked NXM in staking periods that have ended and can be withdrawn by NXM stakers
total capacity = active stake * global capacity factor
# total capacity: the amount of staked NXM in active staking periods
# global capacity factor: constant 2 for all products (can be changed by Advisory Board) 🡪 every one NXM staked opens up two NXM worth of capacity.
total product capacity = total capacity * capacity reduction factor * product weight
# capacity reduction factor: set to zero but can be adjusted up to maximum to one by the Advisory Board when any product’s active cover approaches 20% of the MCR
# product weight: the amount of staked NXM allocated to that cover product
total product capacity = reserved product capacity + available product capacity.
# reserved product capacity: the reserved product capacity for covers that have been sold
# available product capacity: the remaining capacity that can still be sold
Cover buys and reserved capacity
When someone buys cover, the protocol reserves the necessary amount of capacity within the staking pool(s) from which the cover was sourced. The protocol uses the NXM value of the cover amount at the time the cover is purchased to reserve capacity for the length of the cover period. This capacity is reserved until the cover expires, at which time the capacity becomes available again.
Capital pool risk control
# Capacity Design (Diversifying the capital pool's risk through a diversified portfolio of smart contracts):
Similar categories of smart contracts will have a fixed upper limit on their proportion in the capital pool, preventing collective claims events of a specific type of smart contract from impacting the overall payout capacity of the entire capital pool in extreme circumstances.
Staking Pool
Staking
There are many staking pools. Members with risk and pricing expertise[i,.e, the staking pool manager] can create a staking pool. Each staking pool underwrites a definite number of cover products, opens up capacity for those cover products, and carries the risk of having NXM stakes burned to facilitate claim payouts for covers sold from that pool. Risk is assessed and managed in individual staking pools.
Staking Pool Managers
Staking pool managers are responsible for creating staking pools, determining the initial pool settings, and managing and pricing risk within the pool. Those who have an existing risk management business or specific risk and pricing expertise can create a staking pool and earn rewards for managing risk within the pool. A manager can create a public staking pool, which accepts delegations from NXM stakers, or a private staking pool, which does not accept delegations from NXM stakers.
Staking Pool Settings
Different Pool has different settings
1. Management Fee
Those who decide to manage risk within a staking pool charge a management fee, which is the percentage of all rewards earned whenever someone buys cover from the pool. When a cover is sold, 50% of the cover fee flows into the pool. The management fee is charged before rewards are distributed among NXM stakers within the pool. (first give reward to manager then the reward distributed to the NXM stakers in the pool who delegate their token to the manager)
When a pool is first created, the maximum management fee needs to be set. The highest management fee that can be set for a staking pool is 100%. Once the maximum fee is set at creation, it can never be changed, though the fee can be adjusted up to the maximum. With multiple staking pools, managers can adjust their fee to be competitive in order to attract additional NXM stakes. NXM stakers can review the current and maximum management fee charged within a pool and use that to determine where they delegate their NXM stakes.
2. Capacity
Managers choose which cover products to include in their pool and how much NXM to stake against each individual product to open up capacity, or the amount of cover that can be sold over a given period of time for that product.[important: One thing need to keep in mind, for a specific product, more people stake their NXM on that product, then that product can be sold more, because there are enough money to do the claim pay out when accident happens, so that why we said more stake, more open capacity ] The manager can decide the upper capacity for each product in one staking pool.
3. Product Weight [leverage]
Managers can stake NXM across products with up to 20x leverage. The amount of leverage used within the pool determines the total target weight for the pool. For each individual product, the most NXM that can be staked is the balance of NXM available in the pool. For example: if a staking pool has 10,000 NXM, a manager can stake up to 10,000 NXM against a single product[no use leverage, the maximum staking on one product is the whole staking pool amount]. If a manager uses 20x leverage, they can stake 10,000 NXM against 20 different cover products. However, a manager could stake 5,000 NXM against 40 different cover products.
4. Product Pricing
Managers also determine the target pricing for each cover product. The target price is the lowest price a staking pool manager is willing to accept for a specific cover product. The minimum target price that can be set is 1.00%, while the maximum target price that can be set is 100%.
Previously, any member could participate in the risk assessment process, though there’re technical barriers and cost prohibitive gas fees that prevented more members from staking NXM.
In updated staking model, members can participate in one of two roles:
* NXM Stakers:
Members who choose a fixed timeframe to delegate their staked NXM to risk experts that manage staking pools, they do not control how their NXM is allocated within a staking pool.
* Staking Pool Managers: Members with risk and pricing expertise that create and manage risk staking pools.
Delegating staked NXM
When someone choose to stake and delegate their NXM, they delegate both capital and voting power (i.e., the voting power is delegated as well) Staking pool managers can use the delegated NXM stakes to (1) allocate against cover products within the pool and (2) use the pool’s voting power to participate in on-chain governance; however (3) delegated NXM stakes cannot be used in the claim assessment process.
Staking Period
When someone decide to stake their NXM, they need to choose the stake period AKA the stake length, there are eight choices, at least 91 days and at most 2 years. Members are able to delegate their NXM to multiple staking pools and for multiple staking periods. Note: Each staking period will have a fixed date range, so all NXM delegated in one staking period will expire at the same time.
Explain: If all members start staking at the same time and choose the same staking period, the withdrawal date will be the same for everyone. If the start time of staking is different but the same staking period is chosen, then the withdrawal date will also be different.
Rewards for Staking
When members purchase cover and pay the cover fee, 50% of the cover fee is minted in NXM rewards and distributed to stakers in the pool.
1. The staking rewards do not compound to staking positions, which means the reward generate by staking will not add to the initial staking amount.
2. locking NXM for longer periods increases the share of cover fees a member will receive. Though stakers can take the 50% cover fee but the proportion between stakers are dependent on some factors: stake amount and stake time [i.e., the locking period]
# Staking Reward Formula:
Reward Shares = stake Shares * (1 + (10% * lock_period_in_a_year * days Until Stake Lock Period Ends / 365)
& stake Shares: the amount of NXM staked in one position for a given lock period
& LOCK_PERIODS_IN_A_YEAR = 4
Model
Risk of NXM burns
When members delegate their staked NXM to a pool, their NXM can be burned to facilitate claim payouts if members who purchased cover from the pool file successful claims. If a claim is filed and approved by claims assessors, then the staked NXM allocated to the relevant cover product is burned proportionally across all stakers.
Claims
Claim type
Claim process
1. Claim Submission
If one want to submit a claim when his cover is active:
# Note: the deposited amount will distributed as claim assessors reward; the deposit amount has a min and max bound; deposit amount can prevent people from spamming the claims process with multiple claims, however, there is no time limit for submitting the claim once pay the deposit and the cover is active
2. Voting process
Claims assessors: Members can stake their NXM and participate as a claims assessor. Claims assessment stakes are locked for 90 days after a member’s last vote was cast. Assessors review the incident details, proof of loss, and other supporting information to determine a claim’s validity.
Outcome
#Accepted:
(1) A simple majority (50%+) is required to decide an assessment vote
(2) The assessment will last for a minimum of three days, which starts from the time the first vote to approve is submitted
(3) There is a 24-hour silent period, where no votes should be casted before an assessment vote closes
# Deny:
If claims assessors review the claim submission and determine that no loss has occurred or that the claim does not meet the terms of the cover wording, no deny vote is required unless another member submits a vote to approve. If a claim receives no votes and the three day period passes, the claim will be denied by default
3. Claim Payout
When a claim vote has closed with an accepted status, a cool-down period of one day needs to pass before the claim payout can be redeemed by the member who submitted the successful claim. Once the cool-down period has passed, a claim vote is finalized and the member has 30 days to redeem their claim payout.
# Fraudulent votes
During the cool-down period, claim outcomes can be reviewed if fraudulent voting is suspected. If the Advisory Board finds a claims assessor to have voted to deny a legitimate claim or approve an illegitimate claim, then a fraud penalty can be imposed. The Advisory Board can submit a merkle-tree root hash representing the fraudulent voter and their assessment stake. The fraudulent vote is reversed and the fraudulent assessor's stake is burned.
4. Claim assessment rewards
# Total Reward: Members who lock their NXM and participate in the claims assessment process earn rewards for voting on claims. The total assessment reward pool is calculated using the following formula:
“Total Reward In NXM” = min (“max Reward In NXM”, expected Payout * reward Ratio * cover Period In Days / 365), the “max reward in NXM” is equal to 50 NXM and “reward ratio” is 1.3%.
# Individual Reward: Members that lock their NXM and participate in the claims assessment process earn a share of the total reward pool. An individual member’s share of claims assessment rewards can be calculated using the following formula: reward = “total Reward In NXM” * user Stake At Vote Time / (accepted + denied); Once you assess and vote on a claim, you will earn your share NXM rewards, which you will be able to withdraw after the vote closes and the 24-hour cool down period passes.
Mechanism of Claim Payout
There are two main approaches to claims assessment using blockchain technology.
Some limitation of using the trigger parameter insurance:
(1) Basis Risk: This can lead to poor customer outcomes especially when customers have suffered a loss but the trigger has not technically been met.
(2) Oracle Failure: Back-up claims process mechanisms will be required if the oracle were to fail.
(3) Limited Product Set: Product development requires a reliable data oracle to exist. The data must also be sufficiently granular to construct a meaningful consumer product. IoT devices are expected to bring many more potential data oracles in the future but are currently not widespread or reliable enough.
Crowd Sourcing Model is hard to design:
The key point of design the voting process is how to prevent from defraud-voting. There is a clear incentive to defraud the pool by “purchasing cover for a low percentage of the cover amount” 🡪 “using a substantial portion of the cover amount to pay-off claims assessors ” 🡪 “pocketing the difference”.
A solution to this issue is to require claims assessors to have a significant stake in the success of the overall pool and a high disincentive to act dishonestly. This can be achieved by requiring a stake be posted in the form of membership tokens. The stake is deposited for a specified period of time and provided claims are assessed honestly it is returned. If the Advisory Board deems a claims assessor to be acting dishonestly it has the power to burn the staked member tokens.
Claim Logistics 1
Claim Logistics 2
Suffer a loss of funds
File a Claim
Claim Assessors
Submit supporting evidence
Stake NXM for 7 days, voting weight is related to the staking amount
For example, when protocol cover code was attacked, there is a cool down period (24 hours after the thing happen), in this period, user cannot submit a claim but can collect the supporting evidence
Claim deposit
Leon, who holds active Protocol Cover
Cool Down Period
Governance
Protocol governance power
Every member who joins Nexus Mutual has voting power equal to one vote plus the sum total of their NXM tokens, which applies to protocol governance, the formula as follows:
On-chain voting governance = 1 + Min( 5% of NXM supply, NXM holdings)
A single member’s voting power is capped at 5% of the total NXM supply. This is designed to prevent a large holder from having undue influence in protocol governance.
Advisory Board
The Advisory Board is currently made up of five members of the mutual and contains members of the founding team and other experts. The goal is to have a qualified mix of individuals covering three broad skill sets of:
NMPIP (Nexus Mutual Protocol Improvement Proposals)
Members can propose changes to protocol parameters and incentives, the capital model, and the pricing mechanism. When new products are developed, an NMPIP is shared, discussed, and voted on by members. All investment allocations or any use of capital pool funds require an NMPIP and vote before execution, as well.
NMPIP Governance Process
NMDP (Nexus Mutual DAO Proposals)
A Nexus Mutual DAO Proposal (NMDP) is a proposal that can be used to submit a grant request for funding, create a new DAO team, or request a renewal and funding for an existing DAO team. These proposals are used to engage with the community, reach consensus, and distribute funding from the DAO treasury to fund projects and teams.
These two proposals are implemented via the governance process with the following quorum requirements:
The Advisory Board members provide a recommended outcome for each proposal via an Advisory Board vote. If the 15% regular quorum isn’t reached, then the Advisory Board's recommendation is the default outcome.
NMDP Governance Process
InsurAce
Case2: Insur Ace
“0” Cover Payment
Selling Proposition
Enriched Product Line
SCR Mining
Sustainable Returns
Continuous Evolution
Feature
1. “0” Cover Payment (price reduction):
# Use portfolio-centric products to do risk diversification
# Use unique pricing models optimizing cover cost
# Investments which help to offset cover cost
2. Enriched Product Line:
# Multi DeFi products: key point is proving a “basket” to users
# Serve for Multi Chain
3. SCR Mining:
# “SCR Mining Program”: staked underwriting capital earns $INSUR
# the rate of INSUR emission is related to the investment return
4. Sustainable Returns:
# Directly investing in investment products of various risk levels
# Staking to earn investment yields and $INSUR token rewards
# Earning returns generated by cover payments
5. Continuous Evolution:
# Quantify claims fairly, instead of simply accept or reject claims
# Provide extensions, increments, transfer capabilities to existing covers
# Establish a better governance structure for claim and engagement…
# Collaborate with other DeFi protocols to form Cover Syndication
# Improving the product line to better cover risks present in DeFi
Architecture
User Flow: Bob as an investor | Mary as an underwriter | Jack as a cover purchaser (insurance buyer)
Free capital in the Cover capital pool may be transferred to the Investment pool to earn higher yields and subsidize users' costs from cover payments
Cover protocol protects the Investment protocol as well
Revenue generated from cover payments and investment returns will (1) Contributed to Claim Payouts; Decreasing Insurance fee. (2) also contribute to the InsurAce operational and development costs, token buybacks, community incentives, ecosystem collaborations, and more.
Bob (Investor)
Mary (Underwriter)
Jack (Cover Buyer)
Investment Portal
Cover Portal
Invest
Investment Return
INSUR tokens
protection
Free Capital for Investment
Investment Return
INSUR tokens
Stake
Investment Return
Claim
Buy Cover
INSUR tokens
Insur Ace plans to invest any free capital in excess of SCR needed in other DeFi products to gain investment returns. Potential ways: (1) Yield farming[流动性挖矿] on audited protocol; (2) Supplying liquidity to lending protocols such as Compound to earn interest; (3) Supplying liquidity to DEXs such as Uniswap to earn fees
Different Risk Levels
Different SCR Levels
Cover Products
Key points of Insur Ace cover products: portfolio-based.
Currently, it provides five types of products: Smart Contract Vulnerability Cover; Custodian Risk Cover; Stablecoin De-Peg Cover; Post-Audit Cover; Bridge Cover
Smart Contract Vulnerability Cover [分为group claim 或者 individual claim]
Covered Content
Claimable Loss refers to the irrecoverable loss of either
Disclaimers
Important Date
Post-Audit Cover
B2B product tailored for freshly audited DeFi protocols. It applies to loss of funds due to a malfunction or programming flaw; or an unauthorized, malicious, or criminal attack, hack or exploit of a malfunction or programming flaw that was previously undiscovered in the DeFi protocol's smart contract during the security audit process.
Bridge Cover [Cover provides protection for users moving tokens across chains]
Portfolio-Based
# Customers can choose one or multiple protocols as a portfolio to get a quotation and place the order through the Cover Portal , which is flexible and direct.
# By protocol business type: a portfolio product to include the major protocols in Lending, or DEX, or Oracles and etc. so that customers can cover the risks of a business sector by one product
# By protocol risk level: there’s an open risk assessment method to give a risk score for each protocol on-boarded, and a portfolio product that covers the same risk level protocols can be bought in one go.
Notified “Potential Claimable Risk Event”
Advisory Board investigate and verify the event
Up to seven (7) days from such notification
Advisory Board make an announcement
Confirm the occurrence of a Claimable Risk Event
Disconfirm the occurrence of a Claimable Risk Event
Extend the time to investigate
General Claim Process [advantage: quantitative and more sensitive]
Step2: Investigation
The Advisory Board shall only make a Claim Investigation Report containing the Advisory Board’s investigation findings, draw a conclusion, and make a payout proposal on the Group Claim.
Step3: Voting
Claim Submission
Investigation
(a group proposal will send to the claim assessors during voting)
Voting
At least 15% of the total $INSUR tokens staked by the Claim Assessors is involved in the vote
Default Voting Window: 48h
Valid Voting
Invalid Voting
the Advisory Board shall determine the Group Claim
Majority Voting
More than 50% of the Valid Votes reached consensus (“Majority Vote”) on the Group Proposal
No Majority Voting
No more than 50% of the Valid Votes reached consensus, then he Advisory Board shall determine the Group Claim
After determination of the Group Claim
Within 7 days
If one can be claimed
User need Submit Proof of Loss and Ownership, failing which such Claims shall automatically be deemed invalid
Out of 7 days
Claims shall be solely and conclusively determined by the Advisory Board after 5 days and based on the Claim Outcome
If one can not be claimed
Step4: Individual Appeal
In 72 hours
After the Claim is determined by the Claim Assessors(denied), the user have 72 hours to file an Appeal against the decision of the Claim Assessors and pay the Protocol a fee of 0.5% of the amount. The Advisory Board have sole and absolute discretion to make a final and conclusive determination on the Appeal.
Step1: Claim Submission
Detail about the step1 & step2
Advisory Board will propose a claim amount. For example, 0% represents a reject on the claim, 100% represents a full compensation, and other ratio between 0% and 100% represents a partial compensation.
claim assessors
In the first round voting, the claim assessors need to meet a minimum requirement of stake.
In the second (if the voting do not fulfill the requirement in the first round voting), then everyone who has the $INSUR token can be the claim assessor
Governance
Community Voting: the community can vote for or against proposals
$INSUR as the governance token for voting and incentives, representing members voting rights. A cap is placed on the voting power of each member so as to avoid the risk of having voting power concentrated in the hands of a few individuals. Voting outcomes are determined by quorum, majority voting, and voting weights.
Governance Framework
Advisory Board: consists of (1) Insur Ace team (2) 3rd-party independent advisors with technical, insurance, compliance, and other relevant expertise
The Advisory Board works as an oversight committee to set specific rules, review community proposals, and execute contingency plans when community voting fails.
$INSUR & Voting Power Cap
Governance Process
Step1: Proposal Raised 🡪 InsurAce members bring a proposal forward
Step2: Advisory Board Review: provides comments for the community reference, sets the proposal incentives, and defines what the default outcome will be should voting fail.
Step3: Members Vote: vote for or against the proposal. In the meantime, members' $INSUR tokens may be locked-up in the InsurAce protocol until governance reaches a definite outcome.
Step4: Execution: The outcome is disclosed to public. The InsurAce team and community contributors will then work together to implement proposals that have made it through governance.
Pricing Models
Current Problem of Insurance Product
Heavily rely on the value staked on individual protocols: the higher value staked for the specific protocol, the lower cover products will be priced. This staking driven pricing structure fails to assess the real risk of each protocol and is very likely to significantly over-estimate the prices of cover products of those less staked protocols.
Insur Ace New Model
Workflow of Aggregate Loss Assessment: estimate the expected loss in portfolio level
Main Input: 1. number/amount of claims 2. number/amount of exposures in a given time window
Models:
Train models
Insur Ace combines two models to solve the problem of aggregate loss
After aggregate loss decide, it can incorporate in the risk factors of protocols, and formulate the final pricing calculations.
Parameter: initially defined, devised, and validated using historical data. After that, continuous refinement and optimization of said parameters based on new data that is constantly being collected and machine-learning methods
Dynamic Pricing due to supply and demand
Pricing determined by the supply and demand, starting from a minimum or base price up to a maximum price of three times the base price. The more covers sold, the higher the price.
Total capacity is 8M.
Portfolio-based Pricing
The Mutual Cover Pricing heavily rely on the staking amount, if the staking amount is less than the insurance price will be high, even though the risk of that cover product is less.
In Insur Ace, it use the portfolio-based covers to low down the risk and use the aggregated model to give a more precise estimating of the “expected loss of the insurance” which is much make sense.
Tokenomics
Use Case of $INSUR
$INSUR token supply and allocation
# Total Supply: 100M $ INSUR (the total amount has an upper bound)
# How to get $INSUR: (1) Buy through exchanges (2) Earn by incentives such as participating governance event, mining, investment and so on
Public sale on Balancer LBP for liquidity bootstrapping and promoting community awareness
Reserved for liquidity provision on exchange listing, marketing initiatives, developer grants, bug bounty programs, strategic partnership, and long-term development of the platform
In accordance with the mining schedules
5% unlock upon TGE, linear vesting/block over 2 years for the rest starting from the 3rd month after TGE
25% unlock upon token generation event (TGE), linear vesting/block over 2 years for the rest starting from the 3rd month after TGE
15% unlock upon token generation event (TGE), linear vesting/block over 2 years for the rest starting from the 3rd month after TGE
Capital Pool & Model
Capital Pool: funds accumulated (1) underwriting mining pools, (2) cover payments, and (3) investment pool, all of which are governed by $INSUR token holders
Capital Model: EIOPA’s Solvency II
SCR (Solvency Capital Requirement)
The capital required to ensure that an undertaking will be able to meet its obligations over the next 12 months with a probability of at least 99.5% [Soft Requirement, aim to defend for the extreme situation]
The capital required by the undertaking to meet its obligations over the next 12 months with a probability of at least 85%, and is range bound between 25% and 45% of SCR [hard requirement]
There are different tiers of capital requirements under Solvency II, namely the Solvency Capital Requirement (SCR) and Minimum Capital Requirement (MCR).
# SCR Calculation [with the following factors]
The team updates it to on-chain only if there is a noticeable change in the required capital requirement.
# SCR% [Solvency Capital Requirement Ratio]
The SCR% is the ratio of capital that the undertaking has available to support its SCR:
🡪 Formula: SCR% = Capital Pool Size / SCR
# CER% [Capital Efficiency Ratio]
🡪 Formula: CER% = Active Cover Amount / Capital Pool Size
The ratio of output per amount of capital dedicated to the operation of a business or a product line
MCR (Minimum Capital Requirement)
SCR = Technical Provision + Additional Funds
Staking and SCR Mining
Staking Mechanism
LP Tokens
Mining Pool Factor
Risk Management
3-step risk assessment approach for investment and protection protocols and bucket them into different risk categories.
Step1: Expert Assessment
Community Assessment
Continuous Update
Advisory Board do preliminary risk assessment on the new protocols at first with their expertise from several dimensions(Auditing reports of the protocol; Code analysis; Qualifications; Operation track records; Relevance to existing hacked cases)
After the Advisory Board assessment, the protocol to be listed will also need to go through a community driven risk assessment which will be conducted by Insur Ace's volunteer community members to further evaluate and get a risk score. The members who participate in this process will get INSUR tokens as incentives. With the above two steps, a final risk score will be given to the protocol.
Meanwhile, they work with professional security auditing firms to seek for their support should there be extra complexity or challenges in due course. After this, the Advisory Board will provide an assessment report and security rating as the reference for the community.
Insur Ace employ the preparatory risk models to continuously evaluate risk level by collecting data and information of the given protocol, such as the staking changes, the claims to the protocol, correlation analysis to new security incidents, and etc. Such updates will be reflected into the existing risk model and provide updating risk assessments.
Security Rating Methodology & Data Transparency
Security Rating
Project Implementation (10%)
Project Operation (15%)
Team Qualification (5%)
Audit (40%)
Project nature & technical difficulties
Percentage 🡪 weight
Roadmap and future changes
Back-end chain
Project age
Operation history
Existing coverage on funds
TVL
Team anonymity
Team experience especially in programming
Operations and management
Transparency and scope
Findings and vulnerabilities
Trust score
Frequency and updates
Code (30%)
Issues raised on Github or by community
Oracle
…..
Multi-signature
Architecture
Data Transparency
Transaction data of cover products
Key metrics for the capital model, such as the SCR, SCR%, staking pool size, etc
Pricing models parameters
Investment plans, executions, and income
Platform operational cost and income
Claims process and execution
Community proposals and governance
Liquidity mining details
Token issuances and distributions
Unslashed
Unslashed Finance
Cooperation with Enzyme Finance
Unbiased Claims Assessment: Cooperation with KLEROS
Capital Buckets (structured insurance products)
A Capital Bucket is a diverse collection of insurance policies that are designed, assessed, priced and put together for Insurers to underwrite.
# For example, the Spartan Bucket is the first structured insurance product listed on Unslashed. The Spartan Bucket could contain the following:
The Spartan Bucket has a default maximum exposure of 5% of the insurance capacity per policy, which can be adjusted by the DAO on a policy per policy base through majority vote.
Unslashed cooperates with Enzyme Finance which supports 200+ assets and is integrated to all types of DeFi protocols. Enzyme Vaults can handle lending, AMM pools (eg. Uniswap and Curve pools), staking (eg. Curve LP tokens or just plain ETH), semi-automated farming strategies, leverage and more which makes it possible to earn yield efficiently[capital efficiency].
Asset Management through Enzyme make advantages:
Unslashed leverages Kleros and its decentralised dispute resolution protocol. Independent assessors and arbitrators review the claims based on the policy documents provided for each insurance policy and the pieces of evidence presented by the claimant. Claims are therefore treated fairly and in an unbiased fashion.
Kleros is a decentralized dispute resolution protocol which has been implemented on Ethereum. By applying a set of rules and by using game-theoretic incentives, Kleros’ Jurors are able to provide solutions to highly complex problems. Kleros evaluates all disputed claims and their rulings, when favorable, automatically trigger the payouts to claimants.
$USF Governance Token Holders
$USF holders vote on the direction the protocol takes and also updates the protocol parameters. Over the first months, the team will continue managing the protocol parameters and will gradually transition it to the Unslashed DAO.
Insured are Cover Buyers who pay an Insurance Premium to buy a cover and be insured against a wide variety of potential risks.
Insurers are Capital Suppliers who are able to participate by contributing ETH to various Capital Buckets or through specific, individual Capital Pools. Insurers will earn yields by:
Insurer
Insured
The Unslashed Enzyme bridge: Unslashed 🡪 Enzyme
Asset Management Integration
ETH
In this way, Unslashed can earn:
(1) a yield (2) stronger security guarantees
For the capital deployment of Enzyme: strategies are voted over by the governance. The first Enzyme fund used for deploying the capital is USF Fund.
Premium Price
The Premium Price depends on multiple factors:
Cycles
Rollover Price[滚动价格]: 金融衍生品市场中，在合约到期之前，持有人可以选择将合约继续持有，并通过支付一定费用或调整合约条款来延长合约的期限，以便继续持有该合约的权益。这个过程被称为rollover.滚动价格是根据特定的市场因素、交易规则和合约条款计算得出的。它反映了下一个周期开始时某种资产或金融产品的预期价格.
# In Unslashed: The rollover price is a coefficient acquired at the end of the cycle by dividing the remaining amount of deposited Premium by the total amount of Premium deposited by the Policy Buyers. This coefficient influences the Insurance Capacity.
Rollover essentially resets the Insurance Capacity to almost zero, freeing up most of the supplied Capital allowing the Capital Suppliers to withdraw some profits and/or allowing Policy Buyers to buy coverage for the following cycle.
The same amount of premium buys a different amount of cover depending on the stage of the cycle at which it is deposited.
Product Types
Capital Pools & Buckets & Utilization
A capital pool is used for a single policy
Money transferring with time from the “premium deposits” to “Capital Pool”
A Capital Bucket is a collection of insurance policies: diversify exposure
Insurers supply assets (ETH) to Capital Pool and have a risk exposure that is limited to one single policy. By depositing assets (ETH) in a Capital Pool, insurers receive a yield in the form of Premiums, which are paid in ETH by Cover Buyers in exchange of being protected against the risks of policy.
Premium Deposits made by Cover Buyers (Insured) are consumed as time passes-by and transferred to the Capital Pool. In the event of a loss within the scope of the policy, a claim can be filled by the Policy Holder and the Capital Pool is used to make the payout.
.
In Capital Pool, there is a “Maximum Available Cover” mechanism. Capital Pools design disallows withdrawing Capital or depositing more Premium if that action would result in a situation where the maximum payout exceeds the maximum cover.
Because the deposited Premium flows into the Capital Pool, while the Maximum Available Cover stays the same, space to either withdraw some of the capital supplied or purchase additional coverage is freed.
It’s non-withdrawable because of the requirement of “Maximum Available Cover”
Because the money transfer from the “premium deposit” to the “capital pool”, so the capital pool money increase so that it over amount the “Maximum Available Cover” requirement. So partial money is free and can be withdrawn or buy more coverage
Governance
Proposal Lifecycle
Any community member is encouraged to post a draft for initial reaction feedback
A Discourse-hosted forum for governance-related discussion. Community members must register for an account before sharing or liking posts.
Gasless signal voting interface that allows users to signal sentiment off-chain. Votes on scattershot are weighted by the number of USF and LP tokens delegated to the address used to vote. Given the gas costs on the Ethereum network, most of the non-transaction based decisions are voted through Scattershot.
Tally is a friendly user-interface for the governance smart-contracts, It supports direct voting and vote delegation, helping users put their governance insights into action.
Claim Assessment Process
Step 1 | Claim Request: An Insured submits a claim and provides evidence of his or her loss. The claim has 2 days to be challenged, anyone can challenge a claim. If not challenged, the Insured receives his or her payout.
Step2 | Challenging Process: If the claim is challenged, it is sent to a Kleros court. The Insured can add as much evidence as he or she wishes.
Step3 | The Kleros Court: A Pool of Jurors reviews the evidence (usually take five days) and votes to rule whether the claim is valid or not. If deemed valid, the Insured receives his or her payout. If deemed non-valid, he can appeal and provide additional pieces of evidence.
In case of an Event Payout, affected Insured receive a cover from the Capital Pool in exchange for their associated amount of Premium Tokens (PTKN) which are being burned. The Premium corresponding to the burned Premium Tokens is transferred to the Capital Pool. The transfer of the Premium does not affect the Premium Tokens price.
Claim Payout
Tokenomics
Capital Mining: It allows the protocol to reward early supporters and users of Unslashed with the governance token. Rewards are calculated at the end of each epoch[epoch是人为划分的一个固定的时间段，以便于奖励分配等] and distributed linearly over the following epoch once the token is issued. In the event of a partial withdrawal or transfer of the Spartan Bucket ERC-20 tokens, only the capital or tokens remaining till the end of an epoch were used in the calculation of rewards. Bonus rewards for committed Capital Miners are also distributed at the end of each epoch. The calculation of the bonus is also made block per block.
LP Mining: It allows the protocol to reward early supporters and users of Unslashed with our governance token. This aims at building up a solid base of long-term supporters with a strong interest in accumulating more USF tokens through LP Mining. Each block, USF tokens are earned by LP miners. These rewards are calculated block per block. A bonus reward is also distributed amongst those who provided liquidity for one of the incentivised Capital Pools for multiple epochs in a row.
Mining
Tidal Finance
Agent
Cover Seller (AKA: Reserve Provider): Users that are staking their stable coins (USDC) as insurance reserve capital with the intention to generate premiums.
Guarantor: Stake in Guarantor’s Reserves to guarantee a given protocol. Such reserves will be used to compensate reserve providers in the event of paying out a valid claim against the guaranteed protocol, as well as receiving extra yield - a percentage of all the premium sold for the guaranteed protocol.
TIDAL Staking Pool: TIDAL token holders. The staking pool is designed to earn additional TIDAL token as well as taking certain risks of a payout event - Certain percentage of the staking pool will be used to compensate reserve providers whose capital were reduced during the payout.
Cover Buyer
Pay Out Flow
Pay In Flow (Premium Distribution)
Pay in & Pay Out Flow
Temporary treasury funds will not be utilized at initial launch. The Cumulative reward can be used for risk management and assessment committee and initial payout pool as the size of the fund grows.
Mutual Cover Protocol
Each pool will be set up to provide cover for a combination of cryptocurrency contracts or assets. This allows the reserve funds to be used as a form of fractional reserve, allowing various levels of leverage, yields, and risks for LPs, depending on the reserve ratio, and the correlation between the covered assets.
Each mutual cover pool is governed by a Reserve Smart Contract where reserve funds are provided by Guarantors and LPs, and the corresponding cover token(本质上是保险合同) is issued that provides coverage for the specified DeFi protocol and token(s) for the specified period of time.
# Pool Creation
Initially Tidal intends to offer a few pools with different risk levels, the detailed risk criteria and protocols inside each pool will be released at launch.
# Define Pool Parameters: minimum reserve ratio, maximum leverage exposure, premium pricing correlation and premium distribution
# Propose New Protocols: Token holders can propose any new protocol to introduce on TIDAL platform, and the governance will approve the protocol according to risk assessment metric.
# Provide Reserve Capital to Mutual Cover Pool
Select mutual cover pool 🡪 Provide Liquidity (Guarantor Reserve: provide liquidity for one protocol) or (Leverage Reserved: Select multiple protocols to provide liquidity, set the exposure level of each protocol) 🡪 Select and confirm the amount of tokens to stake to the mutual cover pool 🡪 Token Incentive: TIDAL Governance Token will be sent to the same address as an incentive for providing reserve capital
# Cover Price
Cover price determined in two overlaid processes:
1. Base Price 🡪 by meeting certain expected return of LP’s capital, which will be set up at the beginning of each expiration date cycle based on risk assessment and coverage utilization.
2. Actual Price 🡪 Base Price +/- Adjustment, where adjustment is determined based on over or under utilization of available coverage.
Claim and Payout
Process of filing and approving a claim
Cover Buyer must submit a claim within 3 days of the incident
Claim Assessment Committee
vote for the request
There are currently 4 committee accounts. 2 from Tidal team and 2 from Halborn team. All 4 votes need to pass to go to next step. Otherwise, will receive a “No”
If the “claim assessment committee” agree to pass then
the reserve pool of the claimed protocol will be temporarily locked
holder can stake 2,000,000 TIDAL tokens to create a proposal for the payout amount, the proposal contains a trusted receiver address for the payout.
The proposal itself should contain executable code about payout details to deduct from each reserve pool (amount of USDC, amount of TIDAL, amount of guarantor token).
DAO evaluates the description of the proposal and the executable code contained in it, and votes to pass the proposal (72 hours). Current minimum voting threshold is 5,000,000 TIDAL counts and pass ratio is 50%.
Once passed, the amount will immediately be deducted from the reserve pool, and paid to the trusted receiver address held by the claim committee; and the locked reserve pool in step 3 will be unlocked.
Cover Buyer
Claim Assessment Committee (four people)
file a claim
Approve
Put the relevant reserve asset into lock
DAO (TIDAL token holders vote)
DAO will evaluate the submitted proposal and execute its decision-making power based on a heuristic approach
the claim committee will perform the final approval and proceed to pay the damaged users in accordance with the amount being approved
Approve
Simple Version
Capital Management
# Guarantor Mechanism
As the DeFi space grows exponentially, the gap between market supply and demand is widening fast, coverage is often unavailable for most new smart contracts. To mitigate this problem, TIDAL will implement a "Guarantor" concept to provide additional capital to cover the risk. Guarantor capital will be used as the first source of funds to pay out the insurance claims ahead of capital supplied by regular reserve providers. This allows founders of new projects to act as Guarantors of their own project, earning yield from cover premium while attracting other regular LPs to provide coverage.
# Dynamic Reserve Capital Adjustment
LPs are allowed to withdraw reserve capital, but only when the sold cover amount is below a certain threshold of the LP capital, or submit the request to enter into a waiting period (initial waiting period length will be determined at launch).The maximum leverage of exposure will be dynamically adjusted over time depending on the risk to hacking and other forms of attacks, as well as the number of protocols covered by each pool. The leverage should be increased asmore protocols become mature on the market.
# Three Types of Fees
# TIDAL Treasury Wallet & Token Issuance
Issuance Fees, Transaction Fees, Redemption Fees are collected and sent to TIDAL Treasury Wallet. Besides, any additional yield will also inject to the TIDAL Treasury Wallet. The wallet is used as a “back-up”, “source of reserve capital”.
Token Types
# TIDAL Cover Token (Cover Token)[相当于买保险后的拿到的合同凭证]:
Entitle the owner the right to receive a mutual coverage based payout in the case of the failure of covered protocols, these tokens are a form of digital contract and proof of coverage.
The Cover Token has the 4 attributes: 1. Notional Value(notional cover of the protocols); 2. Expiration Date; 3. Last Claim Date; 4. Last Payout Date(the last day can redeem the payout)
# TIDAL Governance Token (TIDAL Token):
Governance token that will govern all aspects of TIDAL Protocol: submit/vote on governance protocol, assessing claims, decide the payout of emergency reserve capital for payment of claims and held in the TIDAL Treasure Wallet.
Token Supply
HELMET
In traditional financial market , derivatives such as options are effective in hedging the risks of market volatility. But the market lack transparency and better infrastructure to improve efficiency. Considering that assets with high liquidity were eligible to be designed as options products, "The Options" became a unique tool to serve commodity traders.
[传统金融中，高流动性的资产被设计为期权产品, “期权”成为大宗商品交易者的工具，非大宗商品被作为期权的很少]
Helmet is a P2P insurance protocol written by option trading logic, which allows anyone to create any insurance policy in the market.
Motivation
P2P creative platform
Introduction
Agent & Role
When Policy mature, policy holder could choose to claim or abstain the insurance[可以选择兑现/不兑现]. For example, Peter bought a 1 month of "Cover 50% off " insurance of A token, in this period, the price of A dump 50%, then Peter could claim it and earn a premium to hedge his lose.
Mechanism & User Flow
Policy: Each Policy Specifies four elements: (1) Denominated asset[计价资产(品种及数量)]; (2) Underlying asset[被保资产(品种及数量)]; (3) Policy price; (4) Insurance period.
User Flow: One can be a supplier if she is ready to 1.depositing denominated assets, 2.choose the insurance type[“cover up” or “cover down”][看涨or看跌], 3.price the premium and publish it. Once a supplier publish a policy, the denominated asset will be locked in smart contract, at the same time, Helmet will create a SHORT Token for supplier and a LONG Token to the market. Anyone buy Long Token on the market is policy holder. Long Token and Short Token is created 1: 1 when policy published.[短币归卖家，长币流入市场，谁买了长币谁就是买家]. The policy holder has rights to exchange the the insured asset to denominated asset at the policy ruled price before expiration[买家有权利，在保险过期前，将被保资产送出，换取计价资产].
Userflow
Supplier put denominated Assets A in the smart contract and get “short token”.
Bidder pay Helmet Token, get the insurance and hold the “long token”.
If the policy is activated, then bidder burn “long token”, get asset A and give asset B to supplier.
Supplier burn “short token”, give asset A and get asset B.
If the policy expired or do not activated, then asset A back to supplier.
Note for policy supplier
Insurance Type
Type (All the insurance can DIY, the following are examples)
1. “Cover 50% off”[腰斩险，看跌类]: The Policy holder can pay premium to insure their bearish assets at a very small cost. The Policy holder will get profits when the value of the Token insured before the expiration date is lower than "half" of the price at the time of issuance. For the revenue, for the policy supplier: Min(current price - policy price, 0) + premium. For the policy holder, the revenue is Max(policy price – current price, 0) – premium.
The maximum loss of the policy holder is just premium, while there is no cap on the gain.
2. “Cover Miss Out”[翻倍险，看涨类]: a kind of insurance against ‘fear of missing out’. Policy holder pays a tiny cost for a “call‘ to prevent missing the price denominated asset rise. For example, if the insured Token's price is higher than double of the issue price before the expiration date, the holder will get a profit. If the value of the Token is not more than double, the policy supplier will receive a stable premium as interest.
Token (Helmet Token/ Long Token/ Short Token)
Helmet Token: total supply is 100 million; Governance Token (community vote)
# Function: (1) vote campaign (2) buy an insurance policy (3) stake to earn fee
# Earn Token: (1) policy(short token) mining (2) LPT mining (3) Governance or Vote
COZY
Protection Markets
Protection Market
Insurance Buyer
Two Key Components
Cost Model: sets the price of protection
Trigger Contract: defines when a market pays out
Protection Sets
A protection set is a group of protection markets. Protection providers deposit funds in the protection set to underwrite the risks associated with all of the markets in the set. The admin of the protection set manages several key parameters, such as: (1) Leverage Factor[杠杆]: Use to calculate the maximum amount of protection that can be sold; (2) Fees[手续费]: used to calculate the percent of buy and cancel volumes that go to the set creator; (3) Market weightings[权重]: used to calculate the total available protection for each market
Create a Protection Sets
# Earn fees: Anybody can sell protection by providing assets to the protection set and anybody can buy protection from any of the protection markets in the set. The creator of the protection set can earn a share of fees collected by the protection set. [earn percents]
# Logistics for creating a protection sets:
1. Choose base assets
2. Choose a leverage factor
3. Choose weight for each market
Create a Trigger
Triggers contain logic that can be used by protection markets to determine whether to pay out. If you create a trigger, it can be used by protection market creators
If you want a market to exist but you can't find a suitable trigger, you can create your own trigger. Once you deploy your trigger, anybody can use your trigger for their own protection market.
Cozy Ecosystem
# Creator: develop markets by creating trigger contracts and/or curating collections of markets to manage risk.
# Buyer: buy protection against the condition defined in that market’s trigger contract by purchasing protection tokens. If the trigger occurs, you can redeem your protection tokens for underlying assets like USDC. You can cancel your protection anytime by selling protection tokens back to the market.
# Provider: deposit assets to back the protection markets in a protection set, allowing protection market users to buy protection tokens. In exchange, you earn fees from every transaction.
Get Prediction
# Protection tokens decay: Cozy protection doesn't expire, however the value of your protection decays over time. The amount of assets your protection tokens are worth if the market triggers goes down over time. You pay an initial fee to buy protection, and you can sell any remaining protection back at any time.
# Cancel your protection for a refund: You can cancel your protection and get a partial refund from the market. The size of your refund is calculated using the refund model.
# Underwriting capital is shared across all markets in a protection set: The assets backing protection are shared by all of the markets in a protection set. That means that if other markets trigger, there may not be enough funds backing your protection. If this happens, you can either wait for protection sellers to add more capital or cancel your protection.[因为加杠杆了，所以不保证触发的specific market pool有足够的后备资金可以立即赔偿]
# Price: The Set Admin specifies the price for each unit of protection based on a curve. The price goes up or down depending on the utilization of the market.
Providing Prediction
# 100% Utilization: You are able to withdraw funds from protection sets as long as all markets are under 100% utilization. If a market is fully or overutilized, you will have to wait to withdraw funds
# Frozen markets: If a market is frozen, you cannot withdraw funds. You will have to wait until the market is no longer frozen.
# Initial withdrawal delay: After you deposit funds, you have to wait for a delay period before you can initiate a withdrawal. This is a safeguard to prevent price manipulation.
# Two step withdrawal: Withdrawing funds requires two steps. First, signaling a withdrawal which starts a delay period. Second, completing the withdrawal after a delay period.
Reference
1. https://blog.chain.link/blockchain-insurance-zh/
2. https://www.odaily.news/post/5161105
3. https://www.defidaonews.com/article/6778830
4. https://www.qianba.com/news/p-435591.html
5. https://www.wwsww.cn/DeFi/15076.html
6. https://mirror.xyz/web3rain.eth/MyqFcY1mWR26bDaBGoGSVcW7u96gNTBo5hGBggLS7JE
7.https://www.yicai.com/news/100921245.html
8. https://www.wu-talk.com/index.php?m=content&c=index&a=show&catid=8&id=4150
9.Nexus Mutual https://www.jinse.com/blockchain/790197.html
10.http://insurance.hexun.com/2021-03-14/203192121.html
11.https://news.marsbit.co/20201218105730006401.html
12.https://zhuanlan.zhihu.com/p/222669668
13.https://medium.com/@winkryptocom/
14.https://www.tuoluo.cn/article/detail-10036865.html
15.https://mirror.xyz/web3rain.eth/mCR9tAXvYFdB3d4rY68hUBUUPIw7R6UmrXrGc5dUmIQ
16.https://docs.nexusmutual.io/overview/
17.https://caifuhao.eastmoney.com/news/20210806161532294011150
19. https://docs.nexusmutual.io/
20. https://docs.insurace.io/landing-page
21. https://docs.insurace.io/landing-page/documentation-1/whitepaper