i deleted the vote for now. Didn’t know the parameters in terms of timing.
Will allow more time for the forum discussion.
2 Likes
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 
2 Likes
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?
1 Like
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.
1 Like
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?
2 Likes
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.
3 Likes
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?
1 Like
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.
2 Likes
gm @eboado instead of changing Snapshot parameters, would doing an on-chain vote with an empty payload be sufficient instead?
Much like how Uniswap DAO did to signal the Polygon Deployment (linked here)
3 Likes
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 
2 Likes
Thank you for bringing this item up!
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.
1 Like
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.
2 Likes
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?
1 Like
Listing on V3 would make the most sense (considering the potential of the E-Mode as well) with a supply cap, however ensuring good culture on security (across whole DeFi and the projects the Aave community is engaging with) by demonstrating good security practices would be important given that there is also reputation risk if there isn’t proper security practices. I am sure however that @benqi_core team is looking to expand the sAVAX in its scale and working with Ava Labs team is a positive signal.
2 Likes
Thanks for you proposal
Could you please provide the details as described in the New Asset Listing Governance Guide? The community needs to understand in detail how sAVAX works and its risks, so its important to cover the questions of the Template ARC Asset Onboarding - Governance
2 Likes
Agreed! A detailed breakdown of the system will be shared once the transition is complete. We want to uphold the security practices of Aave for sure, as we do on BENQI as well. The details will be shared as per the Asset Onboarding template as shared by @Alex_BertoG. Thanks!
@Emilio V3 would be ideal! Also, a timelock contract in between isn’t practical for the liquid staking process as it stands.
Hey guys, let’s move this discussion to the below as it reflects the ARC Asset Onboarding Template. Looking forward to the discussion there!