Skip to content

Instantly share code, notes, and snippets.

@killerstorm
Last active September 7, 2018 11:01
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save killerstorm/f3f21ff0575e786de1cbc07f41c6e0fb to your computer and use it in GitHub Desktop.
Save killerstorm/f3f21ff0575e786de1cbc07f41c6e0fb to your computer and use it in GitHub Desktop.

Bancor vs Growth Tokens

About a year ago I described a concept which I called Growth Tokens (hereinafter GT). As I recently found out, Bancor is very similar to GT. In fact GT can be seen as a generalization of Bancor as it gives you more parameters to play with. Also Bancor and GT assign different interpretation to virtually the same mathematical formula, so it might be interesting to compare that.

Let's start with going through Bancor model. First, recall the basic formulat for price:

Price = Cost / Quantity

This can be used to calculate price within one transaction, but the formula also works when you aggregate results of multiple transactions:

Price = Total Cost / Total Quantity

Paritcularly, if there is a token crowdsale, we can calculate volume-weighted average price this way:

Price = Total Paid / Supply

Finally, if crowdsale is done using a smart contract, the paid amount becomes the contract's balance, thus we can write:

 Price = Balance / Supply                [1]

This is essentially Bancor's formula, except for an additional factor:

  Price = Balance / (Supply x CRR)    [2]

To understand how it works, consider CRR=1. In that case Bancor's formula is identical to the formula above, which is basically a formula for an "actual" price of a token. If we configure a smart contract to buy and sell tokens at that price, then we have a hard peg. E.g. imagine initial price is 2 ethers for 1 tokens, then this price will be maintained forever. This is not interesting.

To get more interesting results, we need to fudge the sale price by some amount, so that's what CRR factor is for. Bancor calls it "Constant Reserve Rate". For example, suppose we set CRR to 0.9, which means that created tokens are 90% backend by ether (or other backing tokens).

But since formula [1] can be understood as the actual, fair price of a token, then we can assign a different interpretation to Bancor formula: contract sells tokens at a price which is (1/CRR) higher than the actual price.

This kinda makes sense if you see the contract as a market maker: by selling tokens at a price slightly above the "current" price, it can make profit. That's how market makers work, and contract is simply an automatic market-maker. But who receives this profit?

To understand it better, we can switch to GT model. The formula is mathematically the same, but it assigns different names to the parameters:

Price = (1+fee) * Balance/Supply

The idea is the same: a token contract acts as a market maker and sells token at a price which is slightly(?) higher than "the actual price". However, this difference is interpreted as a fee, which is added to the balance, thus the previous token owners receive the market-making profit.

This is true for Bancor too: when somebody buys a token, all previous owners benefit from it, as a premium is added to contract's balance, and that increases token's price. So we have

  (1 + fee) = 1/CRR
   fee = 1/CRR - 1

So, basically, 90% constant reserve rate is same as 11.1% premium for buying tokens.

Contract buying tokens back from users is where Bancor protocol differs from GT. Bancor uses the same formula for selling and for buying. So Bancor smart token contract is buying and selling tokens at "artificially inflated price", making that price not-so-artificial. In GT, we use a different formula:

 Price = (1 - fee2) * Balance / Supply

Normally, fee2 > 0, which means that contract charges a fee from the seller and adds it to balance. So GT price grows when people sell tokens.

So that's the difference between Bancor and GT: Bancor-based token's price will go up when people buy it, but will fall down when people sell it, doing sort of a price discovery. GT price always goes up.

But nothing says that fee2 needs to be higher than 0, it's just an additional parameter. Thus we can easily emulate Bancor's behavior with GT by setting fee2 to:

 fee2 = 1 - 1/CRR

So in Bancor model, selling fee is negative. This makes it easy to understand how Bancor works: when somebody buys a token, it charges a premium and adds it to common pool, making price higher. But when somebody sells tokens, it takes an extra amount from the common pool and gives it to seller, thus decreasing the price.

GT model is more general than Bancor because it has two parameters instead of just one, and thus allows one to tweak the token for needs to a particular application.

For example, Bancor protocol is vulnerable to front-running. E.g. suppose Bob knows that Alice is about to buy a large sum of FooTokens from the contract. He can profit from this: he just needs to buy some sum of FooTokens from the contract and then sell immediately after Alice's transaction.

Thus he can force Alice to buy at higher price and pocket the difference. Miners can do this sort of a thing with zero risk and zero cost for themselves, as they can control the order of transactions, so they can just insert their buy and sell transactions around Alice's purchase order.

Thus miners can effectively "tax" all Bancor smart token purchases.

To fix this, we translate from Bancor model to GT model. E.g. suppose CRR=90%. In this case fee=11.1%, fee2=-11.1%. To solve the issue, we can make selling a bit lossy, e.g. setting fee2=-10% while keeping fee the same. This makes front-running less profitable, as you don't take as much from the balance as you put in.

As a side-effect of this, heavy back-and-forth trading will prop the token price up, which is kinda nice.

Another interesting case is setting fee2=0. In this case token price cannot go down, so token becomes effectively riskless. You have no "price discovery" (i.e. price going up and down) this way, but is price discovery really useful for speculative early-stage tokens? At that stage information is highly asymmetric, so real price discovery is not possible, only speculation. By setting fee2=0, you remove the risk -- it is still possible to profit by buying tokens early, but one can just get his money back if there is a problem with said token. I believe this model can actually solve problems with ICOs to some extent, but I'll cover it in more detail in a separate post.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment