Insurance Tiers

OLD GOV (LEGACY)
1

Would like to start a conversation around insurance tiers and why they might be useful going forward.

Why Have Different Insurance Tiers?

  • reduce risk to the Bancor protocol and BNT holders
  • increase the breadth of projects that can take advantage of Bancor’s v2.1 upgrade and hence opening up more potential flows of liquidity + volume into the protocol and the awareness boost that comes with it all
  • increasing the hype/prestige factor of being one of the higher tier insured assets on Bancor and the negotiation power boost that grants us with project that wants to gain access to the Bancor Protocol IL insurance. If everyone gets top tier insurance treatment, it’s hard to ask anything of these projects for even top tier insurance access let alone one of the lower insurance tiers.
  • Use the current v2.1 tech and transform it into a much more flexible and uniquely customizable form

Initially I can see three different tiers that seem necessary but this is certainly open to more given that it addresses a specific usecase:

THE THREE INSURANCE TIERS

Gold Tier Insurance (for vetted large/mid caps):
Essentially what we have now. It’s possible we can actually have a tier above this (less time needed to get full IL coverage perhaps in case things get competitive in this space) with some super reliable / high volume / not too volatile assets (WBTC) but that would need risk simulations.

Silver Tier Insurance (for vetted mid/small caps):
This insurance plan would be for projects that could potentially expose the protocol to high IL insurance coverage costs, and in a general sense these would be smaller caps which are prone to high non-correlated volatility and potentially move in different direction than BNT price thus leading to more IL risk.

The insurance plan here would be much less thorough than the gold one with things like:

  • Max capped protection at both on an individual level and potentially on a TKN based level before being cut off entirely

  • Longer time frame for IL insurance to kick in, with slower rise in coverage than 1% per day.

  • Swap fees generated by the TKN side are used first before tapping into any BNT minting to cover IL

There would be less pressure for the community to whitelist these projects through as the risks would be much less pronounced, and it could be a “starting point” that projects aiming to receive Gold Tier Insurance need to pass…a trial phase of sorts.

Bronze Tier Insurance (automated permissionless insurance for micro caps, shitcoins, and unknowns):
Looking at the volume data on DEXs it’s clear that new hot tokens generate a lot of volume, there’s a certain culture that’s developed around them and it’s not likely to go away anytime soon. There’s also quite a long-tail of smaller crypto projects that probably wouldn’t qualify for the above two tiers. So while in the current state none of the projects can join the Bancor protocol due to the risk factors associated with them, it’s certainly volume that would be nice to capture if we can fit into a workable model.

One of the important aspects of these projects is that they’re quite time sensitive in needing a place for liquidity and thus the above tiers and the time / coordination needed to get them through would likely dissuade these projects from even trying.

Ideally a standard set of requirements could be set, and the whole thing setup to be automated without needing anyone’s involvement given of course the requirements have been met. Such a smooth process to gain access to the v2.1 feature sets of single token exposure and IL (partial) insurance would be a great way to democratize access in a permissionless way.

The requirement would be something like locking a certain amount of both BNT and TKN to make v2.1 access work without putting any additional burden/risk on the rest of the protocol / BNT supply beyond what is supplied. How the mechanism would work to calculate when to halt / cut off the pool due to lack of collateral to cover IL insurance running out is above my IQ level. :slight_smile:

BONUS: DIY INSURANCE PLAN?

Brainstorming through that last bit about the bronze automated insurance gave me an idea that might stretch the idea further. It’s essentially the same concept requiring a pool creator to lock collateral to create a v2.1 pool, but there can be different dials they set to essentially make those collateral funds “go further” by adjusting the parameters of the insurance policy.

Examples of tunable attributes:

  • How many days staked need to pass until IL calculation tracking begins.
  • What the time thresholds are for the IL insurance protection rising in % coverage.
  • Max amount of coverage offered.
  • Duration of the IL insurance coverage.

Putting all these metrics in could spit out some different calculations on how much their initial collateral would provide coverage for given different external factors such as (which again could ideally be played with in calculator like fashion):

  • BNT and TKN price volatility and shock levels
  • Volume flows
  • Liquidity depth

