Request for Proposal (RFP): Redemption and Reallocation of Nomad Collateral and Protocol Reserves for FRAX Market Enhancement

Request for Proposal (RFP): Redemption and Reallocation of Nomad Collateral and Protocol Reserves for FRAX Market Enhancement

Introduction

The Moonwell DAO is seeking skilled and trusted community members and contributors to submit proposals for the management of Nomad collateral redemption and protocol reserves reallocation. This initiative is a direct response to the liquidity challenges in the FRAX market on Moonbeam, and aligns with the community’s decision, as indicated in a recent Snapshot vote, to utilize both dormant Nomad collateral and protocol reserves for addressing these challenges.

Background

In collaboration with Gauntlet and Moonwell community stakeholders, the Moonwell DAO is seeking trusted community member(s) to redeem dormant assets impacted by the Nomad exploit and reallocate protocol reserves. This effort aims to bolster the liquidity of the FRAX market on Moonbeam, which has recently reached a 100% utilization rate, preventing some users from being able to withdraw their supplied assets.

Gauntlet has identified approximately $2.9m of FRAX tokens in the market as “bad debt”. Following the Nomad exploit in August 2022, .mad collateral assets depegged. Many positions borrowing FRAX against .mad collateral have a health score of < 1 and are technically liquidatable, but liquidations have not been taking place as they are in many cases not profitable for liquidators. Those who have supplied .mad assets and borrowed FRAX, GLMR, and/or xcDOT are also unlikely to repay their borrows, as they are now worth more than their underlying Nomad collateral. These positions can be viewed using the Gauntlet Risk Dashboard’s Account Explorer.

Through the passage of the Snapshot proposal “Options for Enhancing Liquidity in the FRAX Market on Moonbeam Snapshot proposal”, the Moonwell community has signaled their desire to utilize both dormant .mad collateral and protocol reserves to address this hole in the FRAX market. Gauntlet estimates the total value of both Nomad collateral and protocol reserves to equal approximately $2,766,142, or 95.38% of the total FRAX bad debt.

Nomad Collateral Available for Redemption

  • WBTC.mad: 41.83 BTC
  • USDC.mad: 10,723,922 USDC
  • ETH.mad: 2,201 ETH
  • Total Value: $2,300,154 (as per Chainlink prices on 2023-12-20)

Protocol Reserves

Assets: xcDOT, WBTC.wh, WETH.wh, GLMR, WETH.mad, USDC.mad, WBTC.mad, xcUSDT, USDC.wh

  • Total Reserve Value: $465,988.98 (as per Chainlink prices on 2023-12-20)

Scope of Work

This Request for Proposal (RFP) has been created with the aim of finding a trusted and capable contributor/community member(s) that can action on the Moonwell DAO’s desire to mobilize both dormant Nomad collateral and protocol reserves to address the liquidity challenges seen in the FRAX market on Moonbeam.

The selected contributor(s) will be responsible for:

Governance Proposal Submission

  • Submit Moonwell Improvement Proposals to:
    • Transfer Nomad collateral to a Moonwell community owned multisig.
    • Reduce_reserves and transfer to a Moonwell community owned multisig.
      • *Additional information about the community multisig can be found in the “Custodial Responsibilities” section below.

Recovery and Exchange Process

  • Follow the Nomad recovery process, including KYC and asset transfer protocols.
  • Complete KYC via the Nomad Recovery Portal. This verification can take up to 1–3 weeks.
  • Utilize the official Nomad redemption process to redeem Nomad assets by unbridging to Ethereum mainnet.
  • Exchange the redeemed Nomad assets and protocol reserves for FRAX and bridge to Moonbeam using Frax Ferry.

Liquidity Management

  • Use redeemed .mad assets and reserves to recapitalize the FRAX market.
    • *The RFP should be comprehensive and clear, providing all details regarding the preferred approach to recapitalization.

Proposal Requirements

Proposals will be evaluated based on expertise, feasibility, clarity, and completeness. The Moonwell community will make their final selection through Snapshot voting.
Interested contributors must submit a proposal including:

  • Background and Experience: Demonstrate experience in DeFi, liquidity management, and community governance.
  • Detailed Plan: Outline a step-by-step plan for asset recovery, exchange, and market recapitalization.
  • Risk Assessment: Provide an analysis of potential risks and mitigation strategies.
  • Timeline: Include a realistic timeline for each phase or milestone of the project.
  • *Fee (Optional): Proposed compensation for services rendered.

Submission Details

  • Deadline: Proposals must be emailed to contact@moonwell.fi by January 9th, 22:00 UTC.
  • Format: Proposals must adhere to the guidelines and satisfy all requirements.
  • Publication: Proposals will be shared as replies to this forum post shortly after the deadline to prevent plagiarism.

Custodial Responsibilities

Asset Custody

The custody of assets under this RFP is critical and demands careful handling. This responsibility should be entrusted to a specifically designated group of Moonwell community members. This group will oversee the assets via a multisig wallet, with the RFP winner serving as 1 of the 3 signatories. The second signatory will be voted on by the Moonwell community via Snapshot. The third signatory will be the Moonwell Pause Guardian multisig, acting as a fail-safe in case of key loss by other signatories.

Request for Signatories

If you would like to become a signatory on the Moonwell community multisig and help increase the DAO’s security posture during the RFP process, please express your interest by replying to this forum post with the following information:

  • Name/Alias: Your recognized name or alias within the community.
  • Motivation: Your reason for wanting to become a signatory.
  • Experience: Briefly describe any relevant experience or skills.
  • Community Contributions: Outline any past contributions to the Moonwell community.
  • Contact Information: Preferred method of contact (e.g., email, Discord handle).

Snapshot Vote

A Snapshot vote scheduled for January 10th at 15:00 UTC will enable the Moonwell DAO to choose their preferred proposal and multisig signatories. Only proposals and signatory requests that include all of the requirements listed above will be included in the Snapshot vote.

Additional Information

For further details on the state of the FRAX market on Moonbeam, Protocol reserves, and Nomad recovery process, refer to the linked documents and resources:

3 Likes

I volunteer to be a signatory for the multisig:

  • Name/Alias: CurlyBracketEffect aka Curly

  • Motivation: I am a long-time contributor and community member of Moonwell both on Moonriver and Moonbeam. I have been following the analysis of the issue as new information has become available and an action plan has been put together. I want to see the protocol recover from this and be a part of the team that implements the solution.

  • Experience: I have 6+ years in the crypto space. I have been a part of several multisig groups before. I know the importance of secure key management, and I would make sure to generate a fresh wallet in an offline environment to serve as this signatory.

  • Community Contributions: I participated in the $WELL token sale and have been staking in the security module ever since I got the tokens. I have also submitted 11 successful Reward Adjustment Proposals combined across Moonwell Apollo and Artemis.

  • Contact Information: You can reach me here on the forum, or on Discord: curlybracketeffect or via email: Daon2earth@gmail.com

6 Likes

Solidity Labs Proposal: Redemption and Reallocation of Nomad Collateral and Protocol Reserves for FRAX Market Enhancement

Overview

Solidity Labs would like to help restore liquidity to the Moonwell protocol on Moonbeam. We will do this by leveraging our deep knowledge of smart contracts, security tools, and our network of trusted security professionals.

Before diving into the proposal steps and approaches, it is important to describe the current state of the protocol, and what must remain true as these corrections occur. When a user’s collateral factor dips below 100%, as defined in the Comptroller, other users can liquidate them, closing up to the specified percentage of their position defined by the close factor, and repaying their debt. When a liquidation occurs, the liquidated user has their debt paid off, and the liquidator receives a portion of the collateral above the debt value as a bonus for taking this action. When Nomad was exploited, this normal liquidation process was circumvented as the collateral immediately lost 80% of its value, and the Chainlink oracles were oblivious to this change, preventing liquidations of positions that now had bad debt. In order to correct this, and put the protocol in the most correct state, the users with bad debt must be force liquidated by governance, have their collateral seized, and then liquidate said collateral with a multisig of trusted community members.

During this liquidation, there are protocol invariants that must remain intact. Total borrows must equal the sum of all user borrows, total supply of mTokens must equal the sum of all user mToken balances, and the exchange rates for each affected mToken must remain constant. Keeping these invariants intact is crucial to the success of the proposal and the health of the protocol.

Trusted Signer

In order to facilitate the seamless execution of the liquidation of Nomad assets, a member of the Solidity Labs team will be on the multisig wallet for the recovery effort. The team has been on many multisig wallets before and executed parameter changes, swaps, governance actions, and recovery efforts during war rooms. A fresh wallet will be created with high-security standards to avoid compromise.

