Proposal: Nexus Covered Vaults (Discovery Phase)

Governance Discussions Nexus Mutual DAO Proposals
1

Summary

We propose to design an ERC-4626 compliant vault that takes an existing ERC-4626 compliant vault (e.g. Yearn) and purchases Nexus Mutual coverage on behalf of all users, with coverage effectively being paid from the yield. A bundled yield-bearing plus covered vault.

Motivation

  1. Purchasing and managing coverage on an ongoing basis can be cumbersome due to the need to roll over and/or change coverage amounts.
  2. Gas for cover purchases effectively means it’s not economically viable for smaller users.
  3. Bundled products have much higher take-up rates due to the reduced user friction.

Project Description

To minimize technical implementation risks for this project, we propose a step-by-step delivery approach including the following stages.

The current proposal will focus only on Phase 1 (Discovery & Planning). Development and testing of the complete solution will be a separate proposal, and its budget and duration will be determined at the end of phase 1.

Phase 1: Scope definition & project planning

  • Business, functional, and technical requirements analysis
  • Technical feasibility assessment
  • High-level specs
  • Project planning (efforts, ideal team, timelines, and engagement terms)
  • Prototype (if needed)

Phase 2: Iterative development

  • Solution architecture design
  • UX/UI design (if needed)
  • Infrastructure preparation (if needed)
  • Sprint-based development according to the project plan.

Phase 3: User acceptance & transition

  • Pre-production core team acceptance testing
  • Help with smart contracts deployment
  • Deployment success assessment
  • Further development planning, if any

Goals

  1. Define use cases.
  2. Collect and analyze business, functional and technical requirements.
  3. Analyze technical feasibility & viability.
  4. Identify risks and propose a mitigation plan.
  5. Create a high-level design and specs.
  6. Create the project plan (delivery timelines, combined resources, efforts, milestones, and future engagement terms).

Deliverables

  1. Product Definition Document covering business, functional and technical requirements.
  2. Action plan: technology validation, recommendations on roadmap, milestones, scope, and effort estimates.
  3. BootNode engagement proposal to create a synergetic incentive alignment mechanism (stables and tokens considerations. Goals and KPIs).
  4. If required and time allows, we can also create a prototype.

Development Roadmap

This project should take around 5 weeks of analysis, design, and prototyping. If this discovery phase is successful, it should be followed by a second phase for development (not included in this proposal).

Milestones 1: Analysis

Description: Gather all required information, analyze the problem and alternative solutions, discuss with the team (both BN and Nexus Engineers) and choose the best option.
Duration: 1-2 weeks

Milestones 2: Design

Description: Complete the solution design. This includes smart contracts architecture and integration design.
Deliverables: Documentation with all required specs, diagrams, and other types of designs required to build the desired solution.
Duration: 3 weeks

Milestone 3: Prototype (optional)

Description: If time allows, the proposed design will be implemented in a simplified way that could prove its feasibility and be used as a baseline for further development.
Deliverables: Working smart contracts in testnet.
Duration: 3 weeks

Scope and Times considerations

This is a time-boxed proposal. If deliverables are shipped earlier, the team will continue working on other tasks. However, if the time is not enough to finish all deliverables, there will be a clear plan for the next steps.

Budget

To be paid in stablecoins:

  • 32,000 USDC (or other stablecoin).
  • 50% (16,000 USDC) as soon as the proposal is approved, 50% (16,000 USDC) once the deliverables are presented for review.

Resources

  • 1 Solidity Engineer: 5 weeks
  • 1 Part-time PM and Business Analyst: 5 weeks

Team

Contact Info

Website: https://www.bootnode.dev/
Email: [email protected]
Telegram, Github, Twitter, Forum, etc: @leolower

Team Members

  • Leo Lower: Co-founder and CTO of BootNode
  • Gerardo Nardelli: Solidity Engineer at BootNode

Relevant Experience

BootNode is a software engineering studio that specializes in decentralized infrastructure, protocols, applications, and ecosystems.

Founded by a team of engineers with an average of 10+ years of experience building and shipping highly available, highly-scalable software for many industries and 3+ years for the blockchain ecosystem in particular.

Our mission is to provide unique and scarce resources to organizations changing the future of humanity through decentralized technologies.

