First Zero DLLR Risk meeting tonight!

[capitalist42]

[Phrygian12]

I remember mentioning this while talking about bumping fee to 2.5%.

Due to the 500% increase since the 0.5% interest rate “Borrowing fee,” i think its needed more than ever. I cant justify using zero, in its state. Been waiting for over a year to use it.

Maybe like a 0.5% discount for VP of 10k, 1% discount for 100k, 2% discount for 1milVP?

I realize its hard to make a system like this because the incentive will change based on SOV price. Maybe some technical way to use Oracles to adjust it based on SOV?

Im very non technical about the development of it, so forgive me if I sound dumb.

Could incentivize SOV staking too.

[one_digit]

I hope some of you who are participating here will be able to join the meeting at 4 PM UTC today in the Community Voice room on discord.

In preparation for the meeting, I’m going to post an analysis I did last week regarding the redemption fee.

TL;DR Does a higher redemption fee slow down redemptions? The answer is no, at least not directly. It does have an indirect effect of slowing off-ramp-intended borrowing.

Consider the actual peg level to be 100%-redemption fee %.

First, it’s possible that as the price of DLLR falls below 100% but above the peg level, there will be some users who decide to hold or buy in hopes of the price recovering at some point. This kind of demand is likely to grow as the price falls. However, in a new project with a stablecoin with little track record, I would imagine the increase in demand above the peg level to be pretty small.

Second, the price must fall below the peg level for redemptions to be profitable. Therefore, in an ecosystem where supply > demand, there will be selling pressure until the price falls below the peg level. This means the AMM price of RBTC/DLLR will rise until the implied DLLR price is below the peg level on the AMM because the AMM is essentially the only liquid way to off-ramp value.

Third, in the process of the price falling to the peg level, a specific amount of DLLR is converted to RBTC and presumably off-ramped. To bring the price back in line with the nominal price, the same amount of DLLR must be purchased with RBTC, assuming no change in AMM liquidity.

Fourth, once the AMM price hits the peg level, there is no force available to bring it back to the nominal price other than speculation on DLLR. DLLR borrowers have off-ramped RBTC, and there is no other net source of upward price pressure on DLLR as long as the market price remains the same. That is, a certain amount of price deviation in the AMM will absorb a specific amount of off-ramping. Once that amount of off-ramping occurs, the price remains fixed at the offset level.

Fifth, once the price falls below the peg level, redemptions will occur to keep the price at the peg level through arbitrage. At that point, redemptions must exactly equal off-ramping via the AMM to maintain the existing offset, which is the profit break-even point.

The bottom line is that a higher redemption fee only allows for a fixed extra amount of off-ramping and therefore a fixed price deviation. It does not create further direct incentives to slow redemptions. Once the extra off-ramping amount allowed by the larger fee is absorbed by the AMM, redemptions will continue at the original pace as long as the borrowing rate remains the same with the same intention to off-ramp.

To put this in the context of the current AMM, changing the redemption fee from 0.5% to 2.5% allows the AMM to absorb an extra 78K DLLR before redemptions become profitable again. After that happens, redemptions will be just as profitable as they were before.

Having said all this, the one thing that a higher redemption fee does is lower the peg, which makes RBTC/DLLR price go up. This makes off-ramping more expensive and therefore less attractive. That may slow off-ramp-intended borrowing, which would slow redemptions.

Prospective off-ramping borrowers may not understand that the redemption fee creates a higher cost of off-ramping before they actually borrow. If that’s the case, the higher redemption fee may not dissuade off-ramp-intended borrowing. I recommend that we find ways to educate and alert users to this extra cost so that off-ramping is discouraged for now. This is the real source of the redemption volume.

A high redemption fee is at cross purposes with our desire to grow confidence in DLLR as a stablecoin because it creates a looser peg. In addition, other than a temporary halt to redemptions (which lasts less than a week with typical borrowing rates), it does nothing directly to slow redemptions. Therefore, I recommend that we consider a smaller redemption fee (1%) that would create a small extra disincentive for off-ramp-intended borrowing and simultaneously educate users that this is a potentially expensive use case until supply and demand move closer to equilibrium as the ecosystem matures.

[one_digit]

I have a running Google doc on the meetings. The bookmark for brief notes on today’s meeting is here.

I’m a terrible note-taker, especially when I’m trying to participate too, so I highly recommend that you listen to the recording.

[dseroy]

I’m going to kick-start the bidding off. I think we go:

• 4% Origination (down 1%)
• 1.4% Redemption Fee (down 0.5%)
• 7.5K additional SOV to AMM (increase to 37.5K SOV weekly)