Existing Bad Debt and Collateral

There are currently 81 accounts with bad debt. The following table describes the borrowed assets that will likely never be repaid, and the corresponding non-nomad supplied assets that can be seized.

Token Seizable Supplied Assets (non .mad) Borrow
FRAX 0.0028 3,015,166.39
xcDOT 3.71 493,252.97
GLMR 30,318.68 5,333,685.56

Solidity Labs will work closely with Gauntlet and Moonwell delegates like @Curly to adjust Interest Rate Models and incentives. This is needed to ensure supply rates are unchanged as both supply and borrow rates will decrease from the bad debt write-off in impacted markets. The FRAX market will see negligible rate changes as the recent Gauntlet proposal moved the interest rate model to a maximum of 1%. However, xcDOT and GLMR will see decreases in rates for both suppliers and borrowers as the total borrows decrease, lowering utilization.

Paths Forward

This post describes at a high level the actions that the Moonwell community will need to take to recover the Nomad assets and restore liquidity. Two paths forward will be proposed, each with its own set of tradeoffs around speed, and thoroughness. The more thorough proposal will take longer, involve more risk, and solve the underlying issues as best as possible. While the less thorough proposal will take less time, involve less risk, and not fully address the underlying issues.

Standard Approach

In order to stop bad debt from further accruing interest, the accounts with bad debt must be manually liquidated. The mToken implementations must be updated to allow a privileged actor the ability to write off liabilities of accounts with bad debt to zero. These accounts will then have their collateral transferred to a trusted address. All of these actions must take place while still preserving the core protocol invariants. However, once the bad debt is subtracted from the user balances and the total borrow amount, the exchange rate of the mToken will change. This means new mToken contracts will need to be created which preserve the rates across time and continue accruing even after the bad debt has been written off.

Once these accounts have their assets and liabilities written off, it will cause a downward change in both supply and borrow rates for the GLMR and xcDOT markets as the losses are realized. To manage this, Gauntlet will need to make a recommendation of the new Interest Rate Model for markets affected by these write-downs.

Comptroller Fixer Contract

This fixer contract will allow the timelock to pass an array of users. This array of users will then be iterated over, and for each user, each mToken they possess will be iterated over, and if they have a supply or borrow balance, call into the mToken contract and zero that users’ associated borrow balance, and send all corresponding supply mToken balance to the community multisig.

mToken Fixer Contract

The Comptroller can call the fixUser function on the mToken Fixer, which will zero a user’s borrow balance, subtract the previous balance from the totalBorrowBalance, and send the users’ mToken balances, to the community multisig. Each amount of borrowed balance written off will be added to another state variable that will be added to the current cash of the contract. This will ensure the key protocol invariant remains intact and the exchange rate of the markets with bad debt does not reprice downwards as this debt is written off and the corresponding amount of cash is not returned to the market.

Formal Verification

In order to verify that the upgrade and liquidate proposal does not violate the core invariants of the Moonwell Protocol, Solidity Labs can write formal specifications and rules for the updated Comptroller and mToken Fixer using the Certora Prover to demonstrate the new code does not violate any protocol invariants.

Storage Slot Clashes

In order to verify the proposed changes do not write to storage incorrectly, storage checking tools will be used to ensure that the offsets of the mToken Fixer contract are not different from the existing code. This layer of testing will give us and the community confidence in the correctness of the proposal and code before going to the audit stage.

Integration Testing

These changes to the protocol are nontrivial and will require significant modifications. In order to ensure these changes do not cause further issues, significant integration testing will be done to verify the correctness of the codebase after the upgrade and governance proposal. Testing types and assertions include but are not limited to:

  • Application of Forge Proposal Simulator tool which has been developed to ensure the safety of all types of governance proposal changes.
  • Check that no account health factors change after each proposal, except for the accounts that are being liquidated.
  • Assert liquidated accounts have no mToken balance.
  • Validating no configuration changes inside the Comptroller occurred.
  • Ensuring no balance change occurred, except in the specified accounts to be liquidated.
  • Verifying that the multisig received both the Nomad collateral and all other mToken collateral from accounts with bad debt and reserves.

Multisig Simulation