Our vision is to become an essential and critical partner that enables these organizations to fulfill their mission.

We have contributed to countless organizations developing their blockchain applications, from ideation to massive adoption, applying proven UI design to React dapps, from protocol and architecture design to Solidity smart contracts, relayers, backends, subgraphs, and integrations. We work the full-stack and pay special attention to product development, not just application programming.

Our engineers have participated in some of the most popular DeFi platforms and this has exposed us to all the different money legos. We can help you build on top or integrate down to any of these protocols.

We have also successfully delivered this proposal to Nexus Mutual: Proposal: MEV protected swaps

3 Likes
2

Thanks @leolower !

Strong support from me on this. Bootnode worked really well with our core devs to build the swap operator functionality (currently in audit with the rest of the v2 release) and have a good understanding of the Nexus code base.

Continuing the relationship by working on another high value periphery feature makes a lot of sense and helps with our biggest bottleneck, dev resource.

2 Likes
3

Highly supportive of this

1 Like
4

I think this is a great idea and Ease actually did this last year if you want to borrow from our legwork/code there GitHub - EaseDeFi/arShield | arShield - Google Docs. Only reason it’s been sunset is because we moved full focus to our Uninsurance model. I think coverage-wrapped tokens will play an enormous part in the DeFi coverage industry wherever they can be used, so this could be great for Nexus.

Use as much of our code as you can, but a lot will probably have to be reworked since it was before ERC-4626 and it was functioning off the arCore system which has since been sunset.

Technical Difficulties:

  1. Must protect against tomfoolery by people who could deposit a lot just to get you to buy extra coverage and have everyone in the vault pay too much.
  2. Must protect against scenarios in which users could buy hacked tokens cheap then enter the vault to try to share in the payout on previous value (depending on how your system works).
  3. Protocols may need a unique vault for each depending on whether they have farming/staking of their own, and rewards from that functionality will somehow need to be liquidated. If a protocol has extra rewards that won’t be able to be received in a Nexus-covered vault that’ll be a huge disincentive to enter.
  4. If the yield on a token drops a user could end up paying more for coverage than yield without realizing it.
  5. Figuring out oracles to liquidate tokens for coverage purchasing could be a bit of a pain. We started working with Umbrella network who I would suggest. They can easily add value of yield-bearing tokens (such as Yearn) so decentralized oracle functionality won’t be needed for each protocol. Other option could be to sell directly on dexes but that could require more cost in upkeep of the system and may also need unique functionality for each protocol for unwrapping then selling.

Less-obvious Benefits:

  1. Can create stacked risk vaults such as purchasing convex and curve coverage at once.
  2. Although I don’t know how much you’d want to go into risk management, there’s an amount of safety added by diversifying protocol coverage over a number of different vaults, so it’s theoretically safe to buy only partial coverage. Make sure users know the exacts if you do this though.
  3. If #3 is needed above, there’s a big UX (and even tax) benefit to users if you cash out rewards for them and either sell to underlying or purchase coverage.
  4. Godly UX if you add zapper and users can enter directly with Ether.
  5. Integration on checkout with protocols is made super easy if it’s essentially just one more zap that needs to happen to make it a fully-covered token. As easy as a checkbox to get covered if everything’s setup smoothly.

Ideally we end up living in a DeFi where users enter the space into a coverage-wrapped token almost without realizing it.

2 Likes
5

Thank you @robert! You bring up some very important points that I’m sure we will have to figure out very soon, so I’m glad you guys already gave it some thought.

And thank you for sharing your implementation! We will definitely use it as inspiration although ours will most likely be different, as you mentioned because it uses ERC-4626 but also because we will target Nexus v2 directly.

This design and future implementation will also be open source, of course.

Happy to discuss further if you’d like.

2 Likes
6

I’m highly supportive of this effort as well, as covered vaults would allow more users to have seamless protection against risk. Adapting to the ERC-4626 standard is also an important step for the mutual, and the BootNode team has been a greater partner to the mutual in their previous grant work.

Looking forward to voting in favour on this vote!

2 Likes
9

This proposal has been transitioned to a Snapshot vote, which will be open for voting from 1 August at 1pm EST / 5pm UTC to 6 August at 1pm EST / 5pm UTC.

2 Likes