Nexus v2 Managed Staking Pools: The Ease Risk Rubric

Hey! I’m Chris, a team member of Ease (formerly Armor). For the past couple months I’ve been in charge of working on upgrades to our arNXM service to coincide with the upcoming Nexus v2 changes. We’re going to be a syndicate on V2 and as such, we wanted to make our ratings transparent.

With Nexus v2 arriving soon and Ease already managing the largest pool of NXM through our arNXM system, we have been working to create a methodology that can accurately quantify the risk protocols have to Nexus stakers.

The goal of this rubric is to provide a framework that determines which protocols to underwrite, in what amounts, and at what prices. Allowing our stakeholders to maximize profits, while mitigating risks. This includes not only the returns from underwriting but also incorporating the potential losses from protocol risk. The rubric can be used to determine any grade of protocol: from extremely dangerous to nearly risk-free. With it, we hope to achieve greater transparency for people that decide to stake into our Managed Pools, whether its through arNXM or the Nexus front end as an independent staker.

The Ease risk score consists of two subratings that are weighted 50/50 to be combined into a total score of 100%.

The Ease Risk Rubric

The Ease Risk score or Protocol Rating is a combination of 2 sub-scores.

The first major score is taken from DeFi Safety. DeFi Safety is a leader in rating a protocol’s transparency and documentation on their contracts, as well as the use of auditors and bug bounties, and if recent hacks have occurred. This score is initially out of 100, but we apply a 0.5 weight to it, to score it out of 50.

Secondly, the team at Ease applies their own ratings to a set of metrics not covered by the DeFi Safety rating. DeFi Safety’s focus is on grading a protocol’s end-user safety. Our ratings are designed with the specific intent of judging how likely claims are to occur on Nexus. These two are added together to provide a general risk rating out of 100.

There are 5 different metrics, each with their own scores:

1. Time Weighted Total Value Locked, 0-20 (TW-TVL): We grab TVLs of protocols from DefiLlama API and time-weight these from the protocols’ genesis, based on data on daily intervals.

Scoring

  • 0: 0 - $1B
  • 5: $1B - $10B
  • 10: $10B - $100B
  • 15: $100B - $1T
  • 20: >= $1T

Rationale - Two factors determine the belief of a protocol’s “battle-tested” nature. How long the contracts have been live, and the amount of value locked in the contracts. So, we account for both. We take daily TVL numbers and add them together, because the longer the TVL has been locked, the more time a black hat has had a chance to attempt to find a vulnerability and exploit it.

2. Upgradeability, 0-5: We rate the impact upgradeability has on the perceived risk of the covered protocol.

Scoring

  • 0: The contracts or protocol covered under nexus are upgradeable
  • 5: The contracts or protocol covered under nexus are NOT upgradeable

Rationale - As an example, Uniswap v2 is never upgradeable. A Uniswap v2 policy on Nexus will always only ever cover Uniswap v2 pools. However, a policy for Yearn (all vaults) can cover more and more added contracts over time. So an exploited contract in the future might not have been a part of the ecosystem when stakers initially underwrote the protocol. This potential for an unknown risk leads to a lower score.

3. Oracles, 1-5: We rate the impact an oracle might have on the potential risk of the protocol

Scoring:

  • 1: v2 TWAP
  • 2: v3 TWAP
  • 3: ChainLink
  • 4: Centralized; ChainLink w/ redundancies
  • 5: No Oracle

Rationale - Oracles are an extremely common attack vector for DeFi hacks. However, not all oracles are exploited equally. A v2 TWAP oracle would rate lower than Chainlink. Centralized oracles are not covered by Nexus policies, meaning the risk to underwriters is unlikely in the event an exploit were to occur through one.

4. Protocol Type, 0-5: We apply a rating depending on the service that the protocol offers

Scoring

  • 0: Lending or Leverage
  • 1: Options
  • 2: Derivatives
  • 3: Yield Farms
  • 4: DEX
  • 5: v2 Clone

Rationale - Historically, some types of protocols are more susceptible than others. A lending protocol is usually susceptible to a loss of a large portion of its TVL. While a yield farm usually results in losses from only a single strategy.

5. Auditors, 0-10: While DeFiSafety does provide a rating on whether or not a protocol has audits, Ease found it important to also provide an additional rating based on:

  1. Are the audits up to date
  2. What is the reputation and quality of the auditor

Scoring

  • 0: No Audits
  • 3: Low Quality
  • 5: Medium Quality
  • 10: High quality
  • +1: Additional points can be given for multiple audits
  • -X: Audits for old code bases

Rationale - Some auditors dedicate weeks worth of work hours to each of their audits with a backlog sometimes spanning into the next year. On the other hand, some auditors have a much quicker turnaround and dedicate significantly fewer hours to their auditing process. We determine audit quality through ours and industry experiences with auditors, their noted processes, and reputation regarding past hacks and bugs. Also, regardless of the auditor if the only audits are for an old code base, then the relevance of the audits are in question

