[REP] Argument against REP as a collateral type

REP as a collateral type for Maker causes problems with REP’s security model and valuation because you have a “snake eating its tail” situation. REP’s value comes from future return on DAI, and DAI’s value comes from a guarantee that it can eventually be redeemed for 1 USD worth of REP (ignoring other collateral types for the moment). You can see that this creates a vicious feedback loop where if REP tanks sufficiently (e.g., causes the system to go slightly underwater) then the feedback cycle will result in both REP and DAI going to zero very rapidly. This is easy to visualize with REP as the only collateral type, and while having other collateral types will mitigate this risk, having REP and DAI values linked makes doing security analysis on REP much harder.

If Augur v2 ends up trading with ETH instead of DAI, then this isn’t a problem (though then REP is to correlated with ETH to be useful for Maker).

This problem is further complicated by the fact that REP is a token that is designed to fork, and when it does its value goes to zero almost instantly (a new token takes on its value).

Even if you ignore the first problem mentioned above, the forking issue is a pretty big problem for a collateral type. A good type of collateral is one with a low probability of going to zero suddenly (black swan event), but REP’s value goes to zero by design anytime a fork happens.

2 Likes

Can you provide some clarity or point us to some details about this?

If there is sufficient disagreement about the outcome of a market, the system will enter a forking state. This state lasts for 60 days and all REP MUST pick a child universe to migrate to. Any REP that has not picked a child universe at the end of the fork will be trapped in the parent universe forever, and the parent universe can never have new markets created in it and therefore there will never be any fees generated, thus REP in the parent universe becomes worthless.

New markets will be created in one of the two child universes, and presumably traders will use the universe that aligns with the reality they believe in. It is expected that one child universe will gain the lion’s share of future trading proceeds and the others will die off over time, thus one of the child universes will end up having a REP token that has value while the others will not.

Could this be solved using a Wrapped REP token that just follows an oracle price feed for REP? This way even if it does fork, you still have the price feed and status of the new REP token. The wrapper can do something fancy like verify the redeem-ability/convertibility of the token in the wrapper.

Are there time limits to converting old rep to new rep? Old rep is only worthless if the holder is unwilling to convert it to the new REP, so can’t we just assume that anyone holding oldrep can convert to newrep?

For Reference (about two months old) https://www.augur.net/blog/augur-v2/#use-it-or-lose-it

Relevant passages:

TL;DR: If a market in Augur v2 forks, you have 60 days to participate or you will lose all your REP.

… the V2 contracts will not allow migration to children universes after the 60 day window has ended. This is the most effective way to motivate participation in a fork, which is the crux of the Augur security model.

I’m not sure if this is solvable with a wrapped version of REP. It sounds like in the event of a fork, for ~60 days there will be three versions of REP, each with separate prices, with the original going to zero at the end of the 60 day period (what it does within those 60 days is more uncertain).

3 Likes

Thank you for the clarification! Geez, this really complicates things. Looking forward to hearing what other possible solutions to this there might be.

The forking process is a human decision point. Whoever holds the REP at that decision point must choose which path to follow by reading the details of a particular prediction market, researching the proper result of that prediction market, potentially discussing it with other humans, and then ultimately converting their REP to the universe that aligns best with reality as they perceive it.

If the REP token was just wrapped, then anyone whose REP was in such a contract would need to delegate this decision to whoever controls the wrapper’s choice. While you could create some system of governance for making this decision, doing so introduces governance risk over that decision as a malicious governance effectively can control all of the REP that is behind the wrapper.

1 Like

I think REP absolutely should be a collateral type.

Maker and Augur are probably the two most symbiotic projects in the crypto ecosystem!

There are two ways to solve this problem:

  1. have CDP be wrapped REP where the Maker governance system decides which fork all REP in CDPs goes to. As a CDP holder, if you don’t like this risk, you can simply close out your CDP before the fork occurs and REP has to be migrated and make your own decision. Anyone holding REP is aware of forking risk anyways, although I imagine some lazy people will be happy to just follow w/e Maker governance decides for any CDPs that weren’t closed pre-fork.

Doing it this way would get the best of both worlds for sophisticated users and for unsophisticated ones.

  1. Another option would be for Maker governance prior to a fork (it’s public / well known when this is with at least 60 days warning) to reduce the amount of REP CDP debt that can be taken out and/or raise rates on rep and eventually liquidate people who don’t withdraw just prior to a fork. Doing this there’s no “rep can go to 0” issue and none of these issues are relevant and it can be done with 0 modifications to the way Maker already works in MCD

IMO rep adds diversification to Maker as one of the few ERC20 collateral types where the creators cant unilaterally steal funds / update the contract arbitrarily. This would add very minimal complexity relative to the benefits of including REP as a collateral type imo, and in the case of option 2, basically no additional complexity.

6 Likes

The first method makes more sense than the later. Is there a possibility for the W-REP contract to be governed by an outside party or DAO? The obstacle in my mind is whether this is manageable for MKR governance.

I also have no sense for how often a fork might occur. If it’s very infrequent it might be feasible for MKR voters to manage this. But if it’s a fork every couple of months, this becomes inefficient for Maker governance to manage effectively.

Is it possible to create a W-REP contract that autoforks based on some “majority fork (minus REP locked in W-REP pool) wins after 58 days rule”?

I also have no sense for how often a fork might occur. If it’s very infrequent it might be feasible for MKR voters to manage this. But if it’s a fork every couple of months, this becomes inefficient for Maker governance to manage effectively.

Augur’s been live a year thus far and there have been 0 forks, so I think it’ll be something relatively infrequent. In fact the game theory is setup such that a fork is a threat, but in theory should never have to happen. It is something that should be considered as a possibility though, even though the chances of it occurring are very small.

And yeah, you could have a contract that does that, although leaving it up to maker governance since it’s such a rare occurrence may be better

1 Like

Thinking more on this today (due to discussion in Augur Discord). A good analogy for the first problem (snake eating its tail) would be if USD was backed by a basket of goods, and included in that basket were stocks that paid dividends in USD and were priced in USD. One can easily imagine a world where monetary policy allowed such stocks into the basket, and over time the basket ended up full of only stocks. At that point, you have a “fully backed” currency that isn’t actually backed by anything, since the assets that back it are all themselves just promises on future USD.

When you have a fully collateralized currency, it doesn’t make sense to use promises on future yield of that currency as collateral for the currency itself because you can end up in a situation where you really don’t have any actual collateral.

I think that Maker should try to avoid any asset as collateral that can be reduced to a promise of future DAI yields. It should also consider any asset that is a promise on future ETH yields to effectively share risk parameters with ETH.

1 Like

I share the intuition but I’m a little confused. Take, say, an algorithmic stablecoin that’s directly backed by promises of more of the same. You have a snake eating its tail. But if you back an asset with future yield that results from work, and the yield happens to be denominated in that asset, I think it ought not to be a problem? I don’t really know how Augur works, but I guess I’m saying that when the value of DAI goes down, the nominal DAI return for REP holders should increase.