The Token Underground 0x1: BZRX token — a smart move or a pre-programmed fail?

We are back with the next installment of the Token Underground. Bringing to the spotlight today a token model of BZRX token recently introduced by the bZx Team. This one grabbed our attention due to a number of reasons. First, it’s relatively fresh, and has some novel ideas, and — perhaps more surprisingly — was developed to integrate a token into some of a lending protocol business, while more bespoke decentralized lending projects like Dharma operate without any token whatsoever.In our pilot issue Token Underground 0x0 we outlined our approach to analyzing token design. It is based on stripping down the ecosystem to a set of elementary economic interactions. We strongly feel that a decentralized framework needs a token to perform one function only — to regulate access to some kind of a limited resource inside that framework. Hence, our blueprint for analysis looks like this:

Understand the system. Down to the smallest detail: why is the system built? who are the participants? how does the business model work?
Understand the goals. Think, if those goals are aligned with customer needs. Can achieving those goals facilitate the system usage, or enhance its performance?
Find economic limitations. In simple terms, what valuable resources are there in a system, and why are they valuable?
Link the achievement of goals with the the scenario of access to a limited resource.

Now, how about we follow this plan step-by-step to answer this one question: wtf is the BZRX token? Is it an efficient upgrade to a virtually useless token introduced in bZx protocol earlier, or just another buildup of aggravation that will eventually lead to the system fail? We’re about to find out.

STEP 1. UNDERSTAND THE SYSTEM.

Let’s unpack a few things first to set the background for our analysis. bZx project is a protocol that allows on-chain lending and borrowing specifically for margin trading. In simple terms, it is a technical solution to enable operation of a decentralized marketplace for lenders and borrowers built on top of 0x protocol. It is based on integration of relayers, DEXes, and a specific Oracle structure. This is how it works: the Lender and the Borrower place their orders via the Relayer, and once matched, the Borrower receives a margin loan. While these margin funds are being used, off-chain bounty-hunters are monitoring the solvency of a margin account. If there’s a risk of borrowed funds being lost (like, when the market moves against the Borrower’s margin position), bounty-hunters initiate position liquidation and subsequent refund to the Lender.

At a first glance, the bZx protocol isn’t much different from the existing decentralized lending protocols like, for instance, the bespoke Dharma. They both lend funds in decentralized environment, right? Well, at a closer look these two are inherently different. First off, t_he core product of bZx protocol is margin lending only,_ which essentially means that these funds cannot be withdrawn anyway, since they’re in a trading position. With Dharma, a loan is not confined to any specific purpose, meaning that once you received your tokens, you can dispose of them however you wish. This differentiating point is crucial, and there’s more: Dharma in general terms is a lending service that makes use of significant collateralization (and even overcollaterization) to secure loans, while bZx’s approach is rather a combination of partial collateralization and liquidation technique. The reason behind it is apparent: a margin loan is a loan that exceeds a trader’s deposit by design, often by multiple times. Therefore, there is no economic sense in offering fully-collateralized margin loans.

Finally, we can attribute the bZx protocol with features of a lending protocol where lenders provide tokens to borrowers to open margin positions, with lenders’ funds secured by the protocol and the Oracles system that starts liquidation of margin positions in case of a threat. Looks great. But the reality is that the BZRX Team is walking on thin ice, because using the protocol doesn’t appear to be secure for the Lender. Sh*t happens here, because the liquidation of a margin position happens not at the exchange in a vacuum of ideal liquidity and pink-pony market makers, but on the real, often low-liquidity trade market. Thus, there is a non-zero probability that the Lender will get back less money that he initially put in, as a result of the price slippage while executing the sell order. Doesn’t sound good already. However, bZx proposed a solution, and we are going to analyze its legitimacy.

STEP 2. UNDERSTAND THE GOALS.

Ultimately, the whole point of the bZx protocol is _to ensure trustless and secure interaction between lenders and borrowers focusing specifically on margin loans._This is the only use case of the protocol (so far). With this in mind, let’s consider the goals of each system participant:

