RFF: Revised Yam Bug/Hack Protection Protocol

The following is an updated spec for the Yam Bug/Hack Protection Protocol. The original post can be found here. While several details require further development, this spec is designed to provide an overview of the system.

YAM Bug/Hack Protection Spec Overview:


The current derisking opportunities in the DeFi space currently are unable to serve the market demand for such functionality, while also either only offering KYC’d coverage or price risk hedging. There is clear excess demand for an open, permissionless protocol that helps DeFi users derisk their exposure to bugs and hacks on DeFi protocols. Yam intends to develop a protection protocol through which underwriters can stake funds and earn premium fees from buyers that want to purchase protection in the event of a hack or bug. This will fill a much needed gap in the existing DeFi ecosystem.


Yam will create a bug/hack protection protocol in which underwriters receive a tokenized representation of their contribution to the protection pool and access to cashflows from protection premiums. The approach is intended to be governance minimal, though Yam Governance will retain some admin control to modify key protocol parameters such as pricing and premium distribution.

Protection Pools:

Each protection pool offers bug or hack protection for a specific set of contracts, which can be updated by the arbiter in the event of underlying protocol upgrades. The basic functionality involves a pool that is underwritten in a cryptocurrency such as DAI or ETH, protection buyers that pay premiums in that same currency, with those premiums being distributed to underwriters.

In the event of a bug or hack, a claim is submitted to the arbiter, and if approved the entire protection pool is distributed to protection buyers according to their proportion of total active coverage.

Covered Protocols:

Protection pools will be created via a Factory contract and can be created by anyone. YAM holders will likely choose to create an initial set of pools and provide an interface through which to access those created pools. In the creation process, an arbiter must be proposed, and that arbiter must then Accept. After Accept is called by the proposed arbiter, the pool is created.


Underwriters will be able to contribute capital to the protection pool and receive a tokenized representation of their contribution entitling them to a pro rata portion of the pool and cashflows from protection buyers’ premiums, which will go into the premium pool contract.

Underwriters can then withdraw their accrued premiums from the premium pool on an ongoing basis according to their cashflow token ownership. They will also be able to withdraw their contributed capital by initiating a withdrawal and burning their cashflow tokens. Once a withdrawal is initiated, a 30-day lock up period will be enforced, at the end of which the underwriter will be able to receive their capital and any premiums accrued in that 30 days.

Protection Buying:

Protection buyers will be able to purchase protection that entitles them to a pro rata portion of the protection pool in the case of a bug or hack on the protected protocol. Buyer’s would receive a tokenized representation of their position in terms of size and duration. Pricing will be based on a bonding curve that increases the cost as the amount of protection purchased gets closer to the total funds in the protection pool.

Arbitration and Claims:

In the event of a bug or hack, a claim will be submitted to the arbiter, set as the YAM Governor contract. This allows the arbiter to act as a neutral third party to fairly assess claims. For this service, the arbiter will receive a 2% fee on all premiums. If the arbiter agrees that a hack or bug has occurred, funds in the protection pool will be distributed pro rata to those with active coverage. Claims submitted that do not reach quorum will default to invalid.

Premium Distribution:

A portion (2%) of all premiums will be paid to the arbiter, while all other premiums will go to a premium pool, which holders of underwriter tokens will be able to withdraw from according to their stake in the pool.


Love this and 100% approve of this moving forward.

  1. Provide some examples of who can be an arbiter. I assume it will be a group, such as all Yam holders who reach a quorom, and an individual will not be acceptable (an individual might not respond, die, or be corrupted).
  2. Work through an example of an underwriter seeking to provide insurance to the SNX community for SNX bugs. How will that work at each step?
  3. Explain the process if two or more groups wants to become an underwriter on the same smart contract (use SNX example). How is it decided who gets to create the pool? Or is it possible in the SNX example there will be 100s of different insurance pools for SNX token bugs rather than a single cohesive product?

@trente can you please work through these examples before this progresses any further?


  1. Anyone can be an arbiter. The implementation details aren’t completely finalized, but the current plan is that anyone can create a pool and specify any arbiter (an ethereum address), but the arbiter must “accept” that role by calling a specific function on the pool. For pools that YAM creates, the YAM Governance contract would be the arbiter, and YAM holders would need to vote on claims.
  2. The underwriter would either need to find a pool already covering SNX contracts, or they would have to create their own. In order to create their own, they need an arbiter that people trust so that people will actually buy cover on it. After the pool exists, it is as simple as the underwriter calling a function on the pool to underwrite it.
  3. They can just underwrite on the same pool. Anybody can create a pool, but nobody would buy cover on one that doesn’t have a trustable arbiter.

What is the implementation effort estimate and high level overview about required development tasks and their complexity?