Dopex - rjs's results

1. Summary

1.1. Approach Taken

Preparation

• Reviewed the Dopex documentation with a particular focus on understanding $rDPX tokenomics and Atlantic Options
• Reviewed the Dopex Solidified Audit (2021)
• Reviewed the Dopex Solidity Finance Audit (2022)
• Reviewed the Dopex Solidity Finance Audit (2022; BNB SSOV)
• Reviewed the rDPX V2 technical specification
• Documented diagram of in-scope system architecture and drafted the mechanism review

Execution

• Reviewed the core contracts in principal, and identified Areas of Concern
• Initial code review
• Drafted reports
• Deep code review
• Wrote & submitted reports

Effort 21 hours total

1.2. Mechanism Review

rDPX V2 is a complex new system involving changes to the existing rDPX token which forms part of the Dopex ecosystem. It introduces dpxETH, which is pegged to ETH in a 1:1 ratio. dpxETH will be designated as a staple collateral token for future Dopex options products. The dpxETH:ETH peg is maintained via an interplay between bonding mechanisms, backing reserves controlled via AMOs, and a peg stability module. There are dependencies on Curve Finance, Uniswap V2 and Uniswap V3 for performing some of these functions.

1.3. Areas of Concern

2. Codebase Quality Analysis

2.1. Codebase Review

Each source unit was assessed with respect to modularity, access control mechanism, centralization risks, validation completeness and documentation quality:

2.2. Maturity Level

• "Admin-only functions" represents a centralization risk; ideally, a more granular set of roles would be implemented
• "Basic" validation refers to code where not all parameters or scenarios were validated; details in the QA report
• "Basic" documentation refers to code lacking a clear description of code purpose, assumptions, etc.
• Overall, the codebase demonstrated high maturity.

2.3. Recommendations

• Validation and documentation should be expanded in the areas highlighted yellow above
• Where possible, centralization risks should be reduced by splitting dedicated roles out of the single "admin" role

3. Architecture Recommendations & Risks

3.1. Consider reducing Peg Stability Module (PSM) dependencies

The PSM is entirely controlled by the Core Contract managers; if these are compromised or act maliciously, they could disrupt the peg. There could also be scenarios where the Curve pool may not have enough liquidity to correct the peg effectively.

3.2. Consider improvements to reduces parameters in the bonding mechanism

Multiple parameters (e.g. discount factor) are set by governance. If governance is compromised or acts inefficiently, it can affect the stability of the bonding process. It is worth considering if improvements are possible to allow parameters to dynamically reflect economic conditions rather than being configured through governance.

3.3. Consider making it possible for funding to be calculated without the APP contract admin

"The APP contract admin needs to calculate the funding needs to be called for every strike before the epoch ends".

Ideally any critical processes ought to be executable directly or indirectly by the impacted users in the ordinary course of operations, to reduce centralization risks.

3.4. Consider more granular roles for System Parameters

System parameters are set by governance and therefore pose a centralization risk. Consider splitting system parameters by role if possible.

3.5. Document system intention through more worked examples

It is possible to create a forge script that runs multiple scenarios and assumptions through the protocol and outputs graph points, when can then be rendered graphically. This would greatly improve the documentation and communicate system intention more clearly.

Time spent:

21 hours