The Borrower’s goal is to get a cheap margin loan.
The Lender’s goal is to provide a secured loan without being exposed to significant risk of error or loss of funds.
The Relayer’s goal is to receive a commission.
The bounty-hunters’ goal is to receive a reward.

It’s safe to say that the goals of system participants are met in general case, except for the Lenders, which has to do with the risk of the price slippage. Hence, what the bZx team proposed is basically a solution that implies creating some sort of insurance fund that will be accumulating certain percentage of interest rates earned by Lenders, and aimed to protect them. If the funds are lost during the liquidation procedure, the insurance fund automatically pays out a remittance to cover this loss.

Now that we have an insurance fund in the system, the stars align making this fund a big deal. If it operates successfully (which means that Σ[Fund_assets]-Σ[Claims_paid]>0 in the longer run), lenders will indeed feel protected from all sorts of risks, and enjoy lending using the protocol. If there are lenders, there will be borrowers, since margin trading is a popular service in general. The circle is closed, and the protocol lives happily ever after. Yet, this is where the story unfolds. Once the bZx team introduced an insurance fund as a crutch solution to the problem of ‘the Lender’s biggest fear’, they will now need to dance around with a tambourine to ensure this fund runs smoothly. This is where the effective governance of the insurance fund comes into play becoming absolutely essential for the overall system success. If this task is fulfilled , the fund will have sufficient liquidity to perform its functions. If not, it will run out of money with some of the lenders losing their capital, because the insurance mechanism didn’t work out properly. Will customers hold trust in the protocol now? Not likely.

STEP 3. FIND ECONOMIC LIMITATIONS (OR A LIMITED RESOURCE)

Okay, let’s recap. We found that the insurance fund is a critical system element necessary for the system’s effective operation. Now let’s identify the limited resource. There are actually three resources that are limited in this sort of system:

the right to govern the insurance fund policy
the capital stored in the insurance fund
the possibilities of relayers to accept and fulfill orders.

Other resources in this system are not limited, or limited by design of the underlying Ethereum protocol. That’s why access to these very resources was driving the token design introduced by the bZx team. Right on.

STEP 4. LINK THE ACHIEVEMENT OF GOALS TO THE SCENARIO OF ACCESS TO THE LIMITED RESOURCE

With these three resources in mind, we are now ready to demonstrate the logic behind the BZRX token economy design. The token was clearly as the access mechanics introduced to link the achievement of goals (i.e. effective management of the insurance fund) with the scenario of access to the limited resource. BZRX token has the following functions in the system:

1. Value transfer. BZRX token is the only way to pay out commissions charged by relayers inside the system.

2. Governance. Token holders can vote over insurance fund policy (fees and other variables), thus executing collective fund management.

3. The right to claim the part of assets from insurance fund corresponding to BZRX token holdings. This function was disabled by initial design, but token holders can still vote to enable it.

A simplified logic scheme for the BZRX system (we didn’t include oracles, bounty hunters and other miscellaneous) would look like this:

All the three functions are interconnected within the framework of general operational logic. Governance function is introduced as a mechanism for collective management of the insurance fund policy, while the right to claim the part of assets acts as an economic trigger to motivate token holders to be active and participate in the governance process. Obviously, without a prospective profit implied, barely anyone will undertake to do this. Accordingly, the team proposed the mechanics that will align effective governance with the profit for each of participants.

The idea is fairly simple. The main governance goal is to set up the right fee charged from the Lender’s profits. The “right fee” here means that this fee has to be high enough to fill up the insurance fund, but lower than the critical point where the Lenders lose interest in the protocol due to the profit drop. And we already know that if the lenders choose to leave the system, the protocol will die.

Turns out, there is no revenue whatsoever to be received from the governance either. Still, there is another way to motivate holders based on their long-term expectations. How about connecting token value with the total of fund’s capital by granting a right to redeem BZRX tokens for a portion of the insurance fund assets? Then, as a BZRX token holder, you will be motivated to participate in the governance process, because if you do this job well, the fund capital will increase, and so will the value of your holdings. This is a major driver for participation. Easy. Suddenly the idea of charging relayer commissions only in BZRX tokens became not as dull, as it looked in the very beginning. By performing their order-matching services, relayers will continually earn BZRX tokens and (maybe?) hold it. In this case, they will have the right “to claim the prize” earned by their activity. The system workers now become “shareholders.”

