Auditing Compound Protocol

Proposals
29

Hi Guys,

This is Rex from DeFiSafety. As I indicated in an article I wrote about the Compound Proposal 62, I believe this latest proposal is trying to solve the wrong problem. What Compound (and other protocols) need is not more 3rd party review but rather more staff. The Proposal 62 needed a PM and an internal software and process quality staff more than a third party auditor.

Protocols need more on the internal team watching and reviewing tasks before they present the results to an external auditor or a DAO. Based on my analysis of 62, the dev was mostly on his own. He wrote the code, wrote the tests, ran the tests, put the code on the testnet and asked the community to review and test. I never saw any evidence of actual community review. Finally, an external auditor looked it over and the result went to the DAO. I did write to the dev to get his comments on the article, but I did not get a response.

There did not seem to be an internal quality person or a PM. There did not seem to be internal dev process that might have said dev can’t write his own tests.

I believe a large protocol like Compound should have at least one internal QA person, a PM and a written process.

Is there a reason I have missed why protocols do not build internal staff? Could the staff be a target of regulatory attacks? But if that was true, it would be true of the auditors too, especially if they take over tasks that would be internal in the corporate world.

Another weakness I see is a lack of internal process documents. An example of this is that latest bZx EOA failure. The dev should not have used his main computer to execute trades on a major protocol account (remember Hughs’s exploit?) and the account should have had a multi-sig. There should be a public process document where bZx says how things should be done. In the case of COMP 62, the process should not have allowed one dev to do the entire requirements/code/test process on his own.

Actually, that inspires me. DeFiSafety can write a process doc, get community content and allow individual DAO’s to vote the document into their process. Perhaps Compound community could contribute?

I am not against more auditor participation and have nothing but praise for all the auditors in the chain of messages. DeFiSafety is not bidding for any work. We do not do consulting to protocols. Our goal is revenue from DeFi users so when we rate protocols like yours we are not in any conflict of interest.

However, our team watches DeFi protocols every day and thinks about problems from a process quality perspective. Please take this as our comments from that perspective. We are always available for discussions.

4 Likes
30

Please find our anticipated proposal below. We iterated on several items and terms that were present in our first draft, so there are a few refinements versus what I posted earlier!

I also spoke on Discord at the Compound Community Dev Call earlier today. I carved out my part of the presentation so you can listen to it briefly since it may add color to the proposal.

(For convenience, I also extracted the audio from ChainSecurity’s portion of the call.)

Executive summary

Compound seeks to prevent insecure proposals from being merged via the decentralized governance process. Trail of Bits will provide comprehensive software assurance services to mitigate this risk across three specific activities: consulting services, security engineering, and process creation.

We believe it is essential to create an easy-to-follow process with highly robust tools that makes security transparent, with or without a code review from Trail of Bits. We consider the primary goal as building capacity in the Compound ecosystem to secure itself. To that end, we will provide engineering efforts to develop critical security infrastructure and processes.

Trail of Bits will be paid the equivalent of $1 million USD in COMP every quarter for one year to provide the baseline services. This payment is all-inclusive of all services defined in the proposal.

Goals and Non-Goals

Goals of this effort include:

  • Prevent insecure code from being merged into Compound through the governance process, and ensure that any remaining risks of proposals under consideration are well known before a vote. Compound desires services that eliminate and illuminate these risks.
  • Provide first-class security tools and analytical capabilities to Compound developers. Compound developers must have every opportunity to analyze their code and understand its security ramifications. Compound desires a variety of tools that enable thorough inspection of code by developers and users.
  • Create repeatable processes that build capacity for security and avoid dependence on external audits or third-party services for security. Security efforts should result in higher quality code being developed by the Compound community over time through the adoption of consistent processes.

Non-goals of this effort include:

  • Deploy, configure, or maintain on-chain monitoring software. This goal does not address the security of governance proposals. These systems are an active field of research, may apply to fewer attacks than expected, or may have undesirable performance costs. Instead, we will commit to evaluating their opportunities and limitations during the project.
  • Further development of the bug bounty program. We support the formation of a bug bounty proposal to specifically address this issue. We will provide consultative advice to this proposal based on our years of experience seeing both ends of the bounty ecosystem.