All multisig actions that require interacting with Moonwell contracts will have calldata programmatically generated using the Forge Proposal Simulator. Additionally, integration tests will be created to ensure that each action the multisig takes that interacts with the protocol is correct.

Peer Reviews and Auditing

Before proceeding, our trusted network of security researchers, engineers, and advisors will review our specifications and code to ensure the intended outcome of the proposal for all parties and actors in the system. Due to the technical complexity of this approach, we will engage in two audits, the first with Halborn and the second with Code4rena. Code4rena will perform a governance proposal audit to ensure the safety of the proposal.

Proposals

Because of the complexity of these operations, two governance proposals will need to be passed to complete the write-down of these accounts. After these proposals are executed, the trusted community multisig will need to be used to perform actions relating to exchanging certain cryptocurrencies for others and bridging the Nomad assets back to mainnet. Solidity Labs will advise and review these proposed actions, ensuring funds are not lost during this crucial time.

Proposal 1

Currently, the maximum number of actions a proposal can execute is 25. However, this will need to be increased in order to handle the sheer volume of actions that will be required in order to fix the bad debt accounts in proposal 2. This proposal will increase the maximum number of proposal actions to 1,000 so that future proposals are not bottlenecked on the number of actions they can take. During this proposal, all Nomad reserves will be transferred to the community multisig. This will allow the KYC process to begin before the second proposal has taken place.

Proposal 2

This proposal will remove all collateral mTokens from users with bad debt from all markets, sending them to the community multisig. In order to allow mToken collateral sweeping and bad debt write offs, the mTokens will have their implementations upgraded. This will stop further issues and to allow the exchange rates of the assets to stay the same post proposal. Interest Rate Models may need to be changed in order to stop rate spikes due to changes in supply and borrow amounts.

Post Proposal 2

The community multisig will redeem the mTokens for their corresponding amounts of Nomad and underlying assets. If there are any non-nomad underlying assets such as GLMR, will be added to the reserves. Any Nomad assets will go through the recovery process and be swapped to FRAX on mainnet and bridged back to moonbeam where they will be added as reserves to enhance market liquidity.

Alternative Approach

Instead of fixing the bad debt with a contract that will manipulate storage, and stop it from accruing further interest, there exists a simpler path. This solution involves only pulling the Nomad collateral from the mToken, and letting the bad debt in both xcDOT and GLMR markets continue accruing. With this solution, most of the FRAX bad debt can be repaid on behalf of the borrowers with bad debt. Taking this course of action will allow further accrual of ~49,000 xcDOT and 320,000 GLMR in interest per year at current rates from existing bad debt.

This approach has much less technical risk and involves less custom code. It may be possible to handle all of the governance steps for this proposal in a single governance proposal. However, with such a low amount of actions per proposal in the current governor, and the code not yet written, it may require a second proposal to complete. With this approach, liquidity will be restored more quickly to the FRAX market, while still allowing further bad debt to accrue in both the GLRM and xcDOT markets.

Comptroller Fixer Contract

The alternative approach will not require the Comptroller Fixer contract to function as individual and global values for each mToken will not be updated.

mToken Fixer Contract

An upgraded mToken implementation will be needed, but only for the duration of the proposal. Before proposal completion, the mToken logic contract for each respective .mad asset will be swapped back to its original implementation.

Formal Verification

Formal verification is not needed for this approach due to the ephemeral nature of the upgrade.

Storage Slot Clashes

Storage slot clashes will be checked in this proposal. However, due to the ephemeral nature of the upgrade, and not writing to storage, this is not a security concern.

Integration Testing

In order to ensure these changes do not cause further issues, Solidity Labs will engage in significant integration testing to verify the correctness of the codebase after the governance proposal.

  • Application of Forge Proposal Simulator tool which has been developed to ensure the safety of all types of governance proposal changes.
  • Check that no account health factors change after each proposal.
  • Assert that no configuration changes inside the Comptroller occurred.
  • Validate no balance change occurred, except in .mad mToken underlying balances.
  • Verify the multisig received the Nomad collateral and reserves.

Multisig Simulation

All multisig actions that require interacting with Moonwell contracts will have calldata programmatically generated using the Forge Proposal Simulator. Additionally, integration tests will be created to ensure that each action the multisig takes that interacts with the protocol is correct.

Peer Reviews and Auditing

Before proceeding, our trusted network of security researchers, engineers and advisors will review our specifications and code to ensure the intended outcome of the proposal for all parties and actors in the system. Halborn will be engaged to audit this proposal.

Proposal 1

Currently, the maximum number of actions a proposal can execute is 25. However, this will need to be increased in order to handle the volume of actions that will be required. Actions include upgrading the mTokens, sweeping the underlying, and returning the implementations back to their original contracts. This proposal will increase the maximum number of proposal actions to 1,000 so that future proposals are not bottlenecked on the number of actions they can take. During this proposal, all Nomad reserves will be transferred to the community multisig so that the KYC process can begin before the second proposal has taken place.

Proposal 2

This proposal will remove all nomad assets from nomad mTokens and send them to the community multisig. After all mToken collateral has been swept to the community multisig, the mTokens will have their implementations changed back to the old mToken implementations to avoid further issues. Interest Rate Models may need to be changed after this proposal to stop rate spikes after borrows are repaid.

Post Proposal 2

The community multisig will redeem the mTokens for their corresponding amounts of Nomad and underlying assets. If there are any non-nomad underlying assets such as GLMR, they will be added to the reserves. Any Nomad assets will go through the recovery process and be swapped to FRAX on mainnet and bridged back to moonbeam where they will be added as reserves to enhance market liquidity.

Timeline

Executing the standard approach is estimated to take seven weeks from proposal start to finish. Executing the alternative approach is estimated to take five weeks. In both proposals, Solidity Labs will immediately submit KYC documents to the coinlist Nomad recovery site as this process is estimated to take between one to four weeks.

Standard Approach

Action Estimated Time
Nomad KYC 1 - 4 weeks, non blocking
Proposal One 1 week
mToken and Comptroller Upgrade 2 weeks, non blocking
mToken and Comptroller Upgrade Review 2 weeks, blocked on upgrade
Proposal Two 1 week, blocked on mToken
Nomad asset recovery and swaps 1 week, blocked on proposal two and KYC
Total Time 7 weeks
  • Proposal one will increase the proposal count and pull the nomad reserves. This will take one week.

  • Writing and modifying the mToken and Comptroller to pay off the bad debt. This will take at least two weeks. Once completed, it will require at least two weeks of review from auditors and external security researchers.

  • Proposal two will be ready to submit on chain at week five, there will be a one week window for voting, completing in the sixth week. The KYC should have been completed, and the assets will be able to be unbridged from Moonbeam back to ethereum mainnet where the Nomad assets can be claimed. A separate multisig wallet will be created on mainnet with the same signer set so that the Nomad assets will be in the multisig at all times.

  • Underlying assets will be claimed on Ethereum mainnet and swapped for FRAX. This FRAX will be bridged back to Moonbeam using the FRAX Ferry. This phase is expected to take another full week.

  • All of the assets will be bridged back to Moonbeam and added as reserves to the market to boost liquidity.

  • Total Proposed Time: seven weeks

Alternative Approach

Action Estimated Time
Nomad KYC 1 - 4 weeks, non-blocking
Proposal One 1 week
mToken Creation 1 week, non-blocking
mToken review 1 week, blocked on mToken creation
Proposal Two 1 week, blocked on mToken review
Nomad asset recovery and swaps 1 week, blocked on proposal two and KYC
Total 5 weeks
  • Proposal one will likely need to increase the proposal count and will have to pull the nomad reserves. This will take one week.

  • Creating the mToken that will allow the transfer of all Nomad collateral to the multisig is expected to take one week to write, and once completed, will require one week of review from auditors and external security researchers.

  • Proposal two will be ready to be submitted on chain at week three, there will be one week for voting, completing in the fourth week. The KYC should have been completed, and the assets will be able to be unbridged from Moonbeam back to ethereum mainnet where the Nomad assets can be claimed. A separate multisig wallet will be created on mainnet with the same signer set so that the Nomad assets will be in the multisig at all times.

  • Underlying assets will be claimed on Ethereum mainnet and swapped for FRAX. This FRAX will be bridged back to Moonbeam using the FRAX Ferry. This phase is expected to take another full week.

  • All of the assets will be back on Moonbeam and can be added as reserves to the market to boost liquidity.

  • Total Proposal Time: five weeks.

