Overview
Commit-Boost is a validator sidecar that facilitates communication between validators and third-party protocols. The PBS Module is fully compatible with mev-boost for high-MEV block sourcing, and is actively used by major validators such as Chorus One, Kiln, and Sigma Prime. The project has been introduced to the Lido DAO and received a $95k grant. They also received a $1.5 million grant from the Ethereum Foundation.
Development Company
Commit-Boost operates as an open software. The main team working on the project is Gattaca, a software company that is also behind the Titan Builder https://www.titanbuilder.xyz & Titan Relay https://titanrelay.xyz.
Main Developer
This is most likely Lorenzo Cavicchioli, hired into Gattaca around March 2024 and in autumn of 2024 he was working on Commit-Boost.
Drew Van der Werff is also noted as the main steward and spokesperson for the project.
References
- Repository: https://github.com/Commit-Boost/commit-boost-client
- Documentation: https://commit-boost.github.io/commit-boost-client/
- Sigma Prime Commit-Boost Client Audit: https://github.com/Commit-Boost/commit-boost-client/blob/main/audit/Sigma_Prime_Commit_Boost_Client_Security_Assessment_Report_v2_0.pdf
- Community Calls: https://www.youtube.com/channel/UCYNYRYTwsbl_oa4HmtvY6Vw
- Twitter: https://x.com/commit_boost
Summary of Risks
Severity | Issue | Status | Mitigation |
High | Single Contributor Risk | Open | Project is seeking additional developers |
High | Potential Validator Key Compromise | Open | |
High | Insufficient Security Audits | Open | New audits are planned |
Medium | Validator Key Exposure via Local Signer | Open | Documentation suggests alternative configurations |
Low | Unclear Financial Sustainability | Open | Budget appears sufficient for long-term development |
Detailed Findings
1. Single Contributor Risk
Description:
(A) Currently, Commit-Boost relies on a single primary contributor, creating a significant redundancy risk (if this individual were to leave, fall ill, or shift focus, there would be no one readily available to maintain or develop the project further).
Contribution frequency data also suggests a gradual decline in activity.
(B) With only one developer, code changes lack independent review, increasing the risk of undetected vulnerabilities. There is no clear plan to improve security practices, and a single individual controls the code running on many validators.
Some NOs (Kiln, Chorus One) have forked the repository, possibly to mitigate this risk. No changes have been pushed upstream so far.
Mitigation:
The team is looking for additional developers, but the timeline is unclear. Forks by Kiln and Chorus One indicate some level of risk mitigation.
2. Potential Validator Key Compromise
Description:
Running Commit-Boost requires initializing docker-compose.yml via commit-boost-cli. If this CLI tool were compromised, an attacker could potentially gain access to a node operator's infrastructure or even a live validator server.
3. Insufficient Security Audits
Description:
The only available audit, covering only PBS mode, is outdated. It assesses code from September 30, 2024, which is over six months old.
Mitigation:
A new audit is planned for Dirk & MUX modules, but no details on timeline.
4. Validator Key Exposure via Local Signer
Description:
At the time of writing, the Commit-Boost signing module has not been audited (only PBS module). Some third-party modules may require it, and using the Local Signer mode is particularly risky as it directly accesses validator keys.
If the local signer mode is used, validator keys could be at risk.
Mitigation:
The project provides alternative configurations:
- “Remote signer” mode which recently supported Web3Signer & Dirk, with a section in the official documentation on how to use Vouch.
- “Proxy keys” mode, with support of BLS and ECDSA. This use case requires additional security research.
5. Unclear Financial Sustainability
Description:
The project has captured $3.3 million in funding so far, but its long-term sustainability strategy is unclear.
Mitigation:
While the project initially lacked a clear income strategy, its lean approach to hiring and spending suggests it can sustain itself long enough to attract community support or secure additional funding.
Current funding should last at least 5–10 years for a small team.
Recommendations and Next Steps
- Encourage public security audits and peer reviews to mitigate single developer risk.
- Define a clear security roadmap including code review policies.
- Adopt safer signing configurations for validators.
- Clarify long-term funding strategy to ensure project sustainability.