Dedaub <-> Nexus Mutual Collaboration Proposal

[Kendrea]

The Community Fund is pleased to begin it’s consideration for the community granting process for a Dedaub & Nexus Mutual Collaboration.

We (dedaub.com](http://dedaub.com/)) propose to create, install, and maintain a vulnerability analysis and continuous monitoring service over the smart contract systems that the Mutual covers.

About Dedaub

We maintain a static analysis infrastructure, demonstrated at contract-library.com, and deployed over all contracts on the blockchain. We decompile deployed contracts and run sophisticated program analysis queries, mainly for security vulnerabilities. In the past months, these analysis reports have led to numerous vulnerability disclosures, several bug bounties (from DeFi Saver, Dinngo/Furucombo, Primitive Finance, Vesper Finance, BT Finance, indirectly from Armor.fi), 6 mentions in “Week of Ethereum News”, and more. Using this technology we have conducted two separate studies for the Ethereum Foundation on the impact of EIP-1884 and EIP-3074 over all deployed contracts.

What We Can Do for Nexus Mutual

We can detect all contracts that are part of each covered protocol and group them automatically (under human supervision). Subsequently, we can analyze the contracts and display warnings of vulnerabilities (or proto-vulnerabilities, i.e., components that when put together can make a service vulnerable). The static warnings will be combined with queries on environmental conditions (e.g., approvals and balances in past transactions, state of initialization of a contract, storage contents) to produce reports that can point to security issues. We will also maintain a contact database for each covered protocol. If a vulnerability is detected in a live system, we will contact the appropriate project team.

Below is a list of tasks involved in this project. For all tasks, we believe that our technology offers a competitive advantage.

1. Identify all deployed contracts that constitute a service covered by Nexus Mutual, while new contracts are being added. This will be done in two ways:
   Starting from a known set of contracts for the service, we will
   a) find newly added contracts using source-code queries for specific code patterns;
   b) monitor blockchain storage fields that link to other contracts of the service, so that a newly-linked contract will be added to our monitor list.
2. Run automated security analyses over all identified contracts. The analyses will combine static (i.e., code) and dynamic (i.e., blockchain state) queries. Some examples of promising analyses include:

• potential for Uniswap/Balancer price manipulation
• interaction with untrusted tokens
• “unchecked sender” in flash loans
• contracts not properly initialized
• inconsistent scaling factors (i.e., powers of 10) for monetary amounts
• ECDSA signing that is not unique per signed message
• conventional errors: arithmetic overflow, reentrancy.
  Any new security analyses added to our repertoire over the duration of service, will be seamlessly re-run on the identified contracts.

3. Monitor the results of the above automated analyses and classify them by severity. Escalate as appropriate. Maintain a list of contact points for covered projects and communicate with them in case of a discovered vulnerability.

Effort, Budget

The three tasks above involve different levels of human effort vs. leveraging Dedaub’s technology. We budget the overall project cost at a baseline of $20K/mo (in NXM), subject to scaling parameters, based on the following breakdown.

For task (1), the level of human effort is moderate and scales with the number of monitored protocols. For 10-20 protocols, a small effort (in the order of a couple of person-weeks) is required for bootstrapping and subsequently under one person-day per week is needed for follow-up monitoring to ensure that the classification is correct and complete.

For task (2), the level of human effort is low (just hours per week), consisting only of maintenance of an automated system. There are also (secondary) infrastructure costs for setting up and maintaining a dedicated instance of our analysis service. This effort remains (virtually) unchanged for more protocols.

For task (3), the level of human effort is high and scales with the number of monitored protocols. For 10-20 protocols, an average of two person-days per week are required for ranking warnings, inspecting state and code, determining if any warnings should be pursued further, and pursuing them.

The budgeting anticipates bonus NXM to be paid if a vulnerability is detected that would have led to a claim payout.

Impact matrix

All proposals will be considered based on their potential impact on the mutual.

1. Awareness/education Projects that seek to grow awareness of Nexus in the wider community and to help members understand how the mutual works. Examples could include writing docs, newsletters, producing videos, memes, NFTs.
2. Distribution/sales Projects that focus on b2b partnerships or increase distribution of cover at the source of the primary purchase (ie, on DeFi apps). Examples could include building a distributor on top of Nexus, integrations with other projects, or designing new products.
3. Technical improvements/capability Projects that seek to expand functionality of the mutual or development of new products. Examples could include contributing to open source code, designing user interfaces, building a reinsurance layer or constructing bundled yield bearing and protected products

Once a proposal has been up for discussion on here for 7 days it will be closed and we will then translate it to the snapshot for voting. After the snapshot has concluded and if it has produced a favorable outcome, we will distribute the funds.

Details about the Community Fund can be found on this page of our Docs

[BraveNewDeFi]

This is an interesting collaboration proposition. Thank you for detailing the services you provide and the benefit it can bring to Risk Assessors and the mutual at large.

I have a few follow-up questions:

1. At $20k/month at a baseline, that translates to ~144 NXM/month at current prices (1,728 NXM annually all things held equal). Since the mutual will be adding this service to existing and new protocols, would we be charging participating protocols for such a service? Or will the cost come directly from the Community Fund?*

2. If a vulnerability is found, will Dedaub collect a bug bounty (where applicable)? If so, would any percentage of a bug bounty found while monitoring listed protocols on Nexus Mutual be returned to the Community Fund? I think a 75-25 split (Dedaub-Nexus) with the 25% being deposited into the Community Fund would be beneficial for both parties. Since Dedaub wouldn’t be monitoring certain contracts unless under an agreement with the mutual, I think it would be fair to have some funds flow back into the Community Fund if a bug bounty is collected to ensure we can capture value for the Community Fund while compensating Dedaub and creating a greater value proposition for listed protocols on Nexus.

3. How would disclosures be provided to community members if a vulnerability is detected? Will semi-regular reports be generated for mutual members?

I believe this could be a beneficial collaboration but members should know if the cost is shifted wholly onto the community fund or if this is an added cost to protocols listed on Nexus; if bug bounties collected while monitor contracts listed by Nexus Mutual are shared with members in any capacity to potentially replenish the Community Fund; and how communication between Dedaub and mutual members will be handled.

Thank you for the detailed proposal. I look forward to your response.

• To be clear, I wouldn’t be in favor of shifting any cost for such a service onto members buying cover or onto listed protocols. Just a clarifying question I wanted an answer to.

[yannis]

Thanks for the questions (and kind words). I’m the (co-)author of the proposal, on the Dedaub side. Although my understanding on question #1 is that this would come from the Community Fund, I believe we (Dedaub) are not the right people to answer this. So, let me focus on #2 and #3.

I think #2 is an excellent idea. I would need to discuss more, but I believe a 75-25 split (Dedaub-Nexus) on any bug bounties on monitored protocols is fair, as long as the Nexus share is capped (to, say, $120K/yr, which is half the annual value of the proposal). Although it may seem that this cap is unnecessary (since it will only apply if annual bug bounties are over $480K/yr), the value of bounties has grown exponentially in recent months and, for reference, we have already received $350K in bounties within 2021.

As for #3, we are open to suggestions. We could certainly be offering semi-regular reports, but reports on false alarms would probably not be too useful. Perhaps the most useful would be a report if a vulnerability is found (which will hopefully not be a regular occurrence).

Thanks again for the well-thought-out feedback and questions.

[HeyChristopher]

Love this proposal. Great synergies with Nexus and the broader DeFi community.

Can you explain how you will rank the security of contracts a little bit more? I.e. if the contract suite of a protocol has a couple of minor to medium issues, what would be the final result from Dedaub? A single score?
Also, will you be providing your results as an API so that other Nexus frontends can potentially integrate it into their risk assessment overviews?

One thing I would like to see and I am not sure it’s already covered in the proposal is a warning about updated contracts. Often times underlying contracts change quite a bit without the user or risk assessor being aware, so an economic score in the form of “Days live/Volume generated since” would be a great way to additionally assess risk.

[Hugh]

Thanks to Dedaub for putting this proposal together! Thought I’d provide some wider context.

Prevention of claims has significant value for the mutual. In regular insurance there are many instances of monitoring systems, usually bundled with the insurance purchase, that give early warning of system malfunction and allows repair crews to be dispatched before severe losses occur. Examples include flood warning systems, boiler monitoring and many others. I see this proposal in a similar vein.

In particular, for protocols where contracts can be upgraded sophisticated monitoring tools can save users and the mutual a lot of money. eg Uniswap is less likely to need such tools, but Yearn would likely benefit a lot from it.

I also see it as a potential strategic differentiator, eg if a project is willing to distribute Nexus cover at point of sale they we can include them on the monitoring list.

I’ve been in discussion with the Dedaub team ahead of this proposal as I think a partnership of this type could bring value for both of us. So in general I’m very supportive and would like to hear more comments from members on the specifics.

Looking forward to more discussion here!

[yannis]

Great question–thanks! The effort will, very explicitly, not give a ranking or score. We are not planning to offer a (noisy) estimate of threat level. Instead, it is a monitoring service: a human engineer will be inspecting all warnings, regularly. E.g., every couple of days the engineer will see a list of queries that need more attention. (This could be because of changes in the code–e.g., a new contract replacing an existing contract in a protocol. Or it could be because of changes in the overall state–e.g., “this contract now has some ETH in it” or “that contract now has a different value for storage variable ‘paused’”.) They will be reviewing the code, consulting others, and deciding whether to escalate to the protocol contacts.

So, the final result will be someone escalating the early detection of a vulnerability to the protocol maintainers, preventing protocol and insurance losses.

Regarding an API or public access, I think this should be a bit limited, so that it doesn’t end up helping potential attackers. Maybe the right public access level would be to export the list of smart contracts we have associated (semi-automatically) with each protocol and that we are monitoring. But we certainly don’t want to be exporting warnings, at least not before they are dismissed as harmless. (And if they are dismissed, why export them?)

[mate]

I’m totally in favor of this proposal.

I’d like to suggest that bug bounty rewards should be 100% owned by Debaub. However, to bring value to the NXM community, the bug bounty rewards should be converted and locked for X years to NXM such that risk assessors could observe/learn how Debaub would allocate their stake.

(Staking, Shield mining rewards whatsoever would not be locked)

[yannis]

That’s clever. But I don’t think our NXM allocation would offer that much to the community. For instance, it might be biased towards a very small number of projects that have happened to have employed us as security auditors.

[BraveNewDeFi]

This service would be an invaluable addition to our existing offerings. The ability to have the protocols we list monitored for vulnerabilities would benefit Risk Assessors, listed protocols, and mutual members on a whole.

This analysis would extend to Nexus Mutual’s smart contract system as well, correct?

While I think a 75-25 split of bug bounties collected would be agreeable terms, it’s ultimately up to my fellow members to weigh in on this. It would make sense to pay Dedaub the $20k/month fee in NXM with a 25% return on any collected bug bounties, which would be reverted to the Community Fund multi-sig in a set denomination. With more community input, we could determine the hard cap on bug bounty, though I think 25% of bug bounties up to 50% of the annual fee is on the level.

[Dopeee]

It seems to me to be quite important whom is working on these tasks. Essentially, the Mutual is creating a freelance contract and paying you what works out to be an hourly rate at the end of the day.

So, members need to consider whether the fee that we’re paying is appropriate for what we’re receiving. What we receive is extremely dependant on whom is working on this task, because we’ll never know otherwise until some issue is detected or is released, undetected.

Would Yannis and Neville be working on this directly? Would others be involved?

Could you share some details about your experience, and why you’re the right team for this specific work.

[yannis]

For the analyses/queries, all of us would be writing them. For the monitoring, it’s just a matter of who the first responder is, and they are responsible for escalating first internally to the rest of us. So, I don’t think that this is as sensitive a role as you may believe. After all, we are a six-person company right now. For the sake of the argument, let’s say we grow to double that in 18 months. It’s still a very small size. So, it’s pretty “direct”, no matter who the first person is who looks at the reports. I have no problem putting our name behind this no matter who we choose for the role, which most likely won’t even be the same person at all times.

[yannis]

Yes to all! The choice of protocols is up to the Mutual, including the Nexus smart contracts, of course.

[Dopeee]

Understood. Thanks for the clarity. I agree with BraveNewDeFi that 25% of bounties up to 50% of the annual fee is about right.

Regarding @BraveNewDeFi 1st point:

"Since the mutual will be adding this service to existing and new protocols, would we be charging participating protocols for such a service? "

Two ways to look at this I suppose. 1st is that it’s a value add and a differentiating advantage against other insurers. 2nd is that we use it how Hugh alluded to, as an extra feature for projects that add extra value to us i.e. 1-click insurance at POS.

I’d lean towards the 2nd option. We can always expand to the 1st option of offering it across all projects later, but it’s hard to go the other way.

This would likely be more of a question for the business development folks. How useful would projects find this and what can we get in return for absorbing this cost?

[yannis]

Just to tie some loose ends from earlier questions with concrete suggestions:

• Regarding reporting: we will issue quarterly reports detailing the set of contracts being monitored for every chosen protocol, the kinds of issues we watch for, as well as a discussion of the most interesting investigations. For actual discovered vulnerabilities, there will be independent public reports (at any time, not in the quarterly report).

• Regarding passing back bounties to Nexus: if Dedaub is to receive bounties on vulnerabilities found on monitored protocols, 25% of bug bounty amounts, capped at $120K/yr, is to be deposited to the Community Fund.

[Kendrea]

Hello Everyone! This has been an amazing thread with lots of great questions, feedback and responses. Just a reminder that this forum will close on Monday, May 17th. If you have any lingering questions, now is the time to ask and get clarification before we close it out for vote! Once we have closed it out, there can be no change to the proposal once it goes to Snapshot. Thank you to our community members and to Dedaub for this discourse!