Onyx by Enzyme Finance is a tokenization protocol for asset management vehicles. It facilitates bespoke ERC20 shares issuance, including fees and tools for valuation accounting.
Before submitting a report, please review our Bug Bounty program guidelines carefully. Reports that only cover issues already listed in the program scope will be closed and marked as spam.
Smart contracts may have both a currently deployed version and the latest audited version that is scheduled for deployment. These are labeled as follows:
- Live — the smart contract that is currently deployed and in use
- Latest audited — the most recently audited smart contract, not yet deployed but planned for future release If no labels are present, it means the deployed (live) smart contract is already up to date with the latest audited version.
Triaged by Immunefi
PoC Required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
Permanent freezing of funds
Protocol insolvency
Theft of unclaimed yield
Permanent freezing of unclaimed yield
Temporary freezing of funds
Smart contract unable to operate due to lack of token funds
Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)
Out of scope
In addition to Immunefi scope rules, the following are considered out-of-scope:
- everything noted in this document set (e.g., Risks and Limitations)
- everything noted in audit reports
- user error; i.e., inadequate inputs or config, lack of mechanism understanding, etc (see below)
- unrealistic fund state (see below)
Examples of out-of-scope "user error"
Onyx is designed for flexibility of different setups and administrative needs. The admin role is often tasked with ensuring fairness, avoidance of denial-of-service (DoS) and similar ill effects, executing steps in order, and otherwise following manual processes to achieve desired results (e.g., Suggested Subscription Rounds).
Example: deposit and redeem handler DoS due to request cancelations
Some deposit and redeem handlers (e.g., ERC7540LikeDepositQueue and ERC7540LikeRedeemQueue) use a minRequestDuration, where a request is cancelable after minRequestDuration has elapsed.
As long as minRequestDuration is always set adequately (i.e., greater than the maximum time between batches), there will never be a cancelation DoS opportunity.
Example: deposit and redeem handler DoS due to small amounts that round to 0 shares
admin has full control to omit requests with amounts that are considered too small.
Example: share price staleness/fairness/etc during deposit or redemption
admin has full control over the price at which deposits and redemptions are executed, and it must be part of their process to validate that the currently-set share price is adequate for any action according to their needs.
Example: failure to initialize contract
Contracts are always expected to be properly-initialized, and all proxies are always deployed with their init data bundled into the same call.
Examples of "unrealistic fund state"
Onyx vaults are assumed to operate within common-sense constraints for how managed funds work.
Closely related to #examples-of-out-of-scope-user-error.
Example: more debt than assets
A reasonable managed fund cannot take on more debt than assets such that share value <= 0.
Example: shares totalSupply > 0 when share value == 0
At the point where a fund truly loses all assets (e.g., hack, violent value deprecation that rounds to 0) and shares have no value, a fund would shut down rather than, e.g., accept new depositors who immediately get diluted by the shares totalSupply.
Smart Contract specific
- Incorrect data supplied by third party oracles
- Not to exclude oracle manipulation/flash loan attacks
- Impacts requiring basic economic and governance attacks (e.g. 51% attack)
- Lack of liquidity impacts
- Impacts from Sybil attacks
- Impacts involving centralization risks
All categories
- Impacts requiring attacks that the reporter has already exploited themselves, leading to damage
- Impacts caused by attacks requiring access to leaked keys/credentials
- Impacts caused by attacks requiring access to privileged addresses (including, but not limited to: governance and strategist contracts) without additional modifications to the privileges attributed
- Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code
- Mentions of secrets, access tokens, API keys, private keys, etc. in Github will be considered out of scope without proof that they are in-use in production
- Best practice recommendations
- Feature requests
- Impacts on test files and configuration files unless stated otherwise in the bug bounty program
- Impacts requiring phishing or other social engineering attacks against project's employees and/or customers