Augur Migration Proposal

my concern is that maybe we should do this faster cause when v2 launches the liquidity of REP(v1) will decreases significantly as users start to migrate and liquidating or repaying a position might become difficult.

3 Likes

Joey, this makes a lot of sense - thanks for taking the time to organize the process.

  • Since Compound Governance takes 5 days, a proposal to pause new supply/borrowing of REPv1 should occur soon
  • Do you think that the community could deploy a “vanilla” REPv2 cToken?
  • Could the community update the price feed to reference REPv2 once is begins/trading? Is there any clear difference in value between the different token addresses, or anything to pay attention to?
2 Likes

Point above about liquidating v1 rep borrows makes sense. Going to edit the proposal slightly to mitigate that issue.

  • Since Compound Governance takes 5 days, a proposal to pause new supply/borrowing of REPv1 should occur soon

Makes sense

  • Do you think that the community could deploy a “vanilla” REPv2 cToken?

Yes I think so

  • Could the community update the price feed to reference REPv2 once is begins/trading? Is there any clear difference in value between the different token addresses, or anything to pay attention to?

Yep! The main thing to pay attention to is forking, which is basically the same as the process I outlined above so it’s not anything additional on top of that (basically, the community in theory may have to go through this process again).

3 Likes

++ on the proposal and comments, adding some dates:

Two relevant periods here, the slow dispute process (8 weeks) and the forking period (60 days). They work out to roughly equal timeframes, however the slow dispute process runs in weekly fee window intervals and the forking period is defined by a fixed number of days. Augur v2 introduces fast disputing where someone can post a bond to accelerate the dispute process up to 8 weeks before a fork, then Augur turns on the slow weekly dispute process for the remainder of the time until the forking period begins.

Assuming a successful deployment of Augur v2 on July 28th, 2020, in theory someone could create a market with a near immediate resolution date, post a sufficient REP bond meeting the requirements of the slow dispute process and trigger it to begin in the upcoming weekly fee window.

The cadence of the weekly fee window is inherited from Augur v1, so the earliest date in which the slow 8-week dispute process can begin is July 30th, 2020 at 00:00 UTC. This would then result in the earliest possible forking period beginning on September 24th, 2020 (+8 weeks), concluding on November 23rd, 2020 (+60 days).

Earliest possible event dates:

  • Slow Dispute Start Date: July 30th, 2020
  • Fork Start Date: September 24th, 2020
  • Fork Conclusion Date: November 23rd, 2020

So to Joeys proposal:

  • 10 weeks prior to earliest fork date: September 14th, 2020
  • 2 weeks prior to earliest fork date: November 9th, 2020
3 Likes

I’d like to see borrows/supplies for cREP paused ASAP because of potential major liquidity changes that will occur when Augur 2 comes out. Additionally, I think we should deploy a cREPv2 as soon as market liquidity of the new asset is high enough. I don’t know if it can use vanilla ERC-20; haven’t looked into the code yet.

2 Likes

Yeah it’s a (spec compatible Zeppelin lib) erc20 token

3 Likes

Additionally when disabling supply/borrow, we could remove REP from the COMP rewards and set reserve factor to 100%
What do you think ?

3 Likes

BTW, the relevant Comptroller functions to do - Prohibit new supply and borrow of rep v1 are:

_setMintPaused(cREP, true)

and

_setBorrowPaused(cREP, true)
2 Likes

That sounds fine / makes sense to me re the reserve factor / COMP. Doesn’t let me edit OP anymore but would do it as part of proposal part 1 imo

3 Likes

Sooner this process gets started the better. Theoretically, if a lot of REP is migrated to v2 soon after launch, it could lead to liquidity pressure for REPv1 which may make it tougher to deleverage (the migration is only 1 way as far as I know). Luckily there’s not much REP borrow outstanding.

2 Likes

thats just one side you see, cause there is like 6M$~ stablecoins that are borrowed with REP collateral,
that is also my only “fear” that the liquidity of REP (v1) will be significantly lower when users will start migrate.

3 Likes

First proposal is live : https://compound.finance/governance/proposals/17

6 Likes

@blck I believe it is time for a 10% collateral factor drop. DEX Rep liquidity is getting shallow.

3 Likes

Just wanted to bump this thread, REP migration has been going on for several months and we should consider reducing the collateral factor to encourage migration to REP v2.

2 Likes

Definitely, good call @monet-supply

1 Like

Augur is now safe to completely deprecate; cREP has shrunk to less than $150k, and is no longer an important collateral market.

There are no practical levers to force repayment of the remaining REPv1 borrows; but disabling the asset as collateral is a logical next step.

3 Likes

We can always adjust the interest rate model if we want to force borrowers to close out :slight_smile:

Eg. make the interest rate 100% APR regardless of utilization.

1 Like

Hi @joeykrug @rleshner, is there any plan to migrate existing $43K worth REP V1 legacy token to the V2 token given the V2 fork seems to be stable and successful right now?

I noticed @joeykrug mentioned in his initial proposal

  • Upgrade any REPv1 in the reserve to REPv2

so I am curious about the timeline to execute that step.

The reason I am asking is personally I still have some REP V1 token in the pool and the ETH GAS fee is discounting me to withdraw and migrate on my own, which I believe some of the LPs in this market are keeping their small but still meaningful tokens in Compound.

Thanks ahead for your attention and response!

2 Likes

@leo there is no ability for the protocol to migrate V1 to V2 automatically; you’ll need to withdraw your tokens and migrate them on your own–ideally when gas prices are inexpensive.

1 Like

Thanks for your reply Robert! I was thinking the Compound contract owns the underlying REV V1 token so technically it might be possible to perform a migration function call within the Compound contract. Though I am not savvy on the Compound code implementation so I take your words for the feasibility.

I’ll go ahead to plan that withdraw & migration on my own. Thanks again and stay safe!