The total amount of time required to complete the standard approach is seven weeks. If the alternative approach is taken, it will take two weeks less because less code will be written and fewer reviews are needed to ensure the safety of the proposal.

Tradeoffs and Risks

There exists no perfect solution to the problem as defined by the RFP. Both proposed solutions exist in a tradeoff space of speed and correctness. The standard approach is the most correct, but it comes with additional risk. The alternative approach is the least correct but restores liquidity faster. Our goal in writing this document is to enumerate the paths forward and allow the community to decide which path is best for them.

The standard approach outlined throughout this document carries increased smart contract risk around the upgrade, which could cause further issues. However, this risk will be mitigated by extensive integration testing, internal security reviews, formal verification, auditing, and review by other experts of Compound V2-based lending protocols. This standard approach stops additional interest from accruing and fixes these markets, at least from an interest accrual perspective.

If the alternative approach is taken, there is much less smart contract and execution risk. The mToken contracts will remain unchanged after the collateral is withdrawn from the markets. No patching of mTokens will need to occur to preserve key protocol invariants. Less governance proposal actions will need to be taken to restore additional liquidity to the markets. This method is less risky, however it fixes less of the underlying problem than the standard approach.

Our Experience With Moonwell

Solidity Labs helped Moonwell’s launch on base. This project included testing the MultiRewardsDistributor, uplifting the smart contracts to version 8 of Solidity, upgrading existing staking infrastructure, building governance tooling for cross-chain governance, and building the new TemporalGovernor Cross-chain governance primitive. We recently completed the xWELL token, which turns Moonwell into a native multichain token. All of these past experiences working together have given our team an in-depth understanding of both the current protocol contracts and the future direction of the Moonwell Protocol.

About Us

Solidity labs is a boutique consulting firm specializing in smart contract development and security. Our team is composed of engineers who have decades of blockchain and security experience. Smart contracts developed by our team have held billions in assets and have never been hacked. We have participated in and helped over 10 projects deliver their smart contract systems from idea to implementation. Additionally, we have helped create and audit four different bespoke lending protocols, giving our team an intimate understanding of the problem space and the ability to reason through the consequences of changes in complex systems like Moonwell. At Volt Protocol, we audited the Compound V2 codebase, and identified a critical vulnerability that was eventually patched.

The key insight that led to the founding of our firm is the realization that DeFi and smart contract projects increasingly need to shift left on security. Security doesn’t start once development is complete, it is a journey throughout the development process and requires developers to be vigilant and up to date on the latest exploits. To further that end and help projects shift left, we have built a custom proposal simulation framework that can be applied to enhance and ensure the security of these upgrades and offer continuous security reviews for our clients. This framework is currently being used to help secure Moonwell and makes governance proposal generation and simulation, fast and secure.

We would appreciate the support of the Moonwell community to vote for our team as we have invested significant energy into figuring out how to resolve this issue. We will apply the same rigor to executing these governance proposals as we did specifying them and will utilize every resource at our disposal to ensure this recovery is executed in a safe and secure manner.

4 Likes

It’s great to see such a solid RFP response from Solidity Labs. Thank you for your contributions.

4 Likes

Moonwell Community,

As the submission period for our recent Request for Proposal (RFP) has now closed, I am writing to update you on the next steps in the Moonwell community’s initiative to address the liquidity challenges seen in the FRAX market on Moonbeam.

Selection of RFP Proposal
We have reviewed the submissions and received a single RFP proposal (posted above). Given this context, we will forego the Snapshot vote initially planned to select the RFP winner. I’m pleased to announce that Solidity Labs, as the sole respondent, has been chosen to lead this pivotal project. Their smart contract expertise and meticulously detailed plan align with the Moonwell community’s goal of utilizing protocol reserves and dormant Nomad assets to enhance liquidity in the FRAX market on Moonbeam.

Community Multisig Signatory Appointment
In parallel, we sought volunteers for the vital role of community multisig signatory. We have also received one application for this position. It is with great pleasure that I announce @Curly as the chosen community multisig signer. His valuable contributions, particularly his regular submission of important reward speed MIPs, exemplify his dedication to and understanding of the Moonwell community and protocol.

Next Steps
As the RFP winner, Solidity Labs will now be driving this initiative. Their proposal outlines two distinct strategies. To ensure community involvement in this critical decision, it may be wise to replace the initial RFP selection Snapshot with an alternate Snapshot vote to determine which of the two paths presented by Solidity Labs in their proposal should be pursued.

Once again, we would like to extend our gratitude to Solidity Labs and @Curly for stepping forward into these crucial roles and to the entire Moonwell community for your ongoing engagement and support.

4 Likes

Solidity Labs has submitted a Snapshot! Snapshot

It’s great to be involved, and we hope the community chooses an options that restores liquidity to the markets!

2 Likes

It’s great to see the community voting to move forward with the redemption of the Nomad collateral!

The Snapshot has reached quorum with over 18m WELL turning out to vote! The option to proceed with the standard approach had near unanimous support with 95.9% of voters choosing the standard approach with Curly as a signer.

Following the passing of this signaling snapshot, a multisig was created on Moonbeam with a 2/3 proposal threshold, with Curly, a signer from Solidity Labs, and the pause guardian as the final signer. The pause guardian will act as a failsafe in case a community signer can no longer provide signatures.
Owners can be viewed in the moonbeam safe app.

Following this ratification, a governance proposal will be submitted for the first proposal to both raise the maximum actions in the Moonbeam Governor, and sweep the nomad reserves to the newly created multisig.

Calldata creation for the proposal will be posted to the chain by Wednesday of this week, enabling the signaling snapshot vote to be ratified by the DAO onchain.

3 Likes

The first proposal is live on Moonbeam, please take a look at the proposal!

1 Like

Just wanted to drop in and give an update for the community on the redemption process.

KYC has been submitted and cleared for the CoinList platform, however we are still awaiting their response for Nomad KYC Recovery.

Development has started on the mToken fixer contracts. You can follow along in this repository. Due to the fact that mGLMR is non upgradable, the bad debt in this market cannot be written off using the fixer contract. However, proceeds from the liquidated Nomad collateral will still be used to restore liquidity and repay bad debt in the Frax market.

4 Likes

Thanks for the update!

2 Likes

Hey fellas,

Does ayone know when it’s likely for liquidity to be restored to the FRAX pool on Moonbeam ? I’m probably in the same boat as other users who are trapped and can’t exit the pool due to the liquidity issue you’re trying to fix. There was no warning or note anywhere this was likely to happen due to the bad debt originating from the Nomad hack.
Any help would be much appreciated.

Thanks

1 Like

I just wanted to give everyone an update on the progress of the Nomad Recovery process. This is a complicated and highly technical upgrade that involves altering core parts of the protocol. Additionally, we had been blocked for some time on the Nomad KYC process, but now things are looking up as I’ll get to later.

Extensive integration testing has been performed to demonstrate the continued functioning and health of the protocol after the upgrade. We engaged the previous lead engineer at Compound to review our design and contracts and no issues in the approach were found.

Considerable amounts of time were spent fighting the tooling in the early stage of the development process. This is due to the precompiles that are used on Moonbeam not playing nice with foundry. Our team is past these issues now and we have moved on to formal verification.

The entire proposal has been gas benchmarked with both proposal and execution transactions coming in under the 13m gas per transaction limit.

The coinlist KYC process has also turned out to take longer than expected. However, we have engaged them directly and are in contact with their team to get the Nomad KYC NFT. It would be surprising if we did not receive the expected KYC and corresponding NFT in a timely manner.

Outstanding questions revolve around the necessity of a multisig on mainnet with the same address as the one on Moonbeam and if wallet connect is supported on the recovery UI. If it is not, we’ll need to craft the calldata programmatically.

We will keep the community updated as the pieces keep falling into place.

3 Likes

Thanks for the update, elliot! I’ll keep an eye out for when it’s all going to be finally sorted as I believe a number of users (such as myself), are now effectively trapped in and can’t withdraw our tokens.

Keep up the good work.

1 Like

Today’s Progress Update:

Solidity Labs held an hour long internal review of the MErc20DelegateFixer and uncovered and fixed an issue around the total borrows of liquidated users not being up to date, which could cause slight discrepancies around the bad debt variable not being as large as it should be. This would have broken invariant sum of all user borrows equals total borrows. Additionally, the liquidator could have potentially been the same user being liquidated, which would have broken the invariant that the sum of all user balances must equal the total supply. In practice, this never would happen as the only user able to call these functions is governance, which is trusted, however, this can create additional issues when writing formal specifications. Another change made is that users can not be liquidated if they have no borrow balance on that market. This prevents a malicious governor from incorrectly liquidating users without borrows. A malicious governor could still liquidate a user with good debt, however this will not happen as the governance proposal will be checked multiple times. Gas optimizations were discussed, however the tradeoffs with optimizing gas meant more complex code, and the team opted to keep the contracts as simple as possible to minimize the chances of errors.