Schematic diagram of the value streams in the bZx Protocol

At this point we’d really like to dig deeper. Let’s throw in some formulas to illustrate. An essential condition for the successful operation of this system is:

Σ[Fund_assets]_-_Σ[Claims_paid]>0 in the longer run

If we are talking about incentivizing participants in the protocol governance, this equation has to be changed:

Σ[Fund_assets]_-_Σ[Claims_paid]→max in the longer run

If the fund is not going to grow over time, the motivation to participate in the protocol governance is lost. But, can a fund be ever-growing really? On the one hand, if the protocol expands, the loan volume will keep growing, with fees collected from the profit of lenders resulting in increase of the fund capital. On the other hand, if there are more lenders and higher loan volumes, there will be more instances of “price slippage”, and therefore, more fund capital will be used to cover up these losses. Theoretically, this dependence (volume of fund capital vs. time) can look like this:

The possible dependence (Fund_volume vs time) curve

This works on paper. Let’s see, what the real consequences of token design for the system could be.

The right to redeem BZRX tokens for a portion of the insurance fund assets leads to bonding of the bottom price of BZRX according to this equation :

Value of BZRX = [1/BZRX_Total]×Fund_capital

Each token is backed by assets from the insurance fund capital. It looks like a cool mechanism to stabilize token price and a great incentive for token holders, as the token is obviously priced at the lowest. Nobody will be selling tokens cheaper than the amount of assets that can be released from the insurance fund in exchange for one BZRX token. Now, let’s suppose that one day there are a lot of assets allocated to the fund valued at X ETH. A token holder redeems his Y BZRX tokens (corresponding to 1% of the fund volume, for instance). Now, fund composition is 0.99X+0.01BZRX, where the ex-token holder received 0.01X ETH. This doesn’t look particularly good, because the next token holder who’s coming to redeem his tokens will receive a back payment that will be partially in BZRX! Let us explain: if the fund asset composition looks like 0.7X+0.3BZRX prior to the redeeming process, the holder will receive 70% back in liquid assets, and 30% in BZRX. Doesn’t seem that exciting, considering that you might wanna get some ETH or some other asset out of the system. Now, you have no other choice than proceeding to the exchange and selling the rest of BZRX (30%). This example proves that the redeeming process doesn’t work properly.

Yet, the team mentioned that the fund portfolio can be rebalanced (as we’ve understood correctly), which means that some of the fund’s assets can be traded to ETH on demand, and this can be applied to the BZRX tokens too. Still, this doesn’t solve the existing problem, and the pressure of the selling is still there. Both cases result in selling BZRX tokens on the open market executed by a user or by fund governors.

There is another weak point of the overall model that is due to the the fact that the token doesn’t have any intrinsic value. Its value is correlated only with the external factor — a possibility to redeem tokens for a portion of the insurance fund assets. Therefore, the profit that can be estimated by a token holder is the only difference between the initial volume of the insurance fund (at the moment when BZRX tokens are purchased) and the volume at the moment of redeeming:

Profit per holding one BZRX token = [1/BZRX_total]×(Fund_Assets_Currently — Fund_Assets_Initially)

So, there are two ways of rational behavior in this situation for a holder: to hold tokens with a view to redeem them at some point in the future, or to hold tokens aiming to sell them in future, when the price will increase due to the increased volume of the insurance fund. Note that for larger amounts of tokens it appears to be more rational to use the redeem function, as there will be no price slippage, and you won’t need to wait for the appearance of buy orders at the exchange, so you can do that nice and easy.

Now, very important. If a token had a simple function that allows to make profit just from holding and (of course) participating in the governance process, the motivation to redeem would be significantly lower. The method of evaluating the token value would also change: in this case, its value would be connected not only with the volume of assets in the insurance fund, but also with the cash flow that is remitted to the holder’s address on a regular basis. It resembles shares in some way (from economic, not legal sense) with dividend flow that can be valued based on theory of discounted cash flows.

