Augur Migration Proposal

Proposal for Augur v2 Upgrade Process for Compound:

Proposal Part 1:

Around V2 launch:

    - Prohibit new supply and borrow of rep v1

Proposal Part 2:

10 weeks prior to earliest fork date:

    - Set REPv1 collateral factor to 0% (going down 10% every 2 weeks until it’s at 0, e.g. 40-30-20-10-0). Encourage people with v1 to convert to v2.
    - If any REPv1 loans are left, use a high rate to liquidate the position, e.g. 10% interest a day or something
    - Assuming some exchanges have listed it and/or dexes have v2 with sufficient liquidity, add v2 to compound with same collateral rules as v1 with a new cREP contract

2 weeks prior to potential fork date:

    - Upgrade any REPv1 in the reserve to REPv2

The thinking behind this is we can keep it fairly simple (to just two proposals). When v2 comes out it no longer makes sense to be able to do new supplies or borrowing of rep, everyone else should be given time to migrate. There are four months until a fork can potentially happen after REPv2 launches (July 28), so there’s time. After the first proposal is enacted and it’s been a few weeks to see how v2 plays out, I then propose a part 2 which reduces how much people can borrow against rep over time (so as to not cause a bunch of cascading liquidations). Assuming there’s oracles with price feeds for v2 at this point and some of the major exchanges have migrated over, I think it then makes sense to in parallel add v2 with the same rules as v1 to encourage people to easily migrate over from v1 to v2 rep and then resupply or borrow from compound.

Since REP has the ability to fork or split into two assets (rare, has never happened and should never happen but is good to prepare), we should go ahead and address that too. The cREPv2 contract could allow compound governance to vote to migrate REP in the event of a fork. But I don’t think it should for a couple reasons: when a fork happens there’s different REP tokens (different contract addresses too) for each universe of the fork, so to migrate, COMP governance would need to choose the winning fork (before it is known what the winning one is), migrate the cREP contract to it, and hope that exchanges list it immediately post fork (otherwise there’s no price feed to go off of for Compound).

Instead what makes more sense is if a fork did happen in v2, there’s always at least 60 days of warning, so we could follow a similar process to the one above: prohibit new supply and borrow, gradually lower the collateral factor, liquidate existing positions if no one pays them back by the end of the 60 days, and upgrade any remaining REP in the reserve (or just convert it to dai or something to be even easier).

Note: continuing the convo from the prior forum here, borrowed a couple ideas from there re collateral factor etc!

Edit: forgot to add fork date info! After launch it takes 8 weeks for a market to potentially trigger a fork at the earliest, and then 60 days for a fork to actually occur.

5 Likes

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.

2 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?
1 Like

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).

2 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
2 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.

1 Like

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

2 Likes

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

2 Likes

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

_setMintPaused(cREP, true)

and

_setBorrowPaused(cREP, true)
1 Like

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

2 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.

1 Like

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.

2 Likes

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

5 Likes

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

2 Likes