Liquidatable: apply funding rate multiplier to TRV or price.

[mrice32]

Why

Project Evergreen.

Difficulty Score [1-10]

• 6: ~1 day

[nicholaspai]

On the perpetual contract PRD, @chrismaree brought up a really good point IMO about using the cToken design. For context, we proposed to “apply the funding” rate by changing the exchange rate at which the synthetic token is backed by its collateral token. However, the main point of the funding rate is to incentivize arbitrageurs to trade the price back to the peg.

As currently designed, the cToken’s funding rate tax is not “felt” as much by token holders and more by token sponsors. It relies a lot on sponsors changing the secondary market price of the synthetic, in response to the value of their debt changing.

On the other hand, aTokens, which change wallet balances, would implement funding rates that are “felt” by holders and therefore might be more readily arbitraged.

Question is, should we be re-visiting the cToken vs aToken debate?

[daywiss]

I am really interested in this debate, especially since chris seems very bullish on atoken design. How do you think it affects sponsor behavior? Also arent there some really bad tradeoffs for a tokens?

[hlambur]

I like this debate and I'm very supportive of @chrismaree's push here. However, I think the debate really is about perception between the two methods vs the actual economic reality.

My view is that aTokens and cTokens are economically equivalent. Chris (and Nick) are very helpfully pointing out that there is a difference between aTokens "giving" a token holder more tokens (which they can immediately sell) vs cTokens "saying" to a token holder that this token is "worth more" (but the price not immediately adjusting—or ever adjusting).

But is there a difference?

Assume that the funding rate is really positive (perp price is at a discount) and token holders are receiving a lot of "interest" which is designed to push the perp price upwards. In the aToken version if the price isn't adjusting upwards, a savvy participant would buy the aGOLD to earn this interest (in the form of more tokens). They wouldn't be "selling" there interest gains, they would be accumulating (and potential selling when it gets back to fair value). In the cGOLD version, wouldn't a savvy participant just do exactly the same thing? The savvy cGOLD buyer would buy the cGOLD token (and not sell) to earn this interest (in the form of more "valuable" tokens).

The traditional finance equivalent would be (i) pay the bond holder more interest by giving them more bonds vs (ii) pay the bond holder more interest by making their existing bonds worth more. A savvy bond holder in either example should buy more bonds and increase the price of the bond. If they do not buy more bonds to increase the price, you have to keep doing more of (i) or (ii) until they do.

To be very clear, this mechanism isn't guaranteed to work in practice! (In either the aToken or cToken styles). As we've seen from the Ampleforth rebasing (which is sort of like an aToken style funding rate), the AMPL price can swing wildly. If our perp does this is will look "broken". However the core difference here is that for AMPL it's collateralized by it's own self-minted collateral that people were speculating hard on. Our perp is collateralized by "real" things and is designed to track a real thing, so the payments should feel more "real". I genuinely think our perp design will work, but it's not guaranteed—we will be learning in prod.

Other point: I want us to support both versions—and I think we can. I think it should be relatively easy to write a simple contract that takes cGOLD and makes aGOLD (where you deposit cTokens into this contract and mint aTokens and have real-time transferability between aTokens and cTokens). If this cToken <> aToken contract design is possible, I think should also quell Chris's fear about cTokens (because conceptually if this convertibility is possible, I think it should mean the arb between these two designs is identical).

[nicholaspai]

First of all I am perhaps mis-attributing Chris' opinions, a lot of this skepticism comes from me. 😅. Great point about wrapping cTokens into aTokens via a helper contract, this might just be the answer we are looking for.

However, the difference I see between cTokens and aTokens is highlighted in the situation where the perp is at a discount (shorts pay longs):

In the aToken version if the price isn't adjusting upwards, a savvy participant would buy the aGOLD to earn this interest (in the form of more tokens).

In this situation, the holders are incentivized to push the secondary price of the perp higher by buying aTokens, earning interest as a "carry", and they can close out their arb by selling the funding rate payment once the aToken gets to fair value. But even if the secondary market does not correct back to fair value, the aToken holder has still earned their funding rate, right?

On the other hand, a cToken buyer must assume that the Market takes the funding-rate-adjusted price into account when making trades. Unlike the aToken which earns payments, the cToken buyer is at the whim of other market participants pushing the price back to fair value.

[mrice32]

In this situation, the holders are incentivized to push the secondary price of the perp higher by buying aTokens, earning interest as a "carry", and they can close out their arb by selling the funding rate payment once the aToken gets to fair value. But even if the secondary market does not correct back to fair value, the aToken holder has still earned their funding rate, right?

On the other hand, a cToken buyer must assume that the Market takes the funding-rate-adjusted price into account when making trades. Unlike the aToken which earns payments, the cToken buyer is at the whim of other market participants pushing the price back to fair value.

