Bug Protection Protocol Scope and Overview

Bug Protection Protocol

The following is an early draft of a project overview for the Bug Protection Protocol. It presents a scope of work, preliminary budget projections, and outstanding questions.

It should especially be noted that budget projects are subject to change considerably. Particularly as we develop a framework for full-time contributors, much of this may fall under their contributions. However, it’s also important to create potential frameworks for those interested in contributing to a specific project on a contract basis. More to come on this front.

What you can do right now: We plan to release a Medium article and “Coming Soon” landing page in the next week. We need to develop ideas and reach consensus around fundamental branding like name and logo. Visit the discord channel to join the discussion: https://discord.gg/PWJaU4D


You can view the most recent spec here. The Bug/Hack Protection Protocol (name TBD) is a protocol designed to let those with confidence in the security of a protocol earn yield and those concerned about a bug or a hack to gain access to upside exposure in such an event. If such an event were to occur, a claim would be submitted and the arbiter would rule on its validity, paying out the entire protection pool to those with active coverage.

Scope of Work

Smart Contract Development:

Protocol Contracts:

  • Factory for pool creation
    • The factory is the creation mechanism for new coverage pools
  • Protection Pool
    • The protection pool holds underwriter funds and premiums paid by protection buyers. In the event of a valid claim, all funds in the protection pool will be paid out to active coverage buyers.
    • One of the pieces to this pool is the pricing curve for coverage. This will be based on a curve related to Active Coverage Amount / Total Protection Pool Funds and will require significant modeling.
  • Premiums Pool (optional)
    • The premiums pool holds the amount of each protection premium that is sent to be immediately redeemable by underwriters.
    • This is an optional pool, as it may make more sense to simply send all premiums to the protection pool. Underwriters’ pro rata holdings in the pool would grow with those premiums, and would be redeemable through the withdrawal process.
  • Yield Farming (optional)
    • If we choose to provide liquidity incentives to bootstrap the protocol, either via a new governance token or YAMs, this contract would provide those incentives
    • Users would likely be able to receive incentives for providing or buying coverage
      • We would want to create the incentives to align with long-term value accrual, likely providing a bonus the longer you provide/buy coverage.

Token Contracts:

  • Underwriter token

    • This token represents a percentage ownership of funds in the protection pool, as well as determines a percentage claimable from the premiums pool. Underwriters would be able to withdraw their funds from the protection pool at any time, but the withdrawal process will include a 30-day lockup period.
  • Protection token

    • This token represents the size and duration of protection and be an NFT. Following expiry, the token has no utility.
  • Governance token (optional)

    • This token would potentially be used to govern the protocol in the future, following network and community stability.

Design and Front End Development:

  • General Branding
    • Protocol Name
    • Token Names
    • Logo
  • Design/Aesthetic
    • Keep general Yam design or new aesthetic
  • Front-end Development
    • Landing page with summary
    • App
      • Provide Protection interface
      • Buy Protection interface
      • User Dashboard (Current provided/bought coverage)
      • Protection pool stats
      • Testing infrastructure


  • Documentation
  • Copywriting
  • Explanatory blog posts
  • Contest for first covered protocols?
  • Memes
  • Community Management


  • An audit would be necessary to increase the security of the protocol.

Preliminary Budget - Subject to several factors

  • Smart contracts
    • Time Estimate: 5 engineer-weeks
    • Rate: $10,000/engineer week
    • Cost: $50,000
  • Design/Front End
    • Time Estimate: 5 engineer-weeks
    • Rate: $5,000/engineer week
    • Cost: $25,000
  • Communications
    • Time Estimate: 5 weeks
    • Rate: $2,000/week
    • Cost: $10,000
  • Audit
    • Cost: $50,000
  • Total: $135,000

Outstanding Questions

  • Should the protocol have a separate governance token?
    • Pros:
      • YAM treasury would receive large allocation, potentially leading to significant short term rise in book value
      • SubDAO would be a new and interesting experiment
      • No increased issuance of YAM
      • Increases YAM’s positioning as an incubator and launcher of protocols, potentially encouraging other teams to build through YAM.
    • Cons:
      • Theoretically, any value that is attributed to the subDAO token in market capitalization could be attributed to YAM if there was no subDAO. In that case, the YAM treasury would see 50% of that subDAO’s market cap increase to its treasury, but the price impact on YAM itself would be difficult to predict.
      • The logistics of managing two communities could be difficult, though until the subDAO was granted control of the protocol or began creating new pools with the subDAO token as the arbiter, this would likely not be an issue.
  • Should any portion of the premiums be redeemable instantly by underwriters? Or should all premiums simply go to the protection pool, such that underwriters still receive those cashflows, but must go through the 30-day withdrawal?
    • Pros of instant redeem:
      • People like cashflows
    • Cons of instant redeem:
      • The protection pool grows more slowly
      • It would not be difficult to track the increase in value via premiums, is it necessary to actually allow for holders to redeem?
1 Like



what would YAM holders profit from treasury??

Hi Trent,
Many thanks for your effort to assemble this great scoping document.

Some comments and general thoughts, most of them are influenced by the idea of transparency and autonomy. Mid- till long-term a DAO has to be well document enough, in many aspects, to further develop without the support the key-developers. For example on-board new developers like a mature open-source project.

• Budget

  • Buffer
    In case the budget estimator and developer is the same person I recommend to at least adding 150% budget buffer on the estimation. Developers typically tend to underestimate their efforts by far.

  • Testing
    There is no budget for testing?
    Any test-cases, unit-tests or simulations planned? Developer and tester are the same person?

  • Further break down of work items
    Would it be possible to break down the work items further?
    For example a break-down of the effort per contract and effort per week?

• User interface mock-ups
Would it be possible to start the specification- or early development-phase with UI mock-ups for the specified use-cases like underwriting or protection buying?
This would help casual users to understand the product and generate some early excitement about the product.

• Roles and skils
What roles with corresponding skills are exactly required? Does adding roles like project management or lead architect make sense?

• Development tools and infrastructure
What software development tools and infrastructure will be used? (IDE, Github etc.)

• Audit
Is there a procurement process for the auditor? Is the audit price a fixed priced or determined by complexity or LoC for example? Remark: In terms of autonomy it would be great to document the process and required steps to hire an auditor

• Separate token / SubDAO
Latest managing the third project in a single DAO will get too complex to govern and synchronize.

1 Like