The following addresses were removed from the liquidation:

remove 0xB3E6420941AcC44C2996666b4B5C998C1545fc19 from mFRAX liquidation (no mFRAX borrows)
remove 0xA5D20094Cf1Bc45B6FF1eB3B5A828865C1E8d583 from mFRAX liquidation (no mFRAX borrows)
remove 0xcD111815A4Acb5355E137B2aae6Ec3E043D57ce9 from mxcDOT liquidation (no mxcDOT borrows)
remove 0x57e421c8a16bf0a609ef87e296cb931113a5e3ed from mxcDOT liquidation (no mxcDOT borrows)

See commits for these changes here.

Formal verification work has started. The key question we would like an answer to is, for all states the contract can be in, can the share price never be impacted by calling any of the new fix functions (assuming accrue interest has been called in the same block). I’ve started taking a look at the formal specifications written for Compound V1 to see if there is anything that can be reused, however that was written using CVL-V1, which is not the same as CVL-V2.

A Safe has been created on mainnet with the same address and owner set, the keys will be rotated so the non-existent msig will be removed as a signer, with another signer being swapped in before assets are held at this multisig address Safe{Wallet} – Settings – Setup

The Coinlist team is working as fast as possible to KYC the multisig wallet so that funds can move across the bridge once the governance proposal goes through.

Potential blockers: Moonbeam safe app does not work with wallet connect. This could cause an issue with bridging Nomad assets from Moonbeamå back to Ethereum mainnet using the multisig. A potential mitigation would be to have a trusted community member unbridge assets using an EOA, redeem those Nomad assets on mainnet for their corresponding underlying tokens, and then send the underlying to the multisig.

The multisig on mainnet would then swap all assets into FRAX, and then use the Frax ferry to move assets from Ethereum mainnet back to Moonbeam. Once the assets are back on Moonbeam, they will pay back the FRAX bad debt.

It is looking increasingly likely that an EOA will need to move assets across the bridge and redeem them for their underlying value. I would recommend the community vote on who this person should be.

Whoever would like to step forward for this role, they should be:

  1. Verifiably Doxxed
  2. Known and trusted in the Moonwell community and by our core contributors
  3. Residing in the United States and holding U.S. citizenship
  4. Demonstrably invested in Moonwell’s success, with tangible stakes at risk

I will nominate myself for this role and encourage others who meet these criteria and are willing to nominate themselves to step forward.

3 Likes

Thanks for the update, sounds like things are progressing quite well.

Hopefully all the issues can be fixed soon and the pool goes back to normal.

Will keep an eye out for the next update.

3 Likes

Just wanted to drop in and give the community another update.

The code has been frozen, and the readme updated to show auditors the files in scope, as well as the ways they can run the integration tests, formal verification, deployment scripts, and governance proposal calldata generation.

I have started the process of finding a platform for code competitions and contacted multiple platforms that specialize in this field.

Another internal security review at Solidity Labs will be scheduled on Monday, and we will reach out to our network of security researchers to try and get at least an hour long review on the books with an external security researcher before we go to the code competition.

3 Likes

Another update, a few more tests have been added in this PR Additional tests and specifications by ElliotFriedman · Pull Request #8 · moonwell-fi/mtoken-fixes · GitHub

Two additional reviews were conducted this morning with no issues flagged.

One was with an engineer internally from Solidity Labs, where we walked through the code and realized we should add additional tests around the cash function.

The previous review was with an external security engineer where we reviewed the MErc20DelegateFixer contract as well as the formal specifications.

Because these reviews came back clean, we are officially code frozen and are receiving quotes from different auditing firms for a contest that will kick off on the 4th of March and last for a week.

3 Likes

Codehawks has been selected to be the audit competition platform for these changes. You can find more details on the contest here. The competition will start on the 4th of March and conclude after 7 days, at which point it is expected to take between 1-2 weeks to gather and report back on the findings.

4 Likes