[Non-Constitutional] Arbitrum Aegis

Proposals
6

I’m glad there’s interest in building on top of Nexus Mutual to offer a safety net for Arbitrum protocols and drive growth in the Arbitrum ecosystem. Launching an underwriting pool (i.e., NXM staking pool) is a great way to do that.

I’m Head of Product & Risk at Nexus Mutual, and I wanted to provide some context on the main proposal and some of the responses in the thread to ensure voters have enough information to make an informed decision.

Overview of Nexus Mutual

Nexus Mutual is the first crypto insurance alternative—we’ve been covering crypto since 2019.
Our mission is to provide protection for onchain risk. To date, we have paid $18M+ in claims and underwritten $6.1B+ in onchain coverage.

Nexus Mutual operates as a discretionary mutual built onchain with $220M+ in assets held in our Capital Pool backing the NXM token supply. When members join the Mutual, they can buy cover, contribute capital to the Mutual and receive NXM, stake NXM to underwrite risk, and participate in governance. For more information about the Mutual, you can see analytics on our Dune dashboards and read through our documentation.

I’m also happy to answer any questions folks might have about Nexus Mutual, as well.

Nexus Mutual Coverage

There are quite a few different cover products we offer at Nexus Mutual, with the most popular public product being Protocol Cover. The Protocol Cover wording is modular, so it can be applied to Single Protocol Cover (coverage that protects against risk within a single protocol), Multi Protocol Cover (coverage that protects against risk across multiple protocols), and Native Protocol Cover (coverage designed for protocol teams to purchase on behalf of their users) listings.

With Protocol Cover, users can protect themselves against:

  • Smart contract exploits
  • Oracle failure
  • Oracle manipulation
  • Liquidation failure
  • Governance takeovers

For more information, you can read through the full Protocol Cover Terms and read the summary of Protocol Cover in our documentation.

Nexus Mutual already has listings for most of the major protocols on Arbitrum. If this proposal were to pass, we on the Product & Risk team would be happy to work with the Arbitrum Aegis pool management team to add new listings for Arbitrum protocols, so the Arbitrum Aegis pool can underwrite cover for those protocols where listings are not yet available.

KYC, Point-of-Sale Integrations, & OpenCover

Because Nexus Mutual is a discretionary mutual, we do require members to go through KYC when joining the Mutual for compliance reasons. However, users can buy cover through OpenCover, our distribution partner that allows native cover sales on L2s like Arbitrum. OpenCover does not require KYC for cover buys but does require KYC for claims filing, if a loss event should occur.

OpenCover has a point-of-sale integration solution that would allow listed protocols on Arbitrum to allow their users to purchase coverage directly in-app without requiring users to link out to OpenCover’s site. This increases awareness about coverage and improves the overall user experience by offering cover at the point of deposit. Less hoops for users to jump through is good for everyone involved.

Specific Terms of Note

@GFXlabs asked a great question about the details about coverage. I shared the Protocol Cover wording above, and I’ll share it here as well.

I’d recommend folks read the whole doc but some terms of note:

  • Deductible. There’s a standard 5% deductible noted in the cover wording. However, there is flexibility to increase a custom deductible for a listing by including it in the Annex document associated with a listing. A deductible acts as a first-loss provision to ensure covered users and covered protocols are not taking undue risk without having an element of skin in the game. This helps offset some of the moral hazard that @TodayInDeFi noted in their comment.
  • Cool Down Period. A period of fourteen (14) days following the occurrence of the Covered Event, during which no Claims may be made. The duration of the Cool Down Period may be adjusted as specified in the Annex for individual agreements. The cool-down period gives assessors enough time to gather evidence and assess the validity of the overall loss event, read post-mortem reports, etc.
  • Grace Period. The period during the Cover Period or within thirty five (35) days following Cover Period ending during which the Covered Member may submit a Claim. If a user buys cover for 30 days and they suffer a loss on day 29, they still have 36 days to file a claim. The grace period ensures users can file a claim if they suffer a loss when their cover is active, even if their cover is expired at the time they file their claim.
  • Oracle Failure. An event in which incorrect price feed data is used by the Designated Protocol’s smart contracts, where:
    • for stablecoin-related oracles, the error exceeds 1%; or
    • for all other assets, the error exceeds 2.5%
      and such incorrect data arises as a result of any of the following:
    • a faulty oracle configuration; or
    • a lack of proper safeguards to prevent an unauthorized party from providing pricing updates; or
    • a fixed-rate oracle that is manually updated where the data is updated incorrectly; or
    • an oracle’s defined trigger parameters to provide updates to its price feed are met but the price feed fails to update a Designated Protocol’s smart contracts.
  • Oracle Manipulation. An event where price feed data is deliberately corrupted and leads
    to a loss of funds in a Designated Protocol.
  • Liquidation Failure. An event where:
    • Keepers are unable to liquidate collateral backing unhealthy borrow positions, resulting in bad debt that is subsequently socialized and passed on to all lenders within the affected market; or
    • Keepers liquidate collateral backing unhealthy borrow positions for an amount less than 80% of the fair realisable market value of the collateral, taking account of the prevailing market conditions.
  • Governance Takeover. An event where a malicious actor forces through a malicious
    upgrade to a Designated Protocol smart contract.