6. Bonus Points

Rationale - Not everything can be quantified into this scoring system. So we leave the opportunity open to add or subtract bonus points from protocols in a subject nature. If this occurs a note will be made on the amount of points given or taken and the reasons why. For example, Eth2 staking will receive an automatic 100. In the event of an issue in the staking mechanism a hard fork is likely.

Total
The max sum of these 5 scores is 45. We take the percentage total a protocol received and apply the same 0.5 weight to it that DeFi Safety receives.

Adding these together we arrive at a score out of 100%, known as the Protocol Rating. We then utilize this rating to determine two things:

  1. Which Ease managed staking-pool the protocol is allocated to
  2. The target price premium for that protocol

We will go into detail on these two items below.

Pricing Model

With the Protocol Rating determined, we now apply our pricing model which is used to determine the Target Price that we will set for that protocol in our management pool.

The Minimum Price in the system is set by Nexus, which is 1%. Meaning, a protocol with a perfect score will also have the lowest possible target price.

Ease Managed Staking Pools

With the launch of Nexus v2 there will now be managed staking pools. In which NXM stakers can allocate their staked NXM to managed staking pools. The manager of the pool will determine what protocols are underwritten, at what prices, and in which capacities. Ease will manage 3 pools, whose protocols are determined by this risk rubric, and stake arNXM into them. The first two these three pools will be available at the launch of v2, with the other one coming shortly after.

What isn’t covered

To start, the aim of Ease managed pools is to support DeFi. Meaning, Ease will not provide underwriting cover to custodial services. The centralized nature of these entities prevents us from being able to accurately assess the risks they pose to Nexus underwriters.

Pool 1: The AAA bucket

This pool will consist of only the highest rated protocols, the cut off being a Risk score of >= 75. These protocols will have the cheapest target prices for premium costs (<1.9%). These protocols generally are the “least risk” to underwrite, and historically utilized high capacity (though that is no longer the case for some). The small pool of protocols means that maximum leverage is not needed to support this bucket. Returns will be safer for stakers as the risk of a potential coverage event is lower.

Pool 2: The AA bucket

This bucket will contain protocols between the 75-60 threshold. These protocols will have the target prices for premium costs between 1.9% and 3.4%.

It is unlikely that the full weight of user stakes will be used on the protocols, as cover demand is consistently lower for most of these. But more NXM leverage will be used to cover the wide range of protocols, as the AAA bucket will be rolled into this one.

Pool 3: The A and Surge bucket

This bucket will be much more dynamic and likely use full leverage on the protocols to maximize capacity with the least amount of arNXM possible. It will include protocols below 50-60, as well as higher rated protocols that begin to experience capacity issues.

Initial Launch Pools

We will launch with two pools. The AAA and the AA buckets. The protocols included don’t include every single rated protocol. We are launching based on ratings + current demand (using active cover values via nexustracker.io). We also used this to determine the starting weights in which NXM is allocated, to reduce excess capacity. The included protocols, their allocated weight and their ratings are subject to change at any time.

AAA Launch Bucket

AA Launch Bucket (+ all AAA Bucket protocols)

4 Likes

Thank you Chris!

We’re looking forward to being a syndicate on V2 and want to be as thorough and transparent as possible to everyone who may be looking for a syndicate to stake with.

DeFi risk assessment is a complicated task that calls for objective measurement. With arNXM previously we did not have an explicit rubric and it resulted in risk/reward choices being influenced by recent events (or lack thereof) rather than being purely data-driven.

For this rubric we’ve worked with a few different security experts on which factors to include and their importance, and will continue to update values as needed based on further research and feedback.

The rubric and explicit strategies for our pools will lead to objective and transparent management of our syndicate where users can be comfortable in knowing exactly how we will be utilizing their stake and what level of risk they are accepting.

Let us know if you guys have any questions!

4 Likes

Thanks Ease team. I really like the structured and transparent approach!

Personally, I would add some value to the question if a protocol/team has been hacked in the past or if critical smart contract bugs were discovered (e.g. through bug bounty/Immunifi/etc) in current and previous iterations of the protocol. While not explicitly scoreable it’s probably something to consider in the “Bonus Points” section.

Cheers,

Ricky

2 Likes

Hey Ricky,

Thanks for the feedback! Our goal is to increase the scrutiny and detail of our metric over time. For now, we decided to forgo including past hacks in our own metrics because DeFi Safety currently applies penalties to their protocol scores if a recent hack occurred. An example of what that looks like can be seen here, with Rari Capital’s report..

Their score also takes into account whether a bug bounty program is present or not. But your idea of also scoring based on if any critical bugs have been found is one I had not thought of! I agree that could easily fit into our “Bonus Points” section.

Thanks! Please share any more ideas if they come to you :slightly_smiling_face:

2 Likes

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