Insurance
We understand participating in launchpad IDOs is a high risk - high reward activity hence we have innovated an insurance feature to safeguard backer's principal capital, tailoring to everyone's risk appetite.
How Insurance Works?
Currently in the market, most launchpads/IDO platforms do not have protection in place to safeguard users' principal capital against volatility when investing in newer crypto projects, making it an extremely high risk activity for IDO participants.
At AptosLaunch, we have engineered an Insurance feature to limit any potential downside and protect the user's principal capital. For example, if a user buy the IDO round of a launchpad project, the user can choose to add a % of invested funds to buy insurance using ALT tokens. The ALT tokens will then be sent to the AptosLaunch Insurance Fund. The AptosLaunch Insurance Fund will then cover any potential loss of the user's principal capital for the next 60 days - on the 60th day since the IDO launch, if the TWAP is less than the IDO price, the AptosLaunch Insurance Fund will cover the differences to the user, so the user's principal capital is well protected. On the other hand, if the project does well, the user's return will be infinity% - % paid in insurance costs.
Users will be able to buy insurance for all projects launching on AptosLaunch, but the costs of insurance will vary, depending on the risk factors of the projects. The higher the risk of the project, the higher the insurance costs. AptosLaunch have various built-in proprietary metrics to assess the risks of our launchpad projects.
Insurance Protocol Mechanism
Launchpad users can decide if they want to purchase the insurance or not
The insurance fee is determined by the Equity Risk Premium model, relative record Approach and the Insurance % charge assessment
All the insurance fee will go to the insurance pool directly
The fund will be used to repay the loss of IDO investment After 60 days, DAO will calculate the average peak price of 60days (UTC+0).
If the price dropped below the IDO price, the difference will be covered. If the fund do not have enough assets to repay the debt, Dao’s fund will be borrowed.
Insurance % charge assessment
This can lead to results that may seem unreasonable, since the valuation of a project with no net worth should be of little value. Other modeling techniques would reflect the unique characteristics of valuation of a project.
T = time of insurance
MV(t) = the market value of similar product at time t
S(t) = project at time t
C(T) = Current valuation of a similar project in the market as of time zero when insurance expires at time T
Shares = number of token unlocked = number of shares granted
r = risk-free rate of return, such as staking
E = Equities’ and Funds’ share and the unlock model
Option = Insurance option
From risk neutral assumptions, the expected value of MV(T) just prior to option expiry is equal to:
Claims Assessment
There are two main approaches to claims assessment using blockchain technology. Firstly, using an oracle which is either a trusted off-chain information provider (e.g to trigger parametric insurance events) or secondly, crowd-sourcing information and assessing claims using voting mechanics (e.g a prediction market).
Under a discretionary mutual model there is a legal requirement that a group or subgroup of members decide on how funds are distributed. This immediately focuses efforts on the crowd-source approach but there are other arguments that limit the usefulness of parametric trigger-based cover:
BASIS RISK - This can lead to poor users outcomes especially when users have suffered a loss but the trigger has not technically been met.
ORACLE FAILURE - Back-up claims process mechanisms will be required if the oracle were to fail.
Returning to the crowd-source model, there needs to be an incentive for people to report and a strong disincentive to prevent fraudulent reporting. This is somewhat difficult to achieve in an insurance context because 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 and then
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.
In addition, the following other incentive structures will be put in place:
• Voting with the consensus outcome entitles claims assessors to a share of the fee pool. Fees will be paid as additional member tokens and valued at a fixed percentage of the cost of cover.
• Voting against the consensus outcome results in locking of the bond for a longer period. Assessment is often challenging and automatically burning high values of member tokens for genuine differences of opinion needs to be avoided.
• Voting power must add up to greater than 5x the cover amount, where voting power is determined by the number of staked member tokens used to vote.
• No consensus results in a reduced fee pool for claims assessors and the claim is then escalated to all members for a vote.
• Member tokens contributing to claims assessment voting become “inactive” and cannot contribute to another claims assessment for 12 hours. This prevents posting a sufficiently high stake, submitting many fraudulent claims of total value well above the staked amount and then approving them all. The Advisory Board has time to step in and burn tokens before too many fraudulent claims are approved. In this case the members would benefit overall as the accretive benefit from the burned member tokens would outweigh the fraudulent claims cost.
• Calibrations of the incentive mechanisms need to be refined in testing.
Designing incentive structures resilient to game theoretic attacks is very challenging. The approach described has a basic incentive structure at its core and then overlays timing windows and human intervention to prevent more extreme scenarios.
The base calculation currency is APT as the pool will be APT dominated to start with. The ALT of each individual module is calculated in its currency (i.e APT or aBTC) and then converted to APT in the combining module. Focussing on module one to begin with, and assuming the product has a fixed sum assured ALTM1 is defined as follows:
ALTM1= √∑𝐶𝑜𝑟𝑟(𝑖,𝑗)∙𝐸𝑥𝑝(𝑖)∙𝐸𝑥𝑝(𝑗)𝑖,𝑗 Where;
Corr(i,j) is the correlation matrix of the individual pricing risk cells; Corr(i,j) = [ 1⋯𝑐𝑜𝑟𝑟(𝑗,𝑖) ⋮⋱⋮ 𝑐𝑜𝑟𝑟(𝑖,𝑗)⋯1 ]
And Exp(i) = Total probability-weighted exposure (or cover amount) in pricing risk cell i.
The correlation matrix may be very simple if independence between cells can be assumed in which case ALTM1 reduces to:
ALTM1= √∑𝐸𝑥𝑝(𝑖)𝑖
It is possible that each product module may have a different formulaic logic to get to an assumed 99.5% confidence capital requirement. In particular, this would be required with indemnity-based products rather than fixed cover amount values.
The next step is the currency module (fx) which takes the ALT’s of each module in a particular currency (k), compares that to the value actually held in the pool, Vj, and applies a currency shock of 50%, both up and down, and then chooses the maximum value. The sum of all these becomes ALTfx: ALTfx = k | (k ALTi – Vk ) / 50%| fxk to Where fxk to is the exchange rate to APTer.
The combining module then takes a similar approach to the ALTM1 calculation, treating each module as its own pricing risk cell and assuming a correlation between different modules: ALTTot=√∑𝐶𝑜𝑟𝑟(𝑙,𝑚)∙𝑀𝐶𝑅(𝑙)∙𝑀𝐶𝑅(𝑚)𝑙,𝑚
subject to a minimum value. Where, Corr(l,m) is the correlation matrix of the modules: Corr(l,m) = [ 1⋯𝑐𝑜𝑟𝑟(𝑙,𝑚) ⋮⋱⋮ 𝑐𝑜𝑟𝑟(𝑙,𝑚)⋯1 ]
A minimum ALT value will be set when the pool launches and the ALT value can never drop below this. The total ALT will need to be calculated regularly, probably at least once per day, as it is needed as a reference item for funding triggers. Operationally this will work as follows:
• Calculation will need to be performed off-chain, due to gas requirements, with the result being notarized on-chain.
• The capital model code will be open source and all inputs will be available on-chain (either directly or via oracles for currency exchange rates) or as part of the model itself.
• Correct running of the model will be verified on-chain.
• Updates to the model or input parameters will be handled via the governance process.
• There will be a specified block number on which calculations are made. This locks the data inputs to the calculation model and gives enough time for the model to be run off-chain.
• To begin with it is likely the ALT will be run in a trusted manner off-chain due to technical limitations. In the future trust minimizing options for complex computation will be investigated further with a strong intention to remove this reliance.
Last updated