We’ll spend at least a week and compare: peg stability, redemptions, revenue and addition DLLR demand drawn into AMM.

I’m fine letting off the gas on the Exchequer LoC buffer idea, but think we should keep it in mind! I also will perpetually hammer the focus should be: 1) Peg stability 2) Revenue (which subsequently is used to increase $SOV yield rewards then 3) Redemptions

[Martin_Adriaan]

Instead of increasing the SOV rewards going to the DLLR/rBTC AMM, would it perhaps make sense to create a SOV/DLLR AMM pool and use the additional rewards for that, so that these additional rewards also serve to draw in SOV besides DLLR? (Also, with such a SOV/DLLR pool, an increase in the price of SOV helps draw in DLLR.)

[one_digit]

Interesting idea. I’m not sure it’s possible though. The AMM is set up around RBTC being the base currency. Trading is structured so that every pair that doesn’t have RBTC passes through RBTC. So, for example DLLR->SOV is actually DLLR->RBTC->SOV. Otherwise, we’d have to have a pool for every possible pair. And you get slippage on both swaps.

[one_digit]

I think those are reasonable adjustments. And I agree with your priorities.

[Martin_Adriaan]

Thanks, I didn’t know how the protocol checks for the need of composite swaps. Would it be much work to change the way the protocol checks whether a composite swap is needed, to avoid that the protocol takes the composite route (via rBTC) instead of doing the direct swap when possible (which incurs fewer fees)?

Relatedly, doesn’t the DLLR have a good claim to becoming another base currency of the protocol? Perhaps it wouldn’t be such a wild idea to create many DLLR AMM pools?

(Although these questions are tangential to the directly relevant discussion about peg, redemption and fees, so feel free to ignore, might be more for the longer term).

[one_digit]

These are all good questions. I’m not a dev and don’t have that level of insight into how the code is structured. My gut feeling is that it would be a massive ovehaul to have a pool that doesn’t have RBTC as one of the assets. But I could be wrong.

As long as we’re on Rootstock, DLLR won’t really be a base currency. RBTC is handled in a fundamentally different way than tokens are. In fact, we actually use something we call wrapped RBTC (not the same as wrapped bitcoin or WBTC!). Basically, the code locks RBTC and issues a token WRBTC so that it can be treated like any other token (ERC-20 Ethereum equivalent in Rootstock) in the system and doesn’t have to be treated in a special way at every turn. Just a little trivia there.

[Travis_trades]

Brilliant idea👍🏼 Many traders trade in dollars so making DLLR the primary trading pair alongside rBTC would surely soak up some liquidity in DLLRs

[Travis_trades]

I agree with David’s perspective in lowering these fees, only thing I’m not a big fan of is also increasing SOV rewards but I don’t see any way of soaking up DLLRs other than this at the moment

[yago]

I think we should switch to the new thread - so I will respond there.

[Ororo]

First, some information about how the system works now:

1. All swaps which do not include RBTC as one of the assets are composite swaps, because all of our pools are paired with RBTC. There is no direct swap possible.
2. The path finding method on the AMM is always returning the shortest path, not the path offering the best rate.
3. The function which finds the conversion path on the AMM is rather expensive (consumes a lot of gas).
4. Because of 2 + 3, the protocol has a default path set.

If we would add DLLR paired pools (or any other non-rbtc paired pools), we’d need to update a few things about the conversion paths:

1. On the protocol we would need to update the interface functions to allow the FE to pass the desired conversion path (because computing it on the contract itself would be expensive). The protocol could then still compare the price to the one offered by the default path and choose the better one - in case rates change between transaction creation and execution.
2. The Frontend needs to be able to determine the path offering the best rate. This logic could be added to the FE logic itself or in a public view function on the smart contract.

Please note that these are only the changes necessary regarding the conversion paths. Adding non-RBTC paired pools adds additional effort at other parts of the system.

[Martin_Adriaan]

Thanks! Regarding (4), if the current system works with a default path set (instead of a path finding function), and if we only add a SOV/DLLR AMM pool for now, could this path not just be added to the default path set? It’s not ideal, but would that circumvent having to update the interface functions and the frontend determining best rates (at least in the short term)? If people want to go via the longer SOV<->rBTC<->DLLR path they can always manually do two separate swaps.

On the one hand I’m thinking this may all be too much dev resources for what it delivers; on the other hand I’m thinking that Sovryn may want this anyway some time in the future, in which case we might as well do it now as it would help greatly with DLLR demand.

[one_digit]

I missed that there was a new topic for the new meeting.

Everyone, please continue the discussion there. The new topic/location is Second Zero DLLR Risk meeting tonight!.