Description of the Services

1. Consulting services

Trail of Bits will provide at least one full-time security engineer, with additional engineers supporting the project as needed, to perform the following consulting services:

  • Maintain a presence on Discord and the Compound forums. We will actively engage in conversation, reach out to developers as needed, and identify any new proposals.
  • Provide proposal authors with 1:1 counseling sessions. We will host a video call with the author to understand their goals and provide immediate feedback, including on the architectural design of their proposal and suggestions to reduce complexity.
  • Review and report any identified security issues in the code for proposals. We will describe the issue, a scenario to abuse it, and a recommendation to address it. We will work with proposal authors to validate fixes that result from these reports.
  • Define security properties for proposals. We will work with the authors to provide reasonable security invariants alongside the proposal and tests for them in Certora, Echidna, or other tools, as appropriate for the specific invariants under test.
  • Document “Security Considerations” for every proposal. We will contribute a standardized section to reviewed proposals to inform developers and users of limitations, risks, or other considerations to form an opinion about their vote on it.
  • Provide our analysis directly to the community. Before a vote on any governance issue, we will host a public community call, walk attendees through the documented Security Considerations, and run test suites, fully informing their decisions to vote.
  • Host bi-weekly Office Hours with developers. We will cover testing and verification tools, demonstrate new security processes and tools for Compound, and solicit feedback for new areas of development and guidance needed by the community.
  • Evaluate new security techniques for adoption by Compound. We will perform detailed evaluations of the applicability of these techniques directly on the Compound codebase, sharing our empirical results of efficacy and utility.
  • Ad-hoc services sourced from across Trail of Bits, as needed. This includes expertise from our separate teams for cryptography, application security, cloud-native security, threat modeling, machine learning, and other research teams. Our firm employs more than 80 researchers servicing clients in tech, defense, and finance on high-risk security challenges.

2. Security engineering

Trail of Bits will engineer solutions in software to critical security risks faced by Compound. We will ensure that first-class security tools are available, easy to use, and customized for use on Compound, with knowledge of Compound-specific risks built in.

  • Ensure that Slither, our static analysis framework, and Echidna, our rapid security property tester, always work on Compound code. These security tools are delicate machines that must ingest all code possible to write in Solidity and EVM. We will ensure that no breaking changes affect Compound for an extended period of time and these tools always “just work.”
  • Customize Slither and Echidna to the Compound codebase. We will extend each tool to understand Compound’s architecture, expected security properties, and third-party protocols, vastly enhancing their depth of results. For example, we can build static analyses that understand and aggregate data from Certora properties or that understand specific Compound interfaces.
  • Customize Slither to evaluate the security of upgrades. Upgradeability exposes low-level complexity with possibly disastrous results. Slither already evaluates for 17 such flaws, and we will enhance this analysis with Compound-specific conditions.
  • Develop scaffolding for new proposals with pre-integrated security analyses from Slither, Echidna, Certora, or others, as appropriate. These templates will provide secure beginnings for parameter changes, new tokens, protocol features, and governance changes.
  • Continuously define and evaluate security properties across the Compound codebase with analyses from Slither, Echidna, Certora, or other techniques, as appropriate. New proposals may expose under-specified areas of Compound that require greater formalization. We will work to fill in these gaps with new properties.

3. Repeatable processes

