Open Dollar — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Open Dollar, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 15
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 15 closed, publicly disclosed Open Dollar reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Governance attack, Oracle manipulation, Integer overflow / underflow, across EVM-Solidity, Move. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Open Dollar
- Governance attack findings disclosed against Open Dollar
- Oracle manipulation findings disclosed against Open Dollar
- Integer overflow / underflow findings disclosed against Open Dollar
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Open Dollar: Collateral could be transferred to an address, which is not `SAFEHandler` managed by the `SAFEManager`
The ODSafeManager contract fails to validate that recipients of internal collateral or coin transfers are valid SAFEHandler addresses. This lack of validation allows users to move assets into arbitrary addresses, including EOAs, which then gain the ability to interact directly with the SAFEEngine. This bypasses the protocol's mandatory proxy-based interaction model, violating core system invariants that require all interactions to occur through authorized proxies.
Open Dollar: Due to extremely short `votingDelay` and `votingPeriod`, governance is practically impossible
A flaw in Open Dollar's ODGovernor contract sets the voting delay to 1 block and the voting period to 15 blocks using OpenZeppelin's GovernorSettings. Because the protocol was deployed on Arbitrum where average block execution times are roughly 0.26 seconds, the active voting duration lasts only about 3.9 seconds. Token holders are unable to review proposals or submit vote transactions before the deadline passes, making it impossible to reach quorum. This misconfiguration completely locks out all governor-controlled setter functions and administrative updates within the protocol.
Open Dollar: Mismatch between the SAFE generated debt and the amount of the system tokens minted for the user
The Open Dollar lending protocol contains a flaw in its debt generation logic that causes mismatches between recorded debt and minted system tokens. The _generateDebt function calculates an adjusted debt amount to account for existing coin balances, but fails to use this adjusted value when transferring tokens to the user. This inconsistency leads to failed transactions and potential protocol-level accounting errors, as the amount of debt added to a SAFE may not align with the actual tokens provided to the user.
Open Dollar: Unable to retrieve price information with CamelotRelayer contract
The CamelotRelayer contract is fundamentally broken because it incorrectly assumes that Camelot V3 liquidity pools implement the exact same interface as Uniswap V3 pools. By attempting to use the Uniswap V3 OracleLibrary, the relayer calls non-existent functions on the Camelot pools, causing constant transaction reverts. This renders the relayer incapable of providing any price information, effectively disabling any system component that depends on this oracle for accurate pricing.
Open Dollar: SafeHandler contract doesn't have any method to call to `ODSafeManager.allowHandler()`, lead to DOS in some function
The `SAFEHandler` contract lacks the necessary logic to invoke the `ODSafeManager.allowHandler()` function, preventing users from granting the permissions required for system interactions. This architectural oversight renders the `enterSystem()` and `quitSystem()` functions unusable, as they are gated by a `handlerAllowed` modifier that checks for permissions which can never be set. While this does not result in the direct loss of user funds, it blocks critical protocol functionality, necessitating a change to the permission-granting mechanism.
Open Dollar: Old permissions in handlerCan mapping are still attached to the safeHandler of a transferred safe
Open Dollar's permission management system for safe handlers fails to reset access controls when a safe's ownership is transferred. Because the handlerCan mapping lacks an owner-based key, permissions granted by a former owner persist after the safe is transferred to a new user. This leads to a scenario where unauthorized third parties maintain control over a safe without the new owner's knowledge, posing a significant risk to user funds and position management.
All reports in this group
- Open Dollar: Approved address can approve other addresses for an owner's safeLogic error$0
- Open Dollar: `transferSAFEOwnership()` does not fully transfer ownershipLogic error$0
- Open Dollar: Incorrect calculations for Surplus Auction creation cause massive surplus imbalancesInteger overflow/underflow$0
- Open Dollar: Missing debt check lets users start a debt auction of non-existent debtLogic error$0
- Open Dollar: `ODSafeManager#allowSAFE()` cannot be executed either by the proxy contract or any other address.Logic error$0
- Open Dollar: ODSafeManager.enterSystem - Transfer wrong amount of collateral, debtLogic error$0
- Open Dollar: Decimal Limitation in CamelotRelayer and UniV3Relayer Contract DeploymentOracle manipulation$0
- Open Dollar: Malicious users are able to bypass the Tax payment using making a Fake BasicActions ContractLogic error$0
- Open Dollar: Vault721.tokenURI does not comply with ERC721 - Metadata specificationLogic error$0