Proposal Idea: Adding support for VST

Radiant Foundation Proposals (RFPs)
1

Abstract

We propose supporting VST on Radiant with a max LTV of 75%. VST is a stablecoin minted directly by the protocol users by opening a vault and depositing ETH, GMX, DPX, gOHM, and GLP as collateral. The variety of Vesta Finance collaterals makes VST one of the most innovative stablecoins currently available on Arbitrum.

Motivation & Rationale

With DAI, USDC, and USDT, Radiant currently has all of the stablecoins available for borrowing presently on the platform are centralized or rely heavily on centralized collateral. Adding VST as a borrowable asset on Radiant would further diversify the protocol from centralized stablecoins and give users on Arbitrum an exciting choice when using the platform.

In addition, VST has strong native demand for lending and would help Radiant onboard users from other ecosystems. VST is the most traded stablecoin on Arbitrum beside USDC, consistently seeing >300k of daily volume in the past six months. VST is backed by Arbitrum leading assets such as GMX/DPX, so having VST onboard will allow Radiant to have attractions to users who hold these assets as well. Also since these collateral are already deployed in different chains like Ethereum/Avalanche/Arbitrium, the liquidity sourced from these chains will also help Radiant’s omnichain vision.

Key Terms

  • Overcollaterization: ​the dollar value of the locked collateral exceeds the dollar value of the issued stablecoins. After opening a vault with some collateral, users may issue (“borrow”) tokens such that the collateralization ratio of their vault remains above 110%. A user with $1000 worth of underlying collaterals in a vault can issue up to 909.09 VST
  • Vesta Reference Rate: a variable interest rate applied on VST generator’s debt algorithmically controlled by the token’s peg.

Specifications

VST is a stablecoin minted directly by the protocol users by opening a vault and depositing ETH, GMX, DPX, gOHM, and GLP as collateral. The available collaterals make VST one of the most decentralized stablecoins on the market.

VST is overcollateralized by its collaterals with two main mechanisms helping it keep its peg. First, Vesta Reference Rate is applied to VST generators that could increase as the peg increases, encouraging people to decrease VST supply. Secondly, there is a minimal collateral ratio for each asset. Both mechanisms create a price floor and ceiling through arbitrage opportunities.

Vesta is committed to ensuring that we provide the best and safest protocol for our users. Our first audit was done by Verilog, a boutique smart contract security firm. More can be found here: https://docs.vestafinance.xyz/audit/audits.