Trail of Bits will build the capacity of the Compound community to secure itself, minimizing dependency on external security audits for security and most efficiently using their time when engaged. We will define and socialize repeatable processes that encapsulate common tasks with security integrated within them. Adoption of these processes will set a floor on proposal quality, continuously secure proposals regardless of security auditor review, and improve the quality of proposals over time.

  • Design a repeatable process for starting a new proposal. We will develop onboarding guidance for developers that describes the end-to-end process for securely creating new proposals. Touchpoints will include security training, using pre-created templates, example security properties, guidance on tools, self-assessment, engaging with Trail of Bits for code review.
  • Design a repeatable process for proposal self-assessment. We will provide guidance to assess the security of proposals before sharing them publicly. This will facilitate more effective conversations about security with the community and Trail of Bits, knowing that an initial baseline has been met.
  • Design a repeatable process for risk assessment by the community. We will share the risk factors that security experts focus on when reviewing proposals and document steps to run testing and verification tools, thus providing a map for those voting on proposals to become better informed and obtain empirical evidence.
  • Design a repeatable process for evaluating third-party protocol integration risks. We will design a repeatable process to investigate the security considerations of new token implementations and other linkages to DeFi building blocks from Compound. We will document existing pitfalls and concerns in third-party code already used by Compound, and facilitate the discovery and documentation of others.
  • Design a repeatable process for other protocols to securely integrate with Compound. In the reverse of the above, we will describe security considerations for DeFi users of Compound. In our mind, any compromise involving Compound, even if it does not originate from our own code, will compromise its reputation.
  • Regularly update a “treasure map” for bug hunting in Compound. We will guide other security researchers to less specified, more risky areas of the code. We will regularly report statistics on these identified hotspots, such as % coverage for specifications.

Risks

Compound may have unknown, latent security vulnerabilities already present in the code. Our proposal focuses on new code added to Compound and, therefore, these issues may continue undiscovered. To mitigate this risk, we have included a) a task focused on specifying new security properties, as needed, and b) a task to build a treasure map to aid other bug hunters.

COMP holders may vote for proposals that contain documented security risk or that are otherwise highly risky, considering the reward to be greater in that circumstance. To mitigate this risk, we will a) add documented Security Considerations to every proposal and b) host a community call to walk through those considerations, demonstrate how to run included test suites, and evaluate the coverage of them.

Compound is highly complex and new proposals may use new features of Solidity or combine features of Solidity in ways that break the security tools upon which it depends. To mitigate this risk, Trail of Bits has specifically prioritized the development and testing of new features for Slither and Echidna against the Compound codebase.

Proposals may require swift approval without waiting for input from Trail of Bits, or input from Trail of Bits may be otherwise unavailable within the timeframe required due to unknown circumstances. To mitigate this risk, Trail of Bits has proposed a robust sequence of processes and tools for the community to enhance trust in themselves and better understand the risks of their actions.

Financial Terms

Trail of Bits will be paid the equivalent of $1 million USD in COMP every quarter for one year to provide the services. This payment is all-inclusive of all services defined in the proposal.

2 Likes
31

I have to say that for the long-term, the model proposed by ChainSecurity seems to me to be the most comprehensive and beneficial to the protocol. I agree that cultivating an RFP process, and in general focusing on the codified process, regardless of auditor, is a direction I believe we should move in to put the protocol in the strongest position going forward. That said, I can see how signing an agreement with a single auditor to guarantee their time is something that could be more useful in the shorter term. I think it would be a great if we could find some sort of balance that moves us towards a robust process, without lock-in, but acknowledges some of the difficulties implementing the full RFP process immediately.

2 Likes
33

@jared as we said on the community call this week, OpenZeppelin would be open and happy to work with other auditors where appropriate or desired by the DAO. We agree that the community will best benefit from a codified robust process that does not involve vendor lock-in, and we have tried to make that clear in our proposal. We are also open to working closely with firms like Certora if and when Formal Verification is required by the DAO. Overall we view partnerships and codified processes as critical to a layered security approach to ensure the security of the DAO and complementary to our continuous audit proposal.

Please find our revised proposal summary below:

OpenZeppelin’s Updated Proposal Summary

The Compound DAO’s long-term security requires a comprehensive and continuous set of audit and security solutions to prevent loss of funds and protect its reputation resulting from risks to the Compound protocol, specifically those introduced by community-proposed upgrades

OpenZeppelin will provide dedicated continuous audit services for all Compound governance proposals and will work with the Compound community to develop comprehensive security requirements and to implement best practice security monitoring.