Nexus Mutual Claims Process

Claims Process

When a loss event occurs, users who held Protocol Cover at the time the loss event occurred can file a claim. For Protocol Cover, there is a 14-day cool-down period that needs to pass before claims can be filed onchain. During the 14-day period, claim assessors review the onchain data to validate the loss event and help users calculate their loss amounts in preparation for claims filing.

  • If users hold Single Protocol Cover at the time the loss event occurs, they can submit a claim with supporting evidence, otherwise referred to as proof of loss.
    • Users would include written details, links to supporting documentation, and/or upload screenshots or other files in the Incident Details portion of the claim submission process
    • Users would choose to either sign a message from the affected address or send a 0 value transaction from the affected address to prove they own and control the affected address
  • Claim assessors will review, discuss and vote to approve claims where proof of loss shows that users have indeed suffered a loss of funds.
    • If a claim is approved, users are able to redeem their claim payout after the 24-hour post-claim period passes in the Your Covers menu. They can also check your Dashboard to see the status of any active claims. The 24-hour post-claim period is in place to allow the Advisory Board to perform a fraud check.
    • If a claim is denied, users are able to file another claim with more supporting evidence

Claim Assessors

Nexus Mutual’s claims process doesn’t involve a protocol-wide governance vote. Historically, any member could participate as a claim assessor by staking NXM to participate in the assessment process. If assessors act maliciously, the Advisory Board has the power to burn a malicious assessor’s staked NXM and reverse their vote. Nexus Mutual’s claims assessment process has operated like an optimistic oracle, in this sense.

Recently, Nexus Mutual members voted to reform the claim assessment process with NMPIP-261. Our engineering team is in the process of finalizing the new claims contracts and will be updating our claims process in the next month.

The new claims model will rely on a set of permissioned claim assessors to review and validate claims. We will have a Claims Committee that will review and validate claims submitted for any of our public cover products (like Protocol Cover). The initial makeup of the Claims Committee will be three of our Advisory Board members: Hugh Karp, Roxana Danilla, and Lee McClelland. Claims Committee members will help claimants calculate their loss amounts, ensure all of the necessary information is included before a claim is filed onchain, and provide rationale for every claim decision that will be publicly available for anyone to review.

Claims History

The Mutual has paid out claims for major protocol hacks including:

To review Nexus Mutual’s claims history, you can see:

Allocating ARB for NXM Staking

Nexus Mutual’s Capital Pool cannot accept ARB directly to mint NXM. ARB would need to be converted to NXM by either:

  • Swapping ARB for ETH and using ETH to mint NXM through the Nexus Mutual protocol; or
  • Swapping ARB for wNXM, the wrapped version of the NXM token, and then unwrapping wNXM for NXM

From there, the NXM can be delegated to the proposed Arbitrum Aegis staking pool where it can be managed. Pool managers can stake with leverage, so $2M of staked NXM can create up to $4M in available capacity for a given listing if the pool weight for that listing is set to 100%.
When cover is purchased, 100% of the premium flows into Nexus Mutual’s Capital Pool (where all of the assets backing the NXM token supply are held) and 50% of the premium value is minted in NXM and streamed to stakers and the pool manager that underwrite the cover for the duration of the cover period and the grace period. In the event of a claim payout:

  • 50% of the claim amount is paid by burning the staked NXM and using the backing capital to pay the claimant(s); and
  • 50% of the claim amount is paid from the Capital Pool and socialized across all NXM holders.

Since all NXM holders see book value grow from premium earnings, they also bear some of the risk, with NXM stakers taking on more risk for greater returns in NXM rewards over time. NXM also sees value accrual from investment earnings and value accrual from automated NXM buybacks.

Pool management fees are streamed to the pool manager based on cover sales. There is no way to turn off management fees when the pool is not profitable other than reducing the management fee to 0% or manually sending the management fees back to the Arbitrum DAO during periods where the pool is not profitable.

A pool manager can stake up to 100% of the NXM in the pool against a single listing, and up to 20x leverage can be used in total if the pool manager were to allocate 100% weight to 20 different listings OR 50% weight across 40 different listings, and so on.

In the event multiple protocols are hacked at the same time and there’s concentration risk between those protocols (e.g., let’s say you’re underwriting Aave and several protocols have exposure to Aave in their Multi Protocol Cover listings, so one hack on Aave impacts several listings a pool manager is underwriting), a manager can lose up to 100% of their staked NXM based on underwriting exposure. If the NXM in the staking pool is insufficient to cover the total claim amount, the remaining liability would be socialized across all NXM holders.

If folks want to review current assets, liabilities, staking performance, and individual staking pool performance, feel free to review the Dune dashboards below:

Again, I’m happy to answer any other questions and provide color where needed to ensure voters make an informed decision.

2 Likes