Proposal to add sAVAX to Aave v3 market on Avalanche.
sAVAX or the liquid staking token created by the Benqi team who is well respected in the Avalanche ecosystem, has already amassed almost $150m in TVL in a few weeks being live. Recently Chainlink has provided feeds for this asset, enabling it for listing on Aave v3.
BENQI Liquid Staking is a non-custodial liquid staking solution that allows users to stake AVAX and receive sAVAX, an on-chain representation of delegation positions with Avalanche validators.
Traditional Staking on Avalanche locks up user’s AVAX on the P-Chain, preventing users from accessing the asset until the staking period ends. BENQIs Liquid Staking provides users the opportunity to unlock these “staked” assets through liquid staked sAVAX.
By supplying AVAX into the BENQI Liquid Staking protocol, users receive sAVAX which earns rewards from staking on Avalanche network. The price of sAVAX relative to AVAX goes up each epoch with rewards being accrued to the underlying staked AVAX. sAVAX can be used within DeFi applications on the C-Chain including AMMs (Trader Joe, Pangolin) and lending protocols (BENQI, Anchor, Aave) where users will now be able to access their yield-bearing sAVAX as liquidity to participate in DeFi and earn additional rewards.
In addition to the listing of sAVAX, we are proposing raising the LTV of AVAX to 60% and suggesting 60% for sAVAX as well. A detailed analysis of raising LTV on AVAX to 60% makes sense is presented in the link below.
I would like to have more clarity on the security of sAVAX. Especially what is happening between the time AVAX moves out of the smart contract and the time it gets staked on Avalanche’s P chain. I have asked this question before on Benqi telegram but have not received an answer.
Why should anyone be worried? Moving funds in and out of the C chain (importing/exporting) can only be done by an externally owned account (EOA). To be clear, I am not insinuating that the BenQi devs would rug, all I am saying is: what protects the backing of all those sAVAX is a single private key. Which can be lost or compromised.
I would love to learn what kind of protection measures are currently in place, but the question remains on what happens if the private key exporting from/importing to the C chain does get compromised.
Full disclosure: I am a member of another liquid staking effort on Avalanche. We are taking our time to launch to ensure proper safety of funds. Developing new technology that doesn’t rely on a single private key. Yes, BenQi scooped us, but they took a hell of a shortcut.
create a compliant with this framework post in the governance forum
after a minimum of 5 DAYS, create a snapshot vote on Aave snapshot with a clear yes, no, and abstain option and reach a quorum of 150k AAVE votes in total
Please read it again and stick to this. Otherwise im just going to vote against it. You don’t want me to vote against this. Trust me.
Edit: Also please check the snapshot vote again. You need YES, NO, ABSTAIN.
Sometimes its better to take some time, then just rush in hurry. Update everything necessary and keep the discussion alive. Will probably then end very well
Thank you for your comments!
I have noticed a large number of proposals not following standard practice lately, and I have tried mentioning this process on the forum recently. I even thought about writing a post on it! (Announcement: Aave Snapshot Space - #16 by raho? )
I asked about why the Snapshot standards were not taken into consideration while voting recently in Aave’s discord and Pablo told me that “as snapshot does not trigger any change in the protocol, is just to evaluate the sentiment it does not need so strict requirements”.
Do you think it would be worthwhile to make a post concerning Snapshot etiquette?
I think its already written in the post i linked today. So not necessarily needed, but still we can ping people and tell them to keep this in mind. Just to have it kinda sorted.
Does anybody know if the Aave v3 new asset listings follow the same methodology as Aave v2 new asset listings? I feel like it would have to vary by chain… Just curious if anything has been written up for new asset listings on Avalanche?
Listings on Avalanche are a bit different than on Ethereum or Polygon @raho. On those, it is possible to do a full-cycle of governance proposal on-chain, direct (Ethereum), or via the deployed cross-chain bridges (with the infra provider by the Polygon network itself).
At the moment, on Avalanche the bridging infrastructure is different, as it is reduced to bridge assets, but not generic messages (a proposal is this last). So the Snapshot process is especially important there, as it is the main layer of governance decision, and then it is the responsibility of the elected Guardian (here Aave Guardian Update) to apply the changes on Avalanche.
Due to that, I think we should really define a strict voting framework for cases like this, where deployment of Aave is done in advance of having messaging bridging available. If you want to tackle the write-up and open the discussion, could be cool. At the very least, I think that for those chains, even if not on-chain enforced, requirements on Snapshot should be exactly the same as on Ethereum governance: 320K AAVE on Yes and vote differential of 80K with No.
Then, for Ethereum/Polygon/others with cross-chain messaging, the requirements can be looser, as it is really just an initial filter. But still, I agree that some minimal requirements like the ones linked before here need to be in place.
Then, regarding the listing, assets with off-chain components should be really carefully evaluated before listing. I could be in support of the listing of sAVAX, but not without having a crystal clear evaluation of everything around the asset, similar to the top-notch work done by Lido with stETH. I’m fully sure that @luigidemeo88 will definitely facilitate this, being a really active member in the Aave community.
Hello and thank you for the clarity on this! I was actually more curious about the grading matrix used on Ethereum compared to off chain… Do you think it would be helpful to have a framework unique to each chain that reflects the Aave community’s standards on new listings? I noticed while trying to fit sAVAX into the standards for Aave’s new asset listings on Ethereum that a lot of the metrics used on Ethereum for v2 were a bit high, and I am curious if this could create a large barrier to entry for many tokens on alternative chains?
I would be happy to write something up! After reading your explanation, I do completely agree that there should be a vote requirement for chains with elected guardians. Do you worry that the mixing of these standards could get confusing for the community though?
With v3 already present, taking into account the isolation mode, the community should be open to more frequent listings. But I think that should just influence voting more frequently Yes, not on lowering governance requirements.
Regarding the framework, I think it is better to keep the same parameters for all chains, for all decisions (listing included), in what concerns the short executor.
Basically 2 different models:
Primary. Forum → Snapshot (lower requirements than on-chain) → on-chain governance
Temporary. For all cases where for technical reasons Primary can’t be applied yet. So Forum → Snapshot (strict requirements) → Guardian executing. Any proposal that doesn’t fulfill the defined requirements on Snapshot, is automatically identified as Failed.
And yes, it could create a bit of confusion, but it is definitely way more confusing not having any “source of truth” for procedures as important as this for the community.
Let’s better move to a separate discussion thread, I think @raho plans to create it. Because if not we are polluting a bit too much in this one of sAVAX
The safety and security of BENQI is the most critical aspect of our work. We have worked extensively with Ava Labs in this regard.
The EOA is currently protected in a hardened memory-only runtime environment with no remote access and extremely restricted physical access.
We are currently in the final stages of transitioning to a distributed warden system based on multiparty computation technology (MPC). We will make the details public in due course.
Note: It will still appear as an EOA, but is in fact a fragmented security solution based on distributed ECDSA.
Thanks for sharing the details on the security side @benqi_core would be good to wait until that transition has happened and after that if the Aave community could get a detailed documentation of the security of the system and also the best practices before moving forward with a Snapshot so that there is enough information for the community to vote on the subject.
Lets consider that the listing would be on Aave V3. Any risk can easily be mitigated by keeping a proper supply cap.
Regarding the architecture @benqi_core, would you consider the usage of a timelock contract between the EOA and the actual sAVAX contract?