@nicholaspai I slightly disagree with this framing. All synthetic assets require arbitrageurs to push the token "back to fair value" for token holders to be able to get their money out. Unless we're only considering the situation where the uniswap pair is GOLD/uGOLD, arbitrageurs will always be responsible for pushing the price around because the token's fair value (that is indirectly incentivized in the same way the funding rate would be) will be fluctuating against the tokens it's trading against. In the cToken case, there is just another component of the price to consider. But arbitrageurs are always using some mechanism to price and determine "fair value" of ERC20 tokens -- an embedded interest rate is probably less complex than many of the other, more subjective pricing mechanisms they have to consider.

Furthermore, I think your analysis assumes a certain market structure where market makers would naturally keep the price the same when airdropped additional tokens as interest (the aToken case). That is true for typical 0x-style (or fiat) markets. But when you airdrop new tokens onto a uniswap market, I think that would cause the price of each token to decrease (because the balance would increase). This would mean if you are a token holder trying to monetize your carry, you would require an arbitrageur to do the same thing as the cToken case -- buy the token to correct the price.

However, I think yours and @chrismaree's skepticism is pointing to something real -- it's easier to conceptualize/price an aToken. It's almost as if an aToken price is a schelling point: 1 token == 1 ounce of gold or $1. Whereas a cToken would require an extra layer of computation to determine what the price should be. That extra layer of computation could cause real usability issues and market inefficiency.

I think the major disadvantage of aTokens is that there are certain contracts and markets where they just won't work -- balancer for example. I think they're also a bit more complex to build into the perp contract.

I think there are a few options we can consider:

• Use aToken-style tokens in the base perp contract. This is a bit more complex, but it makes the more intuitive structure the fundamental representation rather than a secondary representation. This means that the tokens may need to be converted to something else or may just not work in some DeFi contracts (like Balancer).
• Use cToken-style tokens in the base perp contract. This is a simpler perp implementation, it is usable in all DeFi contracts, and it follows all the standard ERC20 rules (no balance changes without transfers). However, its pricing is less intuitive.
• Use cToken-style tokens in the base perp contract, and create a WETH-style wrapper contract that accepts cTokens and creates aTokens using the on-chain cumulative funding rate multiplier to determine how to convert them. This combines the advantages of the two options above, but it does add conversion cost and friction. It could also cause some confusion.
• Similar to the third option, but vice-versa. The big disadvantage here is that the core perp implementation would be a bit more complex.

Thoughts?

[nicholaspai]

Whereas a cToken would require an extra layer of computation to determine what the price should be. That extra layer of computation could cause real usability issues and market inefficiency.

This is a really good framing of the problem, cTokens offload complexity to off-chain infrastructure. I think this won't be a problem when the perp secondary market is more mature.

Overall I think we should implement cToken-style as the base perp contract because its (1) simpler to implement, (2) plays nicely with external infrastructure, (3) we can wrap aTokens on top of it.

[Kevin-UMA]

@chrismaree shared these concerns with me yesterday in our 1 on 1 and it really made me think and occupied my brain a lot and made it go in circles. Lots of thoughts here, but I think I agree with Chris that what we're doing with this cToken-style structure may not help in achieving what funding rates do and that there is no real push or pain that drives people to do what we want with the price. I think there needs to be an arbitrage opportunity to incentivize people to push prices back to fair or a create and redeem type mechanism that allows people to realize the exact value we are trying to replicate. I think this cToken-style seems more like we are just inflating and deflating the supply, but with the amount of collateral backing it changing. cTokens work in Compound's case because you can actually redeem your cDai for Dai, but in our case we don't have that mechanism. So in our implementation of increasing or decreasing the sponsors debt it doesn't seem to really matter if you never have to pay that debt. I think there needs to be actual realizable economics going from longs to shorts or shorts to longs. Even with the aToken-style setup we are just inflating and deflating the supply and just changing the liquidity of each counterparty. If we are creating tokens and debt of our synthetic (which can trade off from fair value) it doesn't pressure people to act or replicate funding. This is in comparison to say actual collateral being paid from one counterparty to another. I had one whacky idea, but probably not doable. Is there any way to create fixings where we can set quarterly or monthly windows for sponsors or token holders to pay back debt or redeem for collateral at the fair value - much like our expiries. For example, a sponsor could elect to settle a trade with their ETH equivalent to the price of the underlying. This would be a way to arb and pull things back to fair. However, the problem is how to close out a long against it. If you had a last in first out system and converted the last long that would be cool. That would discourage people from buying ahead of a fixing as well if it's at a premium in this example and could force the price down naturally. It's kinda like ETF model of create and redeem to help things stay close to NAV, but we don't have the underlying assets... just collateral which doesn't really work....