Case studiesSecurity audit
GitHoney
An on-chain bounty protocol that pays open-source contributors through Cardano smart contracts.
- Client
- TxPipe
- Language
- Aiken
- Scope
- 5 on-chain files
- Final commit
- 8118116
- Report
- 29 May 2025
- Findings
- 21
GitHoney lets a repository maintainer attach a bounty to a GitHub issue, lock the reward in a validator, and release it to the contributor whose pull request is merged. alwaystrue reviewed the protocol's Aiken validators over several weeks in 2025. The review identified three critical and one major vulnerability, the most severe of which allowed an attacker to steal bounty rewards and to avoid protocol fees. The project team resolved every non-enhancement finding before the report was finalised.
Findings
What the review found
Findings are numbered by severity. Each is delivered with a description, a recommendation, and the commit in which it was resolved. Every finding below Enhancement was resolved during the engagement; the one acknowledged finding is an enhancement the project team chose to defer.
| Critical | 3 | |
|---|---|---|
| Major | 1 | |
| Minor | 0 | |
| Enhancement | 12 | |
| Info | 5 |
- Total
- 21
- Resolved
- 20
- Acknowledged
- 1
Selected findings
- GH-001CriticalResolved
Multiple bounty satisfaction
A bounty's identity rested on the name of its BountyId token, but the protocol never enforced that names were unique. Two bounties sharing a name could be consumed in one transaction and re-created as the larger of the two, stealing the rest. Anyone could also mint a duplicate token to release a BountyId to their own wallet and forge bounties with arbitrary values and datums.
- GH-002CriticalResolved
Resin instead of honey
The check that a bounty carried a reward accepted any non-zero value. A worthless dummy token satisfied it, so a bounty could be created while locking less than the minimum 3 ADA the protocol requires.
- GH-003CriticalResolved
Fatal exception on initialization
A fix for an informational finding sent the Settings NFT to an address whose default spending validator always fails. Had it shipped, the team deploying the protocol could never have spent the NFT, and no instance of the protocol could have been initialised.
- GH-101MajorResolved
Honey-lock
The bounty minting policy demanded the Settings UTxO on both its mint and burn paths. Had GitHoney ever deleted the settings, contributors could no longer have burned their BountyId tokens, and rewards on already-merged bounties would have been locked permanently.
- GH-301EnhancementAcknowledged
Claim on merge
Merging a bounty and claiming it are two transactions where one would do. Paying the contributor within the merge transaction would remove a transaction, a datum field, and a proportion of the protocol's cost and attack surface. The project team chose not to adopt this change in the audited release.
The system
What GitHoney does
GitHoney is a bounty management system for open-source software development. It operates as a bot inside GitHub, interacting with users through issues, pull requests, and comments, and it is responsible for deploying the on-chain contracts and monitoring every interaction with them. A maintainer creates a bounty on an issue. A contributor accepts it and eventually links it to a pull request. Once the pull request is reviewed and merged, the contributor claims the reward.
The protocol implemented by the audited files describes only the on-chain contracts and their interactions: a single Settings UTxO per protocol instance, holding the fee schedule and the bounty validator itself, and one Bounty UTxO per bounty, holding the reward assets and a datum that records the parties, the deadline, and whether the bounty has been merged. Four validators govern them, together with two optional badge contracts that sit outside the protocol.
Roles
- Maintainer
- Maintains a repository and has a task that requires completion within a deadline. Creates and funds the bounty.
- Contributor
- Completes the task by submitting a pull request, and claims the reward once the bounty is merged.
- Admin
- Acts as an oracle of the work done. Confirms the contributor's payment by merging the bounty, or reclaims the deposited assets for the maintainer by closing it.
- GitHoney
- Manages the protocol instance and its settings: the fee-receiving address, the bounty creation fee, and the bounty reward fee.
Scope and method
What was reviewed, and how
The audit covered the on-chain validators only. Off-chain code and the test suite were out of scope, and the report makes no claim about them. Each audited file is identified in the report by its SHA-256 hash, and the final state of the code for the purposes of the report is the commit recorded above.
The review began with a thorough examination of the validators and their documentation. The team then worked to steal from, manipulate, and break the protocol using that knowledge, considering vulnerabilities both common to eUTxO systems and specific to this design: interactions between contracts, extraction of value, disruption to other users, and other attack vectors.
Audited files
- onchain/validators/githoney_contract.ak
- onchain/lib/checks.ak
- onchain/lib/types.ak
- onchain/lib/utils.ak
- onchain/lib/validations.ak
Review loop, repeated for each finding
- 01The audit team shares a description of the finding and a recommended resolution.
- 02The project team acknowledges the finding and, where it decides to resolve it, opens a pull request with a fix.
- 03The audit team reviews the fix and either returns feedback or recommends it for merging.
- 04The project team merges the fix and the audit team updates the report.
- 05The audit team continues the review against the changed code.
Trust assumptions
Who must be trusted, and with what
Beyond individual findings, the report examines where control is concentrated in the protocol, what a malicious party in each position could do, and whether the honest parties could still recover the value they had locked.
GitHoney's control over the protocol
By controlling the Settings UTxO, GitHoney can change the fee schedule at any time or halt the protocol by deleting the settings altogether. Fee changes carry little risk: existing bounties record their reward fee in their own datum, and maintainers may simply stop creating bounties. Deletion is more serious, but the close and claim transactions do not depend on the settings, so merged bounties remain claimable and unmerged ones remain closable even after the settings are gone.
Verdict
The audit team considers GitHoney's control over the protocol not only acceptable but an example for decentralised protocols: the worst case, a malicious operator, still allows the honest parties to recover the value locked by the protocol.
The Admin's control over bounties and rewards
The Admin is the only actor able to merge or close a bounty, and has discretion over where rewards added after creation are sent. An Admin could therefore decline to merge a bounty that was in fact merged on GitHub, decline to close one that was in fact abandoned, or direct the extra rewards to themselves.
Verdict
The audit team considers the Admin's control too high for a trustless interaction: both the maintainer and the contributor must trust the Admin. Given that the Admin must decide whether a pull request solves an issue, current technical limitations prevent a fully trustless design. Multi-signature Admin wallets are recommended as a mitigation.
Outcome
Where the protocol was left
All three critical findings and the major finding were resolved during the engagement, along with every informational finding and eleven of the twelve enhancements. The project team was responsive throughout, and the code that reached the final commit was materially smaller, faster, and easier to reason about than the code first submitted for review: redundant checks were removed, expensive value comparisons were replaced with direct lovelace comparisons, and custom types were replaced with their standard-library equivalents.
Two recommendations were left with the team for the next release.
- 01Resolve GH-301 by paying the contributor within the merge transaction and removing the separate claim transaction.
- 02Explore ways to reduce the trust that maintainers and contributors must place in the Admin.
Request a proposal.
Send an outline of your system and your intended mainnet date. We will respond with a proposed scope of review, a fee estimate, and an expected timeline. The full GitHoney report, with the complete protocol specification and every finding, is available below.