In the end it would be something like Mario Maker but for creating your very own custom pool insurance policy. Silver Tier insurance policy makers could even apply for a certain amount of protocol granted co-investing to help stretch their own provided collateral even further (if they wanted something more custom than the standard Silver Tier package).

TLDR: Maximize liquidity/volume flowing through Bancor whilst minimizing risk to Bancor protocol and BNT holders through adding customizability to IL insurance parameters to better target and suit different projects and their IL insurance needs.

3 Likes
2

This is an important discussion topic. I think you have covered everything adequately. I have only a few points to add to the discussion. My intent is to clarify, rather than confuse the issue.

What is insurance on V2.1
Remember, insurance on V2.1 is insurance against impermanent loss due to a token’s value increasing while held in the pool. In this sense, the most volatile tokens are the ones that pose the greatest insurance risk. If ETH, renBTC/wBTC or any other of the highly trusted assets go parabolic, that’s an insurance risk. If you like, this is the ‘normal’ or ‘expected’ risk.

Exploit risk
This is the one that has been a topic of debate on the telegram group. The concern can be explained with a hypothetical scenario:

  1. A bad actor creates a useless/worthless erc20.
  2. A BIP is created to list the token on Bancor, and it is passed.
  3. The creator deposits the token via 1-sided liquidity, causing an equal amount of BNT to be minted.
  4. The creator then takes advatage of the system, swapping their pointless erc20 for BNT.
  5. The creator leaves with their BNT and the protocol is left with a pointless token.
    This exploit could occur in a number of different ways. This is an oversimplified version.

The problem is that the crypto community is not always the most prudent when assessing projects for their criminal intent. You don’t have to look too far to find someone who has invested in a scam and is sincerely defending it, often with fervor (e.g. HEX, any of the food meme tokens). Such people could potentially gain voting power in Bancor, and will likely create BIPs to list this type of high-risk asset. I want to point out that the person creating the BIP may have only good intentions, but that is beside the point.

When a BIP for a token whitelisting is created, more than likely, the community will vote down the garbage. But, there may be times where the status of a token is not so clear. This compounds the insurance problem. The tiered insurance schedule proposed by @coiner could help with these kinds of projects.

Take the current BIP2 as an example
BIP2 is for whitelisting CAP, a relatively unknown, low market-cap token. After looking into it, it seems like it could be a legitimate project with no discernable criminal intent. I submit that this is not sufficient for a Bancor whitelisting. However, similarly immature projects may be considered in the future, and will likely cause some division in the Bancor community. There ought to be an option to be inclusive of projects that we want to trust, but aren’t 100% of the way there.

I refer to @coiner’s discussion point regarding the Silver Tier insurance. To avoid exploits, we could extend the time required for the pool to reach coverage against impermanent losses. The longer the pool exists, and the longer we have to observe its behavior, the more it will earn our trust. There is another way this could be done.

No Minted BNT for questionable pools
Whitelisting could refer to a pool that has the highest level of trust, and which the Bancor community will allow an inflation risk. There could be a lower level - ‘graylisting’, that would require the pool maker to deposit both BNT and their token, as two, separate one-sided liquidities to the same pool. Combined with a longer insurance accumulation, the risk to BNT holders is significantly reduced, perhaps nullified.

TL;DR
Insurance in V2.1 is about token volatility, not trust. There may be a way to bring trust into the insurance model by refusing to whitelist, but offering a second option. This reply has a lot in common with the post by @coiner

1 Like
3

First of all, great job on this proposal, very detailed and thoughtful.

A few things that I want to add that might be interesting mid/long term -

  • Using fees above a certain level to cover insurance and not only in the mid-tier - for top pools, this could actually be significant and it’s especially important in deep pools as these pools also have the most IL to cover
  • Adding insurance cost - unlike IL, it’s deterministic so you can know exactly how much you’re gonna lose/make at the end of the day
1 Like
4

Hey, I am Michal and I work as a consultant on Bancor v2.1.

I will try to keep it short.

Tiered insurance:

I really like the idea of tiers for projects, my biggest concern is the market efficiency here.
Defi is highly dynamic, therefore whitelisting process optimization would help a lot.

On top of tiers, I would suggest creating a rating system that would eligible projects to be considered as gold, silver or other. That would significantly increase the project’s onboarding process and also address the project’s credibility problem.

Since we are able to predict the number of tokens to be minted, based on the historical data of the pool and liquidity providers behavior.

Considered data:

  • Volume
  • APY
  • Volatility
  • Standard deviation
  • Average time of LP in the pool
  • Token existence from genesis
  • Time since setting up a pool on Bancor
  • Fully diluted market capitalization
  • Circulating supply
  • Total supply
  • Historical price trend
  • On-chain transactions
  • Active addresses

If possible:

  • Time since the project is on a different platform such as Uniswap
  • Uniswap (or other) historical data
  • Independent providers rating (Messari, Binance)

Based on the above we would be able to evaluate:

  • average impermanent loss
  • average inflation
  • project input to the Bancor Ecosystem

The process:

  • Deploy the pool to the Bancor network.
  • The software starts monitoring the pool and based on the historical data
  • Software pulling on-chain data outside the pool (if possible) provides the rating
  • If the pool has a rating X or higher, the proposal for the status upgrade is automatically placed in the governance app.

The above would give users insights into numerical data about the pool, what inflation we can anticipate from it and how risky from for the Bancor Network and Liquidity providers the asset is.

The first rating system would be designed and pass in voting process. Rating updates would be governed and voted by community as well.

Also, since Defi space is overloaded with information, that would make the decision-making process much more efficient.

5

In regards to BNT lockup in order to increase the pool credibility or even set up a pool, I am concern that this idea might make the ecosystem plutocracy. Also, since the assets are volatile it might not be so easy to model.

Another obstacle here is a motivation for locking the tokens in a collateral contract.

I believe a wise path to choose would be smth like Aave has introduced:

  • Users would lock the tokens in the collateral contract to protect the risky assets from IL.
  • The IL would be covered from the collateral pool, instead of from minted BNTs.
  • That would allow the protocol to offset the risk to users that are willing to take the risk IL of pool with new, risky assets in exchange for high trading fees.
  • If LP has protection contract and has IL, the BNTs are covered from the insurance pool.
  • Users would have to evaluate by themselves if APY from the pool would be worth the risk of being liquidated (pro rata of course)

Thanks to the above, the new risky (bronze) assets could be listed, but the IL protection would not be provided by protocol but by the users.

6

A rating system to highlight the risk levels that the pool exposes to the system would be great to have.

With such a capability we can perhaps reduce the listing process to:

  1. BIP Proposal With Token Key Data: In line with BIP3 that is currently being discussed on Discord (to make it harder to sneak in risky projects like we nearly had with BIP2), provide data that would be relevant for governance to consider when voting on whether to whitelist a project. The application could require to include some of the advanced metrics mentioned by @MichalHerzyk .

  2. Vote To Enter Silver Tier: Armed with the knowledge/info provided above, vBNT holders can vote whether to include the project into a less risky tier to serve as testing phase for entering Gold tier.

  3. Automatic On-Chain Analysis For Gold Tier Promotion: Since the on-chain pool information is directly available and carries upmost importance (given basic requirements in prior steps are met) regarding IL risk exposure, the pool data can automatically be analyzed as suggested by Michael after a certain period of time and if certain criteria matched be upgraded to Gold tier IL insurance status.

  4. On-going risk monitoring: If there are potential exploitable loopholes or risks that arise for any given project, we can have certain factors that freeze any pool so that the risk can be mitigated and not lead to a catastrophic level inflation rate. Since these kind of events are extremely time sensitive, baking them into the protocol could be a good safeguard (if they’re not already there currently in the first place). Stock market has circuit breakers so pools taking a certain timeout in case irregularities are spotted might be beneficial and in line with the ethos of protecting LPs above all else.

  5. Potentially Halting Gold Tier Insurances: It’s possible that at some point certain pools will just not be worth it in terms of risk/reward and BNT holders might wish to discontinue it. Rating information regarding to how much inflation or IL costs it has incurred in relation to the volume/fees generated will be very useful for making these decisions.

BONUS: Perhaps setting up a nice rating system for the health/risk level of pools will also go towards building that completely permissionless DIY insurance product where users can step in as insurers and fund pool IL risks and in return be rewarded with the fees generated on those pool. As mentioned this would be more of a Aave/Nexus Mutual style insurance product so not sure how it fits into v2.1 approach. :thinking:

7

Thank you for thoughtful summary, I will focus on researching on relevant metrics for the pools then and drop it in the separate thread

8

Hey everyone, I have been working with the core dev team on a solution to the current bottleneck with bootstrapping initial liquidity in whitelisted pools.

The following discusses the current problem and proposes a solution that I can develop into a BIP.

The problem:

Currently there are two limits in place which are designed to prevent excessive minting of BNT.

The first limit is that the protocol can provide only 50% of the BNT liquidity in a pool. Meaning, if a pool has $1K worth of TKN and $1K worth of user-provided BNT, a TKN LP can provide only $1K TKN to the pool at that time. Doing so would cause the protocol to mint $1K BNT (i.e., 50% of the pool’s now $2K in BNT liquidity).

Given the current state of the pool, the TKN LP is restricted from providing any more TKN liquidity, since doing so would lead to the protocol minting more than 50% of the BNT liquidity. In this case, the TKN LP has to wait until a BNT LP comes along to open up space in the pool for additional TKN.

The second limit currently in place is that the protocol’s holdings cannot exceed 3,000,000 BNT worth of pool tokens per pool.

In the initial phase of a liquidity pool, limit #1 mentioned above has proven particularly problematic as it constrains the amount of TKN that can be provided. This leads to a situation in which pools can only be funded in small increments, preventing initial LPs from providing one lump sum of single-sided TKN - which is a common use-case for token projects and/or market makers.

Solution:

Establish a new tier of insurance (e.g., a “Platinum” tier) for the most strategic tokens, in which the protocol can fund 100% of the BNT liquidity up to a predefined amount.

Suggested rules:

  1. Protocol can mint up to 3,000,000 BNTs in order to match the TKN side of liquidity.
  2. Above the 3,000,000 BNT worth level of protocol-provided BNT liquidity, the pool is subject to the standard rules - i.e., the protocol can only provide 50% of the BNT liquidity.

Project whitelisting:

Due to an economic attack identified by the team, the Platinum status would be off limits to variable supply tokens, i.e., those tokens where the protocol can mint and burn supply. Such an attack would allow the third-party protocol to mint new tokens in order to extract protocol-minted BNT from the system.

Once one or two tokens have been tested, and the economic impact on BNT supply and price has been observed, governance can vote tokens into Platinum status using the regular whitelisting process.

Potential Next steps:

I have discussed with the core team potential next steps, which could be as follows:

  • Gain community consensus on the tiered model

  • Pass the BIP

  • Development by core team

  • The change is audited by a third-party smart contract auditor

  • Code is pushed live

  • Community votes on 1-2 strategic pools to provide Platinum status and observe the impact

  • If successful, expand Platinum status to additional pools

2 Likes
9

Thank you Michal and thank you team!

1 Like
10

Screenshot_20201029-120823_Discord
Screenshot_20201029-120823_Discord1440×1398 343 KB

11

Summary:

  1. Protocol can co-invest and mint up to 3,000,000 BNTs in order to match the TKN side of liquidity.
  2. Above the 3,000,000 BNT worth level of protocol-provided BNT liquidity, the pool is subject to the standard rules - i.e., the protocol can only provide 50% of the BNT liquidity.
  3. 5 Pools to be whitelisted as Platinum pools are subject to the further discussion and analysis of the Bancor core team

The above is subject to the current ongoing voting: 29.10.2020-01.11.2020

1 Like
12

Good information thanks for sharing
vmware

1 Like
13

Thank You Member Business Partner