OpenZeppelin's services will be coordinated by a dedicated Security Advisor who along with the OpenZeppelin team, the Compound DAO and the community will work to:

  1. Improve the overall process to ensure the security of community proposed upgrades to the Compound Protocol
  2. Provide continuous audits and dedicated resources to respond rapidly to all community proposed upgrades and changes
  3. Coordinate the creation of documented security checklists and requirements that can be shared with all proposal authors
  4. Implement an open security monitoring and security dashboard solution that will allow the community to validate security
  5. Integrate, support, and analyze other possible future important security program components such as formal verification, bug bounties, and white hat monitoring approved by the DAO.

The combined effort of the OpenZeppelin team, the Security Advisor, and the Compound community will thereby reduce potential security risks and further assure the DAOs trusted reputation.

OpenZeppelin has revised its original proposal to focus on community feedback and excludes performance fees. OpenZeppelin’s fee will be the equivalent of $1 million USD in COMP every quarter for one year, to provide these services. This fee covers all services defined in the proposal. Please see our full revised proposal here :

OZ Final Proposal

We believe that no other firm in the market can bring the same breadth and depth of offerings to the DAO. We provide best-in-class continuous auditing and security advisory services; established leadership in secure development and secure operations; and external relationships and partnerships at a cost to value no other firm can match.

Next Steps

Assuming a vote begins on Dec 6th and OpenZeppelin’s Governance Proposal is selected by Dec 13th, the Compound community can expect the following timeline:

  1. Proposal Security Process (starting on Dec 13th) - the Security Advisor (SA) will immediately engage with the Compound community to create a well-defined process for auditing protocol changes prior to being proposed. This will include a regular and agreed upon set of KPIs and communication plan to update the community on a regular basis, including but not limited to community calls.
  2. Comprehensive Compound Audit (starting in January): A team of dedicated OpenZeppelin security auditors will perform a comprehensive review of the currently deployed smart contracts. Many of whom have worked with Compound smart contracts in prior audits.
  3. Continuous Audits (starting in February): With the Proposal Security Process defined and a Comprehensive Audit complete, OpenZeppelin will be fully prepared to provide audits on all protocol change proposals. Note: We can begin auditing proposal changes earlier but given the lack of protocol changes currently pending, we expect February to be the ideal time to start.
  4. Security Requirements (starting in January): the SA and assigned members of the OpenZeppelin team will engage with Compound Labs and the Compound community to gather current security requirements and begin building comprehensive security requirements documentation and checklists.
  5. Security Monitoring: (starting in January): the SA and assigned members of the OpenZeppelin team will begin bi-weekly community workshops to gather requirements and share progressive design and implementation plans on comprehensive security monitoring and building a security dashboard.

We would be honored to partner with the Compound DAO to not only deliver continuous auditing but to also work together to be leaders and innovators in how to securely and efficiently run an effective DAO security program!

7 Likes
34

Dear Compound Community,

ChainSecurity thanks you for the feedback on our proposal.

We’ve received positive feedback regarding increased competitiveness, redundancy of audits, collaboration between auditors. However, the following questions were raised:

  • How can we ensure continuity with multiple auditors? How can we avoid things falling through the cracks? How can we avoid the risks and costs of switching auditors?
  • What is the cost of this proposal?
  • What exactly is the audit suite and what role does it play in the governance process?
  • What role would ChainSecurity play?

Please find our answers below.

1. The shared audit suite provides a common work basis and alleviates the risks of switching between auditors

Risks of discontinuity can be best alleviated with an extended test suite, called the “audit suite”. The audit suite is a collection of test cases designed by each auditor as they review or study Compound code.

When an auditor reviews the code manually, (s)he imagines numerous potential attacks and their impact on the system. If the system is vulnerable to a few of these attacks, only those end up in the audit report, while the countless other attacks imagined for the audit remain undocumented, only stored in the mind of the auditor.

With the audit suite, the auditor would create tests for each of these attacks, even if they are not successful with this specific code. By storing this thought process in the shared testing suite, we can build up on the thinking of that auditor in future updates of the system, even if (s)he is not present for the next audit.

Recording all test cases also helps to monitor the quality of an auditor’s methodology, and offers more transparency to the community.