Furthermore, Vesta works with Risk DAO to determine and constantly monitor riskiness of all assets. Vesta has devised our own Collateral Risk Framework for onboarding new assets (learn more about our framework here: Collateral Risk Framework - Vesta). Risk DAO’s methodology is applied in determining the correlating parameters for all collaterals such as mint cap and minimum collateralization ratio (visit Risk DAO’s Vesta dashboard here: https://vesta.riskdao.org/).

Market data

  • Market Cap
    • Average market cap 6 months based on daily close (2022 June 1 - December 1) 679057.08
    • Average market cap 1 month based on daily close (2022 November 1 - December 1) 11275498.98
  • Volume
    • The average daily volume of the last 6 months from June 1 to December 1 based on the daily interval is 262016.27
    • Total volume of VST-FRAX since inception is 84072365.13
  • Exchanges
    • VST is mainly traded on Arbitrum Curve (link) and SwapFish (link)
  • Volatility
    • VST consistently trades between 1.01 and 0.98 on our main liquidity pool. The oscillating price encourages activities such as opening and closing vaults to take advantage of the arbitrage (view VST price on Vesta’s Stats page)
  • Maturity

Social channels data (Size of communities, activity on Github)

  • Discord: 7900
  • Twitter: 21k
  • Medium: 630

Contracts date of deployments, number of transactions, number of holders for tokens

Links:

Project - https://vestafinance.xyz/
Whitepaper / Documentation - https://docs.vestafinance.xyz/
Github / source code - https://github.com/vesta-finance/
Ethereum contracts - https://docs.vestafinance.xyz/technical-overview/contract-addresses
Audit - https://docs.vestafinance.xyz/audit/audits
Twitter - https://twitter.com/vestafinance
Discord - discord.gg/vestafinance
Blog - https://medium.com/@VestaFinance
Support - Vesta

Steps to Implement

  • Smart contract logic and UX/UI adjustments to be tested in a staging environment
  • Upon completion of beta testing, code would go to Peckshield to review
  • Upon completion of the audit, implementation would occur upon launch of Radiant v2

Timeline

Implementation of fee redistribution and changes to vesting would go into effect upon launch of v2, and would deploy on all subsequent Radiant chains (current & future).

Overall Cost

Likely some/no/significant maintenance dev cost, no additional structured costs beyond existing time/resources spent in development.

2

send it :rocket:

1 Like
3

I think Radiant is not getting enough benefit out of this partnership.

I would evaluate opening a RDNT vault for minting VST on Vesta finance, that way we add a new utility for the protocol.

Regards

5 Likes
4

Great idea.

My understanding is Vesta is a code fork of Liquity.

Liquity performed brilliantly during the 2022 dumps, liquidations were efficient and the protocol did not suffer any solvency concern.

The big difference is Liquity is ETH collateral only, and there is insolvency risk (research published by Liquity) in cases of extreme ETH volatility.

The concern here with Vesta is that the volatility of their collateral is greater so there would be more chance of protocol insolvency than ETH only collateral in extreme volatility scenarios.

5 Likes
5

In principal this looks exactly like what Radiant should be doing to create a more robust money market offering. Vesta is a solid performer in the collateralized loan space and would enhance Radiant Capitals exposure to other potential users.

I’d like more specifics about how this would benefit Radiant and add to the long term vision and profitability of the protocol. Are there any real or potential downsides of partnering with Vesta in this manner?

2 Likes
6

I agree with Gerhard on this.

1 Like
7

vesta partnership is interesting, however I am strongly against it unless VST is silo’d off from other assets. it’s way too unstable to be used as collateral atm, it would just lead to profitable trading strategies like every other money market with dodgy collateral. stick to collateral that can’t be manipulated or heavily limit the amount borrowable/ltv if you do go through with it

1 Like
8

Hey guys, Mikey from Vesta here. Thanks for all of your feedback. I’ll address as many concerns as I can.

This is definitely something Vesta could do once we un-pause collateral addition. Vesta currently has paused collateral addition since the stablecoin is undergoing some changes. We are going to fix the under-peg issue with the new feature called Vesta Saving Module where VST will now have native yield streamed to it.

While this is correct, please note that Vesta has also changed substantially overtime and will continue to change as we move forward. For reference, please view Roadmap Overview - Vesta

Vesta works with Risk DAO to determine and constantly monitor riskiness of all assets. Vesta has devised our own Collateral Risk Framework for onboarding new assets (learn more about our framework here: Collateral Risk Framework - Vesta). Risk DAO’s methodology is applied in determining the correlating parameters for all collaterals such as mint cap and minimum collateralization ratio (visit Risk DAO’s Vesta dashboard here: https://vesta.riskdao.org/).

Such an integration would enlist Vesta as a strategic partner of Radiant, laying the groundwork for future collaboration such as allowing RDNT to be listed as a type of collateral on Vesta. Vesta core contributors are crafting a proposal on our side to request for VSTA (the Vesta governance token) incentive to support borrowing and lending VST on Radiant.

Thanks for your feedback and I understand your concern. Please note that we take security of the stablecoin very seriously. Assets are only listed once passed the collateral framework and vetted by Risk DAO. Parameters within Vesta are also set very conservatively, With mint cap on assets such as GLP and gOHM at 10m and 6m respectively.

To further make sure that we are on the same page, I suggest starting with a 2m borrowing cap on VST. Basically, only 2m VST can be used to borrow other assets. Ideally, users can deposit however much VST they would like, and that the Radiant protocol can place a cap on the borrowing power of VST. However, if this is not possible, then I would suggest placing a deposit cap on VST - where a max amount of 2m / 70% = 2.85m can be deposited into the pool (this way, a max amount of $2m assets may be borrowed from depositing 2.85m VST given the 70% LTV). This number would scale with VST’s liquidity depth as we deepen liquidity going forward, making VST less exploitable.

9

My first concern is that the team has a lot to do to get V2 launched. Not just code, but lost of documentation updates, training, support, etc. We should not try to do everything inn v2 but rather ensure the V2 launch is well executed and well supported first – then we can take on new tasks in a v3, v4, etc.
A secondary concern is that any proposal should add value to the stakeholders (not just the DAO), and that there are always costs associated with any project (even opportunity costs should be weighed). The community needs transparency about the financial positions and status of the DAO before voting on any new additions. We should understand the costs and benefits. I’d rather see the DOA and the team take some to decide how we will manage our financial position [internal] transparancy and provide a basis to evalute new projects/tasks/integrations before voting on them. It isn’t possible to do everything well so things need to be prioritized.

1 Like
10

Completely agree. My sense is there’s the v2 launch itself, there is a transition to DAO leadership step that needs to be undertaken first.

TRANSITION TO DAO

  1. An operational process for the DAO
  • operational cost reporting (monthly team expense)
  • open sourcing the development flows on GitHub for greater transparency and attracting developers
  1. Tokenomics redesign taking into account a team pay day (liquidity event), team funding sustainability plus the inflation/emission question:
  • OpEx revenue portion
  • team perma-lock question
  • the 10% burn
  1. A product roadmap / CapEx outline

POL
We also have the POL initiative (eg Gamma proposal) that can be addressed alongside the “transition to DAO leadership”.

SUPPORTED COLLATERAL FRAMEWORK
Adding new collateral like VST should come after all this. In my opinion this should be assessed from the point of view of a general framework first (as discussed above), from which you can then apply to VST to see if it suits.

And tbh, we will benefit from having some data on v2 usage etc that we can assess. It may well be that we need to tinker with parameters via vote within 3 months of v2 usage metrics.

1 Like
11

This topic was automatically closed after 7 days. New replies are no longer allowed.

12

From a member that doesn’t want to authenticate his wallet, despite being inform we don’t dox wallets:

"JacksWiths — Today at 12:15 PM
I’m not the one making the final decision, but I’m 100% against adding low liquidity tokens either as collateral OR borrowable.
As far as we know, even with what is supposed to be robust oracle & price tracking systems, it is always an increasing attack surface.

I do not think that giving the possibility to borrow VST would add any value to users, lockers or lenders.

Thus, I see the risk way superior to any possible gain."

14

I understand that it may seem like such a listing could render the market exploitable. The proposal I have is to put a deposit cap of 2.85m and lending cap on 2m from VST (meaning only 2m VST may be used as lending power), which would render any attack uneconomical.

Furthermore, our collaterals are constantly monitored by Risk DAO here: Risk DAO | risk management dashboard All collaterals backing VST have gone through our rigorous framework here: Collateral Risk Framework - Vesta and we have measures such as Vesta Emergency Reserve to compensate users against any exploits. Vesta Emergency Reserve - Vesta Something even better will come with Vesta Saving Module - all deposits in the saving module will be used toward liquidation, rendering bad debt impossible in our system. The module is expected to go online in as short as February 6th.

15

To further clear up any confusion regarding risks, I would like to add a comment regarding how we can safeguard against potential exploits.

Vesta: a Safety-first Protocol

Firstly, we need to establish the understanding VST is safe and that it is hard for VST to go significantly off peg. It is in Vesta’s interest to ensure that no bad debt accumulates. Learn more about Vesta’s risk initiatives here:

VST’s Peg

VST has a hard price ceiling at $1.1. Any sustained period above $1.1 will be arbitraged down to $1.1. On the other hand, VST has a soft price floor at $0.98. Learn more about how VST keeps peg here).

Addressing Possibility of Oracle Manipulation

The main concern with a VST listing is the potential for a oracle manipulation resulting in loss of Radiant’s other collateral - an attacker could take out a flash loan and market buy VST, increasing its value to borrow more asset than it is supposed to. This is infamously known as “highly profitable trading strategy” seen here.

To ensure that such a situation is impossible to be carried out, I will dive a bit into how I see the system should be set up.

  1. VST Oracle set up: Vesta currently runs a VST oracle, which is being used internally to determine Vesta Reference Rate. This oracle is a 30-minute TWAP, which makes it impossible to be attacked by a flash loan. Furthermore, we have a list of best practices for integrators of our oracle service, seen in our doc here which would further ensure Radiant against any exploit. We’ll also work with auditors such as Zellic to double check the system.

  2. Borrow cap on VST: as I mentioned above, a borrow cap should be implemented at the start. I suggest the borrow cap be equal to the total liquidity of VST, so for now it’d be $5m considering how VST-FRAX pool has $5m of total liquidity.

These mechanisms renders any attack improbable. Considering an attack scenario: Alice the attacker could come in with $5m and pump the price of VST to $2 for 30 minutes to influence the 30-minute TWAP price of VST. The price of VST will 100% be arbitraged down to $1.1 within 30 minutes. In this case, he has already lost ($2-$1.1)/$2 * 5m = $2.25m as people arb it down. At this point, his collateral is worth $2.75m. Assuming he takes out max loan at 70% LTV using 2.75m of collateral, he’s only able to take out 1.925m in loan. As a whole, he’s lost more than $3m due to how the price oracle is a 30-min TWAP.

This also suggests that a borrowing cap is actually not needed. However, we do recognize that this is the first time a new collateral is being added on Radiant. Thus it makes sense to add in such a safeguard mechanism and scale this asset’s capacity iteratively.

Borrow Cap Implementation Suggestion

I suggest borrow cap to be implemented where any deposited VST is assumed to be fully utilized at max LTV. For example, suppose VST borrow cap is $70, Alice deposits $100 of BTC + $100 of VST, and takes out $70 of loan in USDC. Then the system’s overall borrow cap is reached and whoever else comes in may no longer borrow using VST. I also suggest that the system keeps count of VST collateral usage on a FIFO basis where only when Alice takes out her VST, then does the borrow cap free up and Bob can come in a use VST as collateral in the system.

$VSTA Incentive for Radiant

We are hoping to incentivize lending and borrowing VST on Radiant with our governance token. See the proposal here: Vesta’s incentive plan for Radiant: [RFC] Incentivizing VST Lending and Borrowing on Radiant - Partnership - Vesta We do plan on modifying the emission to act in accordance to the finalized borrowing cap to ensure a target APR for lending and borrowing.

Overall I believe the 30-min TWAP nature of the VST oracle will render any economic attack unprofitable. Furthermore, we suggest implementing a borrow cap for safety and scale iteratively.

16

Hi Mikey

The concern I have is specifically around the volatility of the Vesta collateral, and what state the system ends up in under realistic assumptions.

The resources you shared don’t backtest the system against realistic volatility assumptions of the collateral posted.

By comparison, the risk assessment by Gauntlet of Liquity with ETH collateral only at annualised volatility of 173 has the system in recovery mode twice. Recovery Mode in Liquity allows the system to liquidate any trove with a Collateral Ratio under 150.

The system can maintain LUSD peg in Recovery Mode, but the process withdraws 27% of circulating LUSD in the model in that state.

173 annualised volatility for ETH is a “normal” amount since this figure was chosen based on historical volatility.

My intuition is that with collateral like GMX, sGLP, gOHM and DPX (!) you are looking at annualised volatility modelling that should assume twice to three times the annualised volatility!

With that level of volatility does Recovery Mode stablise the Vesta system and recover the peg?

I am happy to have my intuition proven wrong by a model of the standard of the Gauntlet model that shows the performance of Vesta under realistic collateral volatility assumptions. (A dashboard and a framework is not sufficient o make me believe this is a system to be trusted under realistic and expected collateral volatility.)

The Gauntlet report on Liquity for reference: https://liquity-report.gauntlet.network/

17

Thanks for your question! Back in May of 2022, Risk DAO conducted a comprehensive system parameterization analysis of Vesta, looking at all the assets on Vesta (excluding sGLP, which is way less volatile than the more volatile assets that were analyzed such as GMX and DPX). You may find the analysis here: Reports/Vesta Finance: System Parameterization Analysis.pdf at main · Risk-DAO/Reports · GitHub In fact, we’ve since disabled recovery mode based on Risk DAO’s recommendation as recovery mode has been shown to not materially impact protocol solvency but it severely impacts user experience of those who have vaults open.

In addition, the establishment of Vesta Saving Module (going live Feb 6, in a couple days) will backstop liquidation in the system even more, as all the locked liquidity in the Saving Module will be used toward liquidation in case of any single stability pool runs out.

19

VST <3 RDNT
Upvoted, should be added

20

Highly in favor. Vesta team has proven to be a a capable team and together with Risk DAO assessment security have been given a top priority regarding VST stabilization although waiting for the Vesta Saving Module implementation would be the right path.
I agree a RDNT vault would be favorable for the protocol as well.

Given that the proposal stablishes a cap of 2M I’m highly in favor to go ahead as a test mode, we should embrace decentralization and VST might be the right path.

21

This topic was automatically closed after 8 days. New replies are no longer allowed.