CONCLUSION AND IDEAS ON HOW TO IMPROVE THE TOKEN DESIGN

The idea that a margin lending service needs an insurance fund for mitigating associated risks is not bad at all. However, limiting the functions of a token (and, therefore, economic motivation of the agents) to the right to redeem the BZRX tokens is a big mistake. And the procedure of redeeming doesn’t look feasible either. We found that there are at least two major drawbacks to this model.

Death spiral of redeeming.Redeeming BZRX to receive the insurance fund assets leads to partial substitution of the fund portfolio by BZRX tokens. We refer to the “0.7X+0.3BZRX” problem here. The consequences of this are quite dangerous both for the token price and the system itself. Token holders will not be able to fully enjoy their right to redeem, as they will be able to redeem partially in BZRX only. Thus, they will have to sell the rest of their BZRX on the exchange. The larger share of the fund’s portfolio being replaced leads to pushing the seller to exchanges decreasing the user’s trust on top of that. Token holders were promised the right to exchange the tokens for liquid assets, but that’s not what they got in the end. This problem is a great negative feedback loop, as every redeem of BZRX tokens results in the increase in the share of fund remittances in BZRX, which ultimately leads to the pressure to sell out on exchanges. A vicious cycle — and the drop in the token price — is now at play.
Lack of intrinsic value.

As we’ve outlined earlier, the token model provides only one mechanism of capturing BZRX token value: redeeming the right for liquid assets of the insurance fund. If there was no redeeming, the token would be useless, as hardly anyone is interested in participating in the governance without getting any profit out of it (at least in the longer run). The economic motivation to participate in some sort of “consensus” is an essential for any crypto network, since Bitcoin’s inception. Thus, the lack of intrinsic value of the token paired with raw and dangerous redeem procedure obviously leads to the fail of this economic framework. Such system cannot work autonomously. This, however, doesn’t necessarily mean that it’s absolutely useless, as it still has a chance to be feasible, provided there are other ‘crutches’ like huge buy walls, or market making.

Is there anything to be done to improve the BZRX token model and make it more solid?

First off, it is critical to add the possibility for token holders to receive the cash flow. Of course, this cash flow should be allocated only in case of active participation in the governance process. The simplest way to do so is to distribute the part of a fee used for filling up the insurance fund among the active governance participants. This will provide a fundamental basis for the token value.
Another idea is to change the procedure of redeeming. The main problem is that during continuous redeeming the share of BZRX tokens in asset structure is increasing. This issue should be solved, as it leads to all the other negative consequences. We propose to implement the “cash and burn” mechanics, where redeemed tokens are burned. It solves the problem with “BZRX substitution” increasing the value of remaining tokens with every act of redeeming. If tokens work as a cash flow source, there will be even less motivation to redeem them.

Implementation of these ideas will solve the above-mentioned problems without affecting general positive effects, highlighted by the team previously. These include backing of the token price by assets of the insurance fund, as well as extra rewards to relayers for their work in cashflow generated by BZRX collected as fees. So, relayers will receive not only “one-time prize” that they claim by redeeming tokens, but also continuous rewards for their work.

Finally, let’s calculate a possible size of the insurance fund. Suppose that this margin lending protocol is successful, let’s estimate it yearly turnover as ETH 10,000,000. We’re assuming that the annual interest rate is 10% and the term of each loan is one month. Then, the profit collected by lenders is (10,000,000/12)*0.1=83,333 ETH. If the fee is 20%, the fund will collect 16,666 ETH over a year’s period assuming that there are no claims from lenders. Doesn’t look like a particularly profitable endeavour.

The bottom line?

Kudos to the BZRX Team for coming up with the idea of an insurance fund.
We got two aftermath questions to the token model creators: what usage volumes do you guys estimate for the system? Is there any financial modeling made? We are keen to engage in discussion to understand the system logic better.

Disclaimer: We will be featuring the projects based on our choice only stemming from the relevance of their token design, and we promise that there will be no bullshit whatsoever. If you’d love to contribute in any way, please reach out to [email protected].