Multiple auditors would be working on Compound, each of them contributing to the test suite. Each auditor would have an incentive to create the best tests possible, as it would be a great reputation builder if one of their tests identifies a vulnerability in the future. The common test suite would expand the Compound auditing knowledge as it is shared, instead of keeping it segregated. As time goes by, the audit suite will comprise more and more attack scenarios, and allow an increasingly performant review of the protocol.

We believe this extended test suite could recreate the continuity of knowledge you’d find in one auditing firm, or even exceed it: even in a single auditing firm, employees may get sick, go on holidays, or leave the company, and their unrecorded knowledge will go with them.

(See more details on the audit suite in our initial proposal.)

2. Multiple auditors are trained on Compound codebase and ready to jump in the audit process at any time

To clarify this point, let us describe the next steps of the voting process with our proposal:

→ STEP 1: Compound governance votes for our proposal

  • This doesn’t select a specific auditor, it just approves the system.

→ STEP 2: Auditors apply in a standardized way, which allows easy comparison between service providers. As stated in our original proposal:

  • “Auditors apply to become wardens of Compound by providing:
    • An example of how a code review for the Comptroller and the cToken would be performed, detailing methods and time required.
    • The cost and amount of hours reserved for Compound per quarter, which are if accepted guaranteed to be paid by Compound.
    • The expected compensation for the training phase.”

→ STEP 3: Compound votes for the auditors

  • Compound governance can vote for several auditors and/or proposals

→ STEP 4: Auditors are onboarded into the system

  • Selected auditors start the training phase (which is a full audit of the system). This training phase brings the auditor up to speed, secures the system even more and improves the shared testing suite: the auditor will add tests coming from a new perspective
  • During the training phase, previously onboarded auditors can spend time helping new auditors (if time allows)

→ STEP 5: Auditors work in partnership

  • Auditors secure the protocol and contribute to the test suite as per their proposal
  • Every year, Compound governance votes to keep the auditors in the system or not

As an example, please find here the proposal we intend to submit.

PS: Thanks @dguido for recording the audio of our intervention expalining the proposal in the Compound dev call: chainsecurity.m4a - Google Drive

1 Like
35

It’s been over a month since I posted the original request for auditors. Since then, we’ve received several comprehensive proposals from top-tier smart contract auditors. Candidly, I thought there would be some interest to audit Compound protocol, but I didn’t expect we’d get as many proposals as we did. It’s spectacular to see so many vendors vying for Compound’s business. If you’re looking for what a B2DAO process looks like, this is it.

As mentioned in an earlier post from this thread, Compound protocol does not have a clean and efficient process for evaluating several vendors. As a result, tokenholders and vendors aren’t sure what happens next. This is problematic for both parties: Compound needs an auditor as soon as possible, and the audit firms have a business to run and need to assign resources to their customers ahead of time. In short, we need a process for picking the vendor of choice.

I spoke to several community members about this, and folks suggested a quick and easy process. In a nutshell, we’d be using the community multisig to run a simple process. The community multisig would first whitelist each vendor to make a proposal. After that, tokenholders would vote on their favorite proposal. The proposal with the most “For” votes wins. To prevent more than one proposal from winning, the community multisig would then cancel the losing proposals after the vote is completed.

I’m including a more detailed version of the process below.

Audit Selection Process

  1. Reverie to create a form for vendors to submit their Ethereum address - 12/7
  2. Reverie to confirm the address belongs to the vendor through a video call - 12/8
  3. Reverie to share addresses with the community multisig - 12/8
  4. Community multisig to whitelist the address for each vendor - 12/9
  5. After being whitelisted, each vendor will submit their proposal for an on-chain vote - 12/13
  6. Tokenholders vote for their favorite proposal after a two-day review period - 12/15-12/17
  7. Winning proposal is queued for execution in the timelock; losing proposals are cancelled by the community multisig - 12/17

Since Reverie (the company I started with Derek Hsue) initiated the audit search process as part of this thread, we propose that we also complete the vendor selection process on behalf of Compound protocol. It took considerable time for us to reach out to the audit firms, explain Compound’s needs to them, encourage them to submit proposals, and to walk them through the process. We would appreciate a $75k COMP grant for the work we’ve done here.

11 Likes
36

