If you are like me you love Chipotle and you also read fine print for fun. The fine print of this coupon acknowledges something obvious in a mildly comical way.

“Cash value 1/100th of one cent, which is pretty much nothing,” huh? Ok chips and guac are a lot more than 1/100th of one cent they were $3.25 last time I checked. NPR correspondent Kenny Malone explains this strange coupon vernacular in the latest episode of the Planet Money podcast:

MALONE: That’s right. So back when these programs were popular, there was some controversy. There wasn’t, like, a lot of transparency around who actually benefited and whether consumers were sort of being scammed. And so a number of different state legislatures passed laws that said, OK, fine. If you want to do the program, you need to put, like, some nominal cash value on these stamps so that, like, if I don’t really want to go buy a toaster, I can use those stamps and cash them in for money … because these laws are on the books, it’s just easier to put that nominal cash value on the coupon than to sort of fight the laws.

A coupon is like a promotion specific currency! Seems like an easy way to get out of honoring a coupon thou. Imagine showing up at your local Chipotle and upon ordering a burrito you present the coupon. You are told that they are running low on guacamole however, they are still more than happy to honor the “cash value” of your coupon. After you pay for your burrito they promptly hand you a penny and tell you to “keep the change.” (ಠ_ಠ; are you kidding me?)

As insulting as that sounds this is exactly how a Bancor contract can treat people when it runs low on reserves. If we don’t understand how the concept of weight works in the Bancor formula, then any insurance architecture we create has the potential of shortchanging policyholders in like manner.

Lets review before getting ahead of ourselves

The terminology I’ll be using here comes from my earlier posts describing the Bancor protocol, so please refer back to post 1 and post 2 (formula specific terminology) if you get lost. I previously mentioned that the concept of weight given by the Bancor formula can be explained as different levels of solvency a Bancor contract can have. Let’s look again at the formula.

The point of using Bancor is to be able to use a relatively small pool of reserve currency to provide liquidity to a much larger pool of community currency. The weight value is given as a percentage, which means it is a number between 0.01 and 1. The weight value remains static but the flow of tokens into and out of the contract is dynamic.

The illustration above makes clear that tokens sent to the BXC do two things:

Delete tokens within the BXC

Allow reserves to leave the BXC

What changes over time is the conversion rate between the local currency and the reserve currency. Let’s plug in some simple numbers to remind us how this works:

The rate of exchange between ETH and local currency is initially 1:1.

However, the next person who tries to convert their tokens into ETH realizes that the rate isn’t 1:1 any longer because 99 / (999 * .1) = 0.9909. Fractional liquidity comes at a cost and this cost is a lack of fair treatment for all attempts to exchange tokens for reserve currency. A fractional reserve escrow can guarantee the right to withdraw funds but cannot guarantee the exchange rate between tokens and reserve currency. This allows the exchange rate to gradually decay over time as solvency decreases. Bancor fractional reserve escrows have gradual reductions in solvency but never become completely insolvent.

Insurance architecture using Bancor has to maintain the same exchange rate because it is expected to pay all claims fairly. Practically, the only way to do this is to divide claims up into incremental daily payments. Incremental payments allow us to pay out claims over the course of several weeks. We want reserves to exit the BXC as claim payments gradually, allowing us to add back premiums to the BXC as reserves. By making daily corrections in the addition of reserves we can maintain the same exchange rate. If you want this explained without the use of formulas this blog post is helpful.

Side note: When using Bancor for insurance architecture our contracts primarily function is to convert tokens to reserves in a one way flow. When using Bancor for community currency architecture Bancor anticipates a two way flow between tokens and reserves. This is why people that are familiar only with traditional Bancor architecture may be unfamiliar with how Bancor is used by fractional reserve escrows. Later we will illustrate an example of governance in which these same contracts are used and policyholders add reserves to the BXC. But in general, the BXC functions to pay claims when policy holders send CA-tokens to the BXC. Most transactions sent by policyholders to the BXC therefore pull reserves out of the BXC.

Solvency is how we buy people time in a crisis

But how much premiums are we expected to need to add per day in order to maintain a constant exchange rate? How quickly could rates change? What if we can’t add premiums quickly enough to maintain the same rate? What if in a crisis we run out of premiums? In the previous blog post I stated “If a system is gradually becoming insolvent policyholders need adequate time to switch providers to avoid a lapse in coverage.” Our weight determines our solvency ratio. Our solvency determines the amount of time policyholders have to adjust to higher than expected numbers of outstanding claims. We need enough solvency to provide policyholders the adequate time to make decisions. This is how we reduce the potential for financial loss in a crisis.

Taken from the Bancor whitepaper:

Lower Volatility — A Smart Token™ with a 10% Weight (for example) is comparable to an exchange with 10% of the entire supply of a token in its order-book at all times, forming substantial market depth. In a typical crypto-exchange, the share of the supply in the market depth at any given moment is well below 1%. The higher the Weight, the lower the Smart Token’s™ price volatility.

Bancor is suggesting that a 10% weight would be sufficient liquidity to minimize price volatility relative to the average market depth found on an exchange. Would a weight of 10% be sufficient liquidity if Bancor was used in insurance architecture?

Returning to the Chipotle example we have a demonstration of how a coupon can have nominal value upon conversion to currency. There is an equivalent scenario with regard to insurance architecture using Bancor. The below chart represents a weight of 10%. The chart gives us a sense as to how quickly claims would be underpaid if we took no corrective action to inject premiums as reserves.

% Tokens Used: The total value of all tokens in the system represent the maximum value of all claims that could possibly be opened by all policyholders.

The total value of all tokens in the system represent the maximum value of all claims that could possibly be opened by all policyholders. % Claim Paid: Taking into account a variable exchange rate as tokens are converted to reserves a claim payment would diminish as more reserves leave the BXC.

To put these numbers into context we would need data. We would need to know what the historical ratio of the number of open insurance claims in a given period, relative to the number of total policies. We would also need to know the average value of a claim relative to the maximum coverage provided by the average policy. But even without the context, this chart makes it clear that with a weight of 10% there isn’t much time before claims are underpaid by a significant amount.

For the sake of simplicity lets assume that there are 100 policy holders. The opening of one claim represents a use of 1% of the total claim award tokens which could be used to process a claim. Claim award tokens represent outstanding obligations, entitling policyholders to withdraw a claim payment from the BXC. Please look at the chart again and associate the left column with the number of policyholders entitled to a claim payment and the right column with the payment they should expect to receive. If the policy does not use incremental payments then it would be paying claims in one lump sum. In which case our first claim is underpaid by approximately 4%. Our next claim is underpaid by more than 10% and the decline in claim payments relative to claim awards continues to worsen. After 7 claims the 8th claimant would find that their claim is underpaid by more than 50%.

The takeaway

Given a weight of 10% in the event that a large number of policyholders decide to open claims in a short period of time rates could change very quickly. A weight of 10% in insurance architecture requires that premiums are promptly added to the BXC in response to claims. Higher weights result in greater solvency meaning more time to respond to open claims. This protects policyholders from a sudden change in the exchange rate between tokens and reserve currency. In a perfect world every attempt to convert 1 claim award token would produce a claim payment of 1 ETH.

Our job is to create insurance architecture which can accomplish this without being full reserve. If a large number of claims are opened simultaneously this may not be true. The greater the solvency the more time individual policyholders have to respond to sudden increases in the number of open claims. Greater solvency also provides more of a guarantee that in a crisis claims will be paid in full. How much time we provide to policyholders is determined by our models for risk. How much solvency is needed depends on how much risk our models predict is possible. The main concept I want you to walk away from this blog post is that use of the Bancor formula in insurance architecture makes an insurer’s risk model explicit and transparent.

The smart contracts which pay claims in the future are on the blockchain. These contracts are being governed by code that looks similar to what we see in Bancor’s architecture. In the future people don’t shop around for insurance based merely upon brands and customer ratings. A newcomer can enter the scene and have a better model for managing risk and lowering premiums. Instead of wasting advertising revenue to build their brand they could instead use that money to provide better coverage to policyholders. The proof of how a company would treat policyholders in the future would be in the smart contract code. The code would make explicit what a provider’s model for risk really is and how much solvency they really have to pay claims. And that is the entire point of why anyone would ever want to use blockchain technology to provide insurance coverage.

Next up: