Auditing Compound Protocol

I appreciate the write-ups from @OZSecure (OpenZeppelin) and @dguido (Trail of Bits). These teams’ work with Compound Labs on the protocol’s core contracts, especially pre-governance, was invaluable for the bootstrapping of the protocol. As a community member and user, I deeply appreciate your past work for Compound and your broader efforts as good actors in the smart contract security space.

To me, the tenor and character of this current thread feel out of step with the bona fides of OZ’s and ToB’s prior work with Compound Labs. Let me try to lay out the key discrepancies I’m seeing. I am hoping it could help us think through the origins of the current tension; increase community buy-in for @jamico’s suggestion on a path forward; and hopefully identify some ways to circumvent such tensions in future efforts as stewards of the protocol.

Conflicts of interest: I appreciate @sukernik’s transparency at the top of this thread in explaining how the proposal from OZ came to us. That said, declaration of a conflict of interest doesn’t absolve us of the need to agree on how to work around it. In this case, it seems likely that there was some degree of information or timing asymmetry between the vendor with whom @sukernik has a business relationship (OZ) and the vendor with whom he presumably does not (ToB).

Now, we have one vendor (OZ) that has been, at times in this thread, projecting a sense of entitlement to an up-down vote as a sole-source provider, and another vendor (ToB) stuck playing catch-up through no fault of their own while trying to manage the optics of the awkward situation that we have placed them in.

I have to say, I am a bit baffled by the number and variety of high-pressure sales tactics employed by @OZSecure throughout this thread, from aggressive up-selling relative to @sukernik’s initial outreach, to intentionally promoting an atmosphere of urgency, to rather bizarrely accusing ToB of copying aspects of OZ’s proposal that any reasonable vendor would include. In my eyes, these tactics are incongruous with, and damaging to, OZ’s good reputation.

I see two take-aways here, one for community members taking on new initiatives, and one for vendors proposing fee-based services to the protocol:

  • Community members: Let’s please at least start a thread here on the forums before engaging in direct outreach to potential vendors for any new initiatives that could possibly involve a distribution of COMP, especially if there are known conflicts of interest involved. Otherwise, vendors like ToB (and others who might be well-qualified but whom we might not personally know) have every reason to question the integrity of the process.

  • Service providers: Especially in cases where a conflict of interest may exist, prospective service providers should be careful to keep proposals clearly in-scope of the request. Here, the request was audit review of new governance proposals prior to on-chain execution; what OZ proposed in response is a much more elaborate engagement, some of which is necessary to deliver the core service, some of which is almost certainly not.
    For example, I love the idea of an experienced auditing firm providing educational materials for community members seeking to improve the protocol, and I would likely be a user of this resource if it existed. Furthermore, OZ’s suite of public contract templates offer ample evidence that they would likely do a fantastic job. However, it is related, but quite far removed from, the core aims of this security audit request and, at least in my view, should be considered as a separate proposal.

Cost model: I’m not qualified to objectively assess how reasonable the costs are, but I will state as an outsider to the security audit industry that they seem absurdly, even comically high to me (like, by about one order of magnitude). While I acknowledge that the community is likely to support paying a premium relative to reasonable market rates, any additional supporting evidence OZ can provide to justify the cost structure relative to industry standards would be helpful here.

I also agree with community members who question the cost structure of OZ’s proposal and its performance fee: I do not consider a performance fee model to be appropriate for this work. If the service rendered is to secure the protocol, why should the service provider get extra cookies every quarter the protocol is not exploited? Compound does not need to offer an extra incentive here. The service provider’s motivation to do their work well should be to score the next security agreement with the protocol, not to earn extra compensation for services already rendered.

Finally, I agree with @arr00 that compensation for this work should not be streamed to the vendor. It makes more sense to me that it be paid out periodically (perhaps quarterly for one year, then annually) with a new proposal to authorize the payment for each following period.

The question of payment schedules leads to an important final follow-up question: how can the community secure auditing services beyond the runway of the current COMP distribution schedule, which is only a few years iirc? While this question goes beyond the core focus of the audit proposals, it is worth discussing in this context as we continue what I consider to be the most important discussion we’re having: how to adjust COMP distribution for the health, security, and sustainability of the protocol.

9 Likes