This structure makes a lot of sense and is a good use of the whitelisting proposers feature.

While I don’t think we need to worry about the firms making other proposals, setting a relatively short expiry on the ability to propose is a good idea. Maybe two weeks? It could be even shorter, like 10-days.

This whole process has been a great learning experience for DAO, and this setup will be good for future B2DAO situations.

6 Likes
37

Thanks @sukernik. This structure makes sense and provides a clear path to finalizing the process. A couple thoughts:

Timing. The proposal deadline Larry suggested above (12/13) is reasonable. The community has given ample time to receive new bids and needs to be respectful of the auditors who have committed time, effort and resources towards the process to date. Also, it makes sense to require all proposals to be submitted at the same time so they run simultaneously. To that end, it might make sense to specify an exact time on 12/13 for the whitelisted auditors to introduce their proposals. That way we can ensure the votes run as close to simultaneous as possible.

Voting Mechanics. Under this model, we should make clear that tokenholders should only vote for one proposal. In other words, tokenholders should vote “yes” on the proposal they prefer, and abstain from the others (since the multi-sig will cancel all proposals except the one with the most “yes” votes). This will ensure that we avoid any weird overlapping vote dynamics between the various proposals.

Otherwise, this approach looks great. Thanks again to @sukernik and the Reverie team in taking the initiative and creating a framework that works for all sides.

Jeff Amico
a16z

8 Likes
38

No complaints yet for the $75k fee? good to see. We’re making progress people.

9 Likes
39

“Community Multisig”

1 Like
40

No complaints yet for the $75k fee? good to see. We’re making progress people.

It’s really clear from our end that Larry has been a tremendous help in getting this done, and the multisig-based voting process is just the latest effort that he’s invested. He’s definitely an asset for all you folks!

8 Likes
41

Hey folks, apologize for the tone of this post. I feel quite strongly that anyone who does work to add value to a protocol (especially one as big as this) should be able to capture meaningful value/ownership from that work. COMP has not done this well in the past, but I see things like this (meaningful fee for arranging an auditing firm to work with the community) as a great step in the right direction. This should be the standard going forward (and we should even consider going back to retroactively reprice past contributions).

5 Likes
42

Under this model, we should make clear that tokenholders should only vote for one proposal. In other words, tokenholders should vote “yes” on the proposal they prefer, and abstain from the others (since the multi-sig will cancel all proposals except the one with the most “yes” votes). This will ensure that we avoid any weird overlapping vote dynamics between the various proposals.

In terms of voting mechanics it seems like this adds additional and unnecessary friction. If voters & the community multisig are required to do this every time we pick a vendor for a specific function on Compound, it sets a bad standard for future votes (though this model should work in the short-term for this vote). We should look into doing one of the following:

Direct Voting for Vendor Selection. Adding additional functionality to the GovernorBravoDelegate contract to enable multiple & customizable options for voting on governance proposals. In this model, a “Audit Vendor Selection” Proposal would be created with ToB & OZ & Abstain listed as potential options by the community multisig or an unbiased third party, with the ToB & OZ correlated to a specific action (i.e. sending COMP tokens to the auditor as the first payment for auditing). There should be an arbitrary limit on the number of options allowed on a governance proposals (i.e. 2-4 to start), and voters would only be allowed to pick one option.

Correlating Proposals. Similar to the role that the community multisig is playing in @jamico’s model, we would create a function that would enable proposals to be batched together, with only the proposal in the batch with the highest votes FOR (where the proposal is passing) being approved. In this model, a third party proposer would create the batched proposals, and launch them together. Should any proposal pass by the end of the voting period, all proposals but the one with the most FOR votes would be cancelled by the contract. Additionally, voters would only be able to vote for one proposal within a batch.

In either of these two options, we solve the problems of 1) relying on the community multisig & 2) requiring voters to be cognizant of not voting on more than one proposal. Still trying to figure out the specific details for implementation, but would love to hear thoughts on implementing such functionality into the governance module.

s/o to @Rk2357 & @annamira for the inspiration here

5 Likes
43

Agree that this method is not ideal, but the best option currently available. Modifying governance is not a quick task but could be done with time. I find the first option (multiple choice voting) to be the best solution.

8 Likes
44

We have three great proposals from three reputable firms - thank you all for posting proposals! Thank you @sukernik for organizing this - the $75K COMP grant seems fair.

Right now I’m leaning towards OpenZeppelin as my top choice. The revised proposal seems like a great value not only for Compound but for the whole ecosystem! OpenZeppelin’s Ethernaut was a tool I used to learn about smart contract exploits and how to avoid them. I can’t wait to see how the new Audit Suite will further improve smart contract security.

6 Likes
45

While the ChainSecurity proposal is interesting, I don’t think it meets the short term needs, so I’ve ruled it out for now.

I’ve evaluated the two proposals from Trail of Bits and from Open Zeppelin. Both are overpriced considering market rates, but both provide more value to Compound than they cost. I would be happy with either.

Focusing on the differences, rather than the similarities.

Trail of Bits

Pros:

  • Echidna customization/rules. Echidna is a good tool to have in the security toolbox. As a fuzzer it is worse at finding tiny errors than formal verification, but is much easier to use and reason about, making it overall better at finding big stupid hidden things you have done that have snuck past your unit test because you didn’t think of them…
  • External integration guide for safely integrating Compound. While Compound is not downright evil to safely integrate with (unlike Curve), it would be good to have a clear guidance for others here. It would be good for both the safety of the protocol, and for potential increase in future usage.

Cons:

  • ToB’s proposal is focused on building Compound’s ability to self audit and self manage security. While this is a good goal for most teams, the Compound protocol currently has neither a core developer group, nor it’s own in-house security group. Instead outside individuals code and make proposals, and may or may not be around to work with the later proposals of others. I think that in the current state of Compound, this focus is misplaced. (If I though Compound would be realistically building out a team in the next few months, this con would become a pro)

Open Zeppelin

Pros:

  • Not just auditing changes, but monitoring changes through the rest of their lifecycle, including deploys, on-chain configuration, and beyond.
  • Upstream monitoring. Compound’s security depends on the oracles behind it and the and security of the tokens it lists, some of which can be upgraded. It would be vital to know when changes are happening to upstream tokens.
  • In general, the OZ proposal focus more on OZ doing the work, rather than bringing a non-existent Compound team up to speed. I think this is more of what is needed at the current time.

I lean towards OZ.

5 Likes
46

Quick update.

OpenZeppelin, Trail of Bits, and ChainSecurity have posted their proposals:

I encourage everyone to review the proposals in depth in order to make an educated vote.

Best of luck to all of the vendors!

8 Likes
47

At Gauntlet, we are excited to see these proposals and believe that auditing is a valuable and necessary service for the Compound protocol. We are abstaining from this vote as it is difficult to weigh in from a quantitative perspective, which is what Gauntlet always strives for in its decision-making process. We look forward to working together with whichever provider the Compound community ends up deciding on, and are excited to collaborate on value-add proposals such as risk parameter recommendations and listing new assets.

1 Like
49

Congratulations on a successful governance proposal @OZSecure!

As a first order of business, who will be our Security Advisor, and how might we contact them regarding scheduling upcoming audits?

7 Likes
50

Hi @jared

My name is Michael Lewellen. I’ll be the Security Advisor for you all on behalf of @OZSecure.

Based on the Next Steps outlined in our proposal, our first goal will be to define a security process that proposal authors can follow leading up to an audit and submission to the DAO for a vote. This will start with engagement in the next community call and one-on-ones with key community members. After collecting feedback from everyone, we’ll then propose a process that will go through refinements with the community before being finalized.

While we work on defining this process, I’ll share a draft version that I’ve been working on based on our usual audit process in a separate forum thread as I believe it deserves its own dedicated discussion.

I’d love to start talking to key members of the community including yourself although it might be slow going over the next week due to holiday plans. I expect that we’ll really ramp things up by Jan 3rd to start preparing for a comprehensive audit of the Compound Protocol.

Anyone that has protocol changes planned in the next future or would like to share feedback can contact me at the following:

I’m really looking forward to working with you and the rest of the Compound community!

7 Likes