[REP] Argument against REP as a collateral type

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.

8 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

2 Likes

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.

Reporting fees are a percentage (small one) of open interest, which is in DAI. If there is 100 DAI in open interest and the reporting fee rate is 1%, then that means there is 1 DAI of reporting fees that will be collected (and 99 DAI will eventually be given to winners). If the value of DAI drops such that 1 DAI = 0.5 USD, then the reporting fee will still be 1 DAI. This means that reporters are now making 50% of what they were making, thus REP is worth 50% of what it was.

That makes sense. And security aside you might not even want e.g. a DAI/USD price feed because you’ve got to denominate REP value in something and DAI seems like the most natural choice. It’s still confusing me at some level that this should happen.

This is awful close to the definition of a economic capital… what kind of assets are there that aren’t yield producing that you think would be better than economic capital?

Commodities (or promises for a commodity).
Other currencies (that are actually used as currencies and stand a chance of having adoption) such as Monero, ZRX, Dash, Bitcoin.
Various derivative products of the above (e.g., DGX is an IOU for a commodity, W-BTC is an IOU for BTC, etc.)

It is worth noting that I’m not a huge fan of the “collateralize all the things” mentality that many others are. I think there are very few assets that would make a good Maker collateral and I’m generally OK with Ethereum dominating the collateral space, or even being the only collateral. This is because it is the only collateral that IMO makes sense and is trustless. All other options either require trust (e.g., DGX) or don’t make for good collateral (governance tokens, things whose value is based on future DAI yields, etc.).

IMO, using REP as a collateral for DAI would be like using T-Bonds as a collateral for USD. Gold is a great collateral for USD, T-Bonds as collateral make no sense. It reduces down to using USD as a collateral for USD.

Hi Micah.

Thx for sharing your knowledge! Do you agree that it is unlikely that REP goes to zero “almost instantly” once the forking state is activated? And hence if the REP price going to zero takes 60 days would that not leave more than enough time to liquidate REP cdps without deluting MKR? Or do you imagine other problems like low liquidity or something else to make the REP price go to zero faster than 60 days?

Forking is the most likely cause of REP going to 0. It would be expected to go to 0 over the course of the fork window, which is 60 days. At the end of the window, REP’s value will be 0 (and a new REP token will have value).

Other than the usual contract bug/hack, REP doesn’t have any other cases that will cause it to go to 0.

But you think the 60 day period is too short a period to liquidate cdps without likely diluting MKR? Or do you dislike REP as collateral because of the inconvenience/risk of loss to cdp owners?

My primary dislike of REP as collateral is that REP (v2, assuming DAI integration happens) is an asset that yields DAI. This means that REP can be modeled as future-DAI, which can be simplified to DAI. Thus, having REP as a collateral type for maker is similar to having DAI as a collateral type to Maker, which doesn’t make sense.

The 60 day window may be enough, but depending on the how much of total collateral is REP, it could cause a spike in DAI price as demand for DAI spikes during that 60 day window. Maker governance will need to take care to not curve fit the DSR and stability fee during this time, even though DAI may slip its peg.

2 Likes

Ok. thx for clarifying.

It is worth noting that Augur will be undergoing a major upgrade in the near future. The tentative plan is to use DAI as the denomination token for Augur v2 which means Augur v2 will launch after McDAI launches. This means that REP v2 cannot be used as a launch collateral type for McDAI because it won’t exist yet.

REP v1 could be used as a launch collateral type for McDAI, but it would be short lived since once Augur v2 launches, users are expected to migrate their REP from v1 to v2 (like Maker did a while back with MKR tokens). This means that REP v1 will become scarce, and should a fork in v2 happen REP v1 will become worthless.

2 Likes