Our report presents an in-depth analysis of the DittoETH protocol, a decentralized stablecoin system with an order book design for enhanced staking yield. our report provides actionable insights, improvement recommendations, and a detailed architecture review to enhance the security, reliability, and decentralization of the DittoETH protocol.
The analysis was conducted through a systematic review of the DittoETH smart contract codebase. The following approach was employed:
- A line-by-line examination of the smart contract code to identify potential vulnerabilities, bugs, and edge cases.
- AAn evaluation of the protocol's overall design, including its components, interactions, and potential risks.
- An investigation of the protocol's control mechanisms and potential for admin abuse.
- An assessment of the protocol's key mechanisms, such as the order book, staking, and redemption processes.
- A comprehensive analysis of the systemic risks associated with the DittoETH protocol.
Codebase Quality Analysis:
The DittoETH demonstrates a well-structured and modular design. The use of libraries, such as LibShortRecord
, LibOrders
, and LibAsset
, promotes code reusability and maintainability. The contracts adhere to common coding conventions and best practices, enhancing code readability.
- The contracts heavily rely on
revert
statements for error handling, which can make it difficult to provide informative error messages to users. Implementing custom error types and a centralized error handling mechanism would enhance the user experience and facilitate debugging.
Example: This line
if (redemptionAmount < minShortErc) revert Errors.RedemptionUnderMinShortErc();
Recommendation: Use custom error types and a centralized error handling mechanism to provide more descriptive error messages.
- External Dependencies: The protocol heavily depends on external libraries and contracts, such as
SSTORE2
andLibBytes
, for critical functionality. While these dependencies can provide useful abstractions, they also introduce potential risks if not thoroughly audited and verified.
Recommendation: Security reviews of all external dependencies to ensure their reliability and security.
- The DittoETH protocol involves multiple interacting components, such as the order book, redemption mechanism, and collateral management. The complexity of these interactions can increase the attack surface and make it challenging to reason about the system's behavior.
Recommendation: Formal verification to ensure the correctness and security of the protocol's complex interactions.
- Upgradability: The protocol utilizes the Diamond proxy pattern for upgradability. While this allows for flexibility and adaptability, it also introduces risks associated with contract upgrades, such as the potential for introducing new vulnerabilities or breaking existing functionality.
Recommendation: Implement strict access controls and governance mechanisms for contract upgrades, ensuring thorough testing and community consensus before deploying any changes.
- The protocol lacks granular access control mechanisms, allowing any user to propose redemptions, dispute redemptions, or claim redemptions. This lack of access control can lead to potential abuse or spamming of the system.
Example: This function
function proposeRedemption(
address asset,
MTypes.ProposalInput[] calldata proposalInput,
uint88 redemptionAmount,
uint88 maxRedemptionFee
) external isNotFrozen(asset) nonReentrant {
// ...
}
Recommendation: Implement role-based access control, restricting certain functions to authorized users or roles, such as "Proposer," "Disputer," and "ClaimRedeemer."
- The protocol grants significant privileges to the admin or owner, such as the ability to freeze assets, update critical parameters, and perform emergency actions. While these privileges may be necessary for protocol management, they also introduce centralization risks and the potential for admin abuse.
Recommendation: Establish a robust governance mechanism, such as a multi-signature scheme or a decentralized autonomous organization (DAO), to distribute control and ensure transparency in admin actions.
- The DittoETH protocol utilizes an on-chain order book mechanism for matching trades and providing staking yield. The order book design is well-structured and efficiently handles order placement, matching, and cancellation.
- Front-running: Malicious users may attempt to front-run orders by observing pending transactions and placing their own orders with higher gas prices.
- Griefing: Attackers may spam the order book with numerous small orders to congest the system and disrupt normal operations.
Recommendation: Implement measures to mitigate front-running and griefing risks, such as using a commit-reveal scheme, implementing order thresholds, and employing rate-limiting mechanisms.
- Redemption Process: The redemption process allows users to redeem their stable assets for collateral. The process involves proposing redemptions, disputing invalid proposals, and claiming redemptions after the dispute period.
- Insufficient validation of disputed short records: The
disputeRedemption
function lacks thorough validation of disputed short records, potentially allowing invalid or malicious disputes. - Lack of incentives for disputants: The current incentive structure may not provide sufficient rewards for users to actively participate in the dispute process, leading to potential manipulation or abuse.
Recommendation: Enhance the validation of disputed short records, ensuring they meet the required criteria. Adjust the incentive structure to encourage active and honest participation in the dispute process.
- Dependence on Staked ETH Liquidity: The DittoETH protocol heavily relies on staked ETH, such as stETH and rETH, as collateral for its stable assets. The protocol's stability and redemption process depend on the liquidity and stability of these staked ETH tokens. Any significant disruptions or depegging of staked ETH tokens could pose systemic risks to the DittoETH ecosystem.
Recommendation: Diversify collateral types to reduce dependence on a single staked ETH token. Implement robust risk management mechanisms to handle potential liquidity crises or depegging events.
- Oracle Vulnerabilities: The protocol relies on price oracles, such as Chainlink, for accurate price feeds. Vulnerabilities in the oracle system, such as price manipulation or data feed disruptions, could compromise the integrity of the DittoETH protocol.
Recommendation: Implement multiple redundant oracle systems and establish a robust oracle governance framework to ensure the reliability and security of price feeds.
We have check for vulnerabilities and verify the validation of proposed ShortRecords and their collateral ratios.
The proposeRedemption
function in the RedemptionFacet.sol
contract to check for vulnerabilities and verify the validation of proposed ShortRecords and their collateral ratios. We also ensure that the redemption amount is within the allowed limits and doesn't exceed the maximum redemption CR, and look for any ways to manipulate the input data to bypass validations or propose invalid redemptions.
-
Input Validation:
- The function takes
asset
,proposalInput
,redemptionAmount
, andmaxRedemptionFee
as input parameters. - It checks if the length of
proposalInput
is within the allowed limit (type(uint8).max) to prevent excessive gas usage. - The
asset
is validated using theisNotFrozen
modifier to ensure that the market is not frozen. - The
redemptionAmount
is checked against a minimum value (minShortErc
) to prevent proposing redemptions for very small amounts. - The function verifies that the redeemer has sufficient
ercEscrowed
balance to cover theredemptionAmount
. - It also checks if the redeemer has any existing proposed redemptions (
redeemerAssetUser.SSTORE2Pointer == address(0)
).
- The function takes
-
ShortRecord Validation:
- The function iterates over the
proposalInput
array to validate each proposed ShortRecord. - It retrieves the
currentSR
(ShortRecord) using the providedshorter
andshortId
. - The
validRedemptionSR
function is called to check if the ShortRecord is valid for redemption.- It verifies that the ShortRecord is not
Closed
, has sufficientercDebt
, and the proposer is not the owner of the ShortRecord.
- It verifies that the ShortRecord is not
- The
updateErcDebt
function is called to update theercDebt
of the ShortRecord based on the currentercDebtRate
. - The current collateral ratio (
currentCR
) of the ShortRecord is calculated using thegetCollateralRatio
function and theoraclePrice
.
- The function iterates over the
-
Collateral Ratio and Redemption Amount Validation:
- The function checks if the proposed ShortRecord's
currentCR
is less than the previous ShortRecord'spreviousCR
to ensure that the proposals are sorted in ascending order of collateral ratio. - It also verifies that the
currentCR
is below the maximum redemption CR (C.MAX_REDEMPTION_CR
). - The
amountProposed
is calculated based on the remainingredemptionAmount
and thecurrentSR.ercDebt
. - If the
amountProposed
would leave less thanminShortErc
in the ShortRecord, the iteration breaks to prevent creating ShortRecords with insufficient debt.
- The function checks if the proposed ShortRecord's
-
Redemption Fee Calculation:
- The redemption fee is calculated using the
calculateRedemptionFee
function based on thetotalColRedeemed
andtotalAmountProposed
. - The calculated fee is compared against the
maxRedemptionFee
provided by the redeemer to ensure that it doesn't exceed the specified maximum.
- The redemption fee is calculated using the
- Potential Vulnerabilities and Considerations:
- The function relies on the accuracy of the
oraclePrice
provided by theLibOracle.getPrice
function. Any vulnerabilities in the oracle price feed could impact the correctness of the redemption process. - The function assumes that the
proposalInput
array is sorted in ascending order of collateral ratio. If the redeemer provides an unsorted array, it could lead to unexpected behavior or bypass the CR validation. - The function does not enforce a strict limit on the number of ShortRecords that can be proposed in a single redemption. A large number of proposed ShortRecords could potentially cause gas exhaustion or exceed block gas limits.
- The function does not have any direct mechanisms to prevent a redeemer from proposing redemptions on ShortRecords that are currently being liquidated or have pending liquidations.
- Implement additional checks to ensure that the
proposalInput
array is properly sorted before processing the redemptions. - Enforce a reasonable limit on the number of ShortRecords that can be proposed in a single redemption to prevent gas exhaustion and ensure efficient processing.
- Integrate additional validation to prevent redemptions on ShortRecords that are currently being liquidated or have pending liquidations.
- Regularly monitor and audit the oracle price feed to ensure its accuracy and reliability.
We dive deeper into the redemption process and investigate potential weaknesses and vulnerabilities in the redemption logic, validation of proposals, dispute process, and collateral transfers.
-
Validation of Redemption Proposals:
- Weakness: The validation of redemption proposals may not be comprehensive enough to prevent malicious or invalid proposals.
- Vector: The
proposeRedemption
function in theRedemptionFacet.sol
contract.function proposeRedemption( address asset, MTypes.ProposalInput[] calldata proposalInput, uint88 redemptionAmount, uint88 maxRedemptionFee ) external isNotFrozen(asset) nonReentrant { // ... for (uint8 i = 0; i < proposalInput.length; i++) { // ... if (!validRedemptionSR(currentSR, msg.sender, p.shorter, minShortErc)) continue; // ... } // ... } // ... }
- Potential Exploit: An attacker could craft malicious proposal inputs that bypass the validation checks in the
validRedemptionSR
function. This could allow the attacker to propose redemptions for invalid or non-existent short records, leading to unintended consequences. - Recommendation: Strengthen the validation logic in the
validRedemptionSR
function to ensure that only valid and eligible short records can be proposed for redemption. Implement additional checks, such as verifying the short record's status, collateral ratio, and other relevant parameters.
-
Dispute Process:
- Weakness: The dispute process may not have sufficient safeguards to prevent fraudulent or malicious disputes.
- Vector: The
disputeRedemption
function in theRedemptionFacet.sol
contract.function disputeRedemption( address asset, address redeemer, uint8 incorrectIndex, address disputeShorter, uint8 disputeShortId ) external isNotFrozen(asset) nonReentrant { // ... if (disputeCR < incorrectProposal.CR && disputeSR.updatedAt + C.DISPUTE_REDEMPTION_BUFFER <= redeemerAssetUser.timeProposed) { // ... } else { revert Errors.InvalidRedemptionDispute(); } }
- Potential Exploit: An attacker could manipulate the dispute process by providing false or misleading information to challenge legitimate redemption proposals. This could lead to the wrongful cancellation of valid redemptions or the theft of collateral.
- Recommendation: Implement robust verification mechanisms in the dispute process to ensure that disputes are valid and supported by sufficient evidence. Consider requiring disputants to stake a bond or collateral that can be slashed if their dispute is found to be fraudulent or malicious.
-
Collateral Transfers:
- Weakness: The handling of collateral transfers during the redemption process may have vulnerabilities that could be exploited.
- Vector: The
claimRedemption
function in theRedemptionFacet.sol
contract.function claimRedemption(address asset) external isNotFrozen(asset) nonReentrant { // ... for (uint256 i = 0; i < decodedProposalData.length; i++) { MTypes.ProposalData memory currentProposal = decodedProposalData[i]; totalColRedeemed += currentProposal.colRedeemed; _claimRemainingCollateral({ asset: asset, vault: vault, shorter: currentProposal.shorter, shortId: currentProposal.shortId }); } redeemerVaultUser.ethEscrowed += totalColRedeemed; delete redeemerAssetUser.SSTORE2Pointer; // ... }
- Potential Exploit: An attacker could try to manipulate the collateral transfer process by exploiting any vulnerabilities in the
_claimRemainingCollateral
function or by interfering with the deletion of theSSTORE2Pointer
. This could lead to the unauthorized transfer of collateral or the inability to claim rightfully redeemed collateral. - Recommendation: Ensure that the collateral transfer process is secure and tamper-proof. Implement strict access controls and validation checks in the
_claimRemainingCollateral
function to prevent unauthorized access or manipulation. Consider using a secure deletion mechanism for theSSTORE2Pointer
to prevent any potential interference.
-
Loopholes and Unintended Advantages:
- Weakness: There may be loopholes or unintended advantages in the redemption process that could be exploited by malicious actors.
- Vector: Tthe interactions between the various functions involved in the redemption process, such as
proposeRedemption
,disputeRedemption
,claimRedemption
, andclaimRemainingCollateral
. - Potential Exploit: An attacker could try to find ways to manipulate the redemption process by exploiting any inconsistencies or gaps in the logic flow. For example, an attacker might attempt to propose a redemption, dispute their own proposal, and then claim the collateral in an unauthorized manner.
- Recommendation: Conduct thorough testing and analysis of the redemption process to identify any potential loopholes or unintended advantages. Perform extensive scenario testing and consider engaging in bug bounty programs or security audits to leverage the expertise of the community in identifying vulnerabilities.
- Enhance the validation logic for redemption proposals to ensure that only valid and eligible short records can be proposed.
- Implement robust verification mechanisms in the dispute process to prevent fraudulent or malicious disputes.
- Ensure secure and tamper-proof collateral transfers during the redemption process.
- Engage in regular security audits and bug bounty programs to proactively identify and mitigate vulnerabilities.
-
Orderbook Matching Logic:
- Vulnerability: The gas-saving measures employed in the orderbook matching logic may introduce edge cases or unexpected behavior.
- Potential Attack Vector: An attacker could exploit the matching logic by crafting specific orders that take advantage of the gas optimizations, leading to unintended matches or manipulated outcomes.
- Recommendation: Extensive testing of the matching logic, including edge cases and extreme scenarios, to ensure its correctness and robustness. Verify that the logic always respects the oracle price for Short Orders and handles all possible order combinations correctly.
-
Oracle Price Caching:
- Vulnerability: The 15-minute caching period and the 0.5% buffer for matching Short Orders may be abused by attackers.
- Potential Attack Vector: An attacker could manipulate the cached oracle price by exploiting the 15-minute window or the 0.5% buffer, leading to favorable matches or mispriced orders.
- Recommendation: Assess the security implications of the caching mechanism and consider reducing the caching period or buffer if necessary. Implement additional safeguards to prevent price manipulation and ensure the integrity of the "starting short id" determination.
-
Dust Amounts:
- Vulnerability: The measures in place to prevent dust amounts on the orderbook may not be comprehensive enough.
- Potential Attack Vector: An attacker could find ways to circumvent the dust protection mechanisms, creating numerous tiny orders that clog the orderbook and increase gas costs.
- Recommendation: Review the implementation of dust prevention measures and consider strengthening them if necessary. Conduct tests to verify the effectiveness of these measures and identify any potential loopholes.
-
Minimum Debt Amount (minShortErc):
- Vulnerability: The logic for maintaining the minimum debt amount (minShortErc) may have weaknesses or loopholes.
- Potential Attack Vector: An attacker could exploit the known issue regarding ercDebt requirements being met through ercDebtRate application to create ShortRecords with insufficient debt, reducing liquidation incentives.
- Recommendation: Examine the implementation of minShortErc and ensure that it is robustly enforced throughout the protocol. Address the known issue and implement additional checks to prevent the creation of ShortRecords with insufficient debt.
-
Liquidations and Exits:
- Vulnerability: The liquidation and exit mechanisms for ShortRecords may have vulnerabilities or race conditions.
- Potential Attack Vector: An attacker could manipulate the liquidation process or exploit race conditions to prevent or delay liquidations, allowing them to maintain unhealthy positions.
- Recommendation: Test the liquidation and exit mechanisms under various scenarios, including high-stress conditions and concurrent transactions. Ensure that ShortRecords can always be liquidated when below the liquidation ratio and that exits are properly handled.
-
Collateral Ratio Manipulation:
- Vulnerability: The collateral ratio of ShortRecords may be susceptible to manipulation.
- Potential Attack Vector: An attacker could utilize flash loans, price oracle manipulation, or dependencies on external protocols to artificially inflate or deflate the collateral ratio, avoiding liquidation or gaming the redemption process.
- Recommendation: The potential risks associated with collateral ratio manipulation and implement safeguards to mitigate these risks. Consider incorporating price smoothing mechanisms, rate limiting, or additional validation checks to prevent sudden or extreme fluctuations in collateral ratios.
To verify that the redemption mechanism respects the maximum redemption CR constraint and ensure that redemptions are not possible for ShortRecords above the maximum redemption CR, We've analyze the relevant code and check for any potential vulnerabilities or ways to manipulate the CR calculations.
-
Maximum Redemption CR Constraint: The
proposeRedemption
function includes a check to enforce the maximum redemption CR constraint: #L93if (p.previousCR > p.currentCR || p.currentCR >= C.MAX_REDEMPTION_CR) continue;
This line ensures that the current collateral ratio (
p.currentCR
) of the proposed ShortRecord is less than the maximum redemption CR (C.MAX_REDEMPTION_CR
). If the condition is not met, the ShortRecord is skipped and not included in the redemption proposal.Vulnerability Assessment:
- The maximum redemption CR constraint is enforced correctly within the
proposeRedemption
function. - ShortRecords with a collateral ratio greater than or equal to
C.MAX_REDEMPTION_CR
are excluded from the redemption proposal. - However, it's important to verify that the
C.MAX_REDEMPTION_CR
value is set appropriately and cannot be modified or manipulated by any party.
- The maximum redemption CR constraint is enforced correctly within the
-
CR Calculation Manipulation: The collateral ratio (CR) of a ShortRecord is calculated using the
getCollateralRatio
function: #L90p.currentCR = currentSR.getCollateralRatio(p.oraclePrice);
The
getCollateralRatio
function is defined as follows:function getCollateralRatio(STypes.ShortRecord memory short, uint256 oraclePrice) internal pure returns (uint256 cRatio) { return short.collateral.div(short.ercDebt.mul(oraclePrice)); }
The CR calculation depends on the
collateral
,ercDebt
, andoraclePrice
values of the ShortRecord.Vulnerability Assessment:
- The CR calculation itself does not appear to have any direct vulnerabilities or ways to manipulate the result.
- The
getCollateralRatio
function performs a simple division of thecollateral
by the product ofercDebt
andoraclePrice
. - However, it's important to consider the following potential issues:
- Accuracy and reliability of the
oraclePrice
: If the oracle price can be manipulated or is not up to date, it could affect the CR calculation. - Manipulation of
collateral
andercDebt
values: If there are any ways to manipulate thecollateral
orercDebt
values of a ShortRecord before the CR calculation, it could potentially bypass the redemption constraints.
- Accuracy and reliability of the
To further enhance the security and ensure the integrity of the redemption mechanism, consider the following recommendations:
- Implement additional checks and validations to prevent manipulation of the
collateral
andercDebt
values of ShortRecords. - Comprehensive review of the functions and contracts that interact with or modify the
collateral
andercDebt
values to identify any potential vulnerabilities or manipulation points. - Verify that the
C.MAX_REDEMPTION_CR
value is set appropriately and cannot be modified or manipulated by any party. - Implement monitoring and alerting mechanisms to detect any unusual or suspicious behavior related to the redemption process.
To investigate how the redemption mechanism interacts with other parts of the DittoETH protocol, such as liquidations and collateral management, and to identify any unintended consequences, conflicts, or vulnerabilities, We analyzed the relevant components and their interactions.
- Redemption proposals target ShortRecords with low collateral ratios (below the maximum redemption CR).
- When a redemption proposal is successful, the collateral is transferred from the ShortRecord to the redeemer.
- This reduces the collateral available in the ShortRecord, potentially making it more susceptible to liquidation.
- If a ShortRecord's collateral ratio falls below the liquidation threshold due to a redemption, it becomes eligible for liquidation.
- Liquidators can then liquidate the ShortRecord, following the protocol's liquidation mechanism.
Potential Issues:
- Redemptions may inadvertently trigger liquidations if the collateral ratio of a ShortRecord falls below the liquidation threshold after a redemption.
- This could lead to unexpected losses for the ShortRecord owner and potential instability in the protocol.
Mitigation:
- Ensure that the maximum redemption CR is set appropriately, considering the liquidation threshold and the potential impact of redemptions on collateral ratios.
- Implement checks in the redemption process to prevent redemptions that would directly cause a ShortRecord to become liquidatable.
- Provide clear information to users about the risks associated with redemptions and the potential impact on their ShortRecords.
- Redemptions directly affect the collateral of ShortRecords by transferring a portion of the collateral to the redeemer.
- The protocol needs to accurately update the collateral balances and ensure that the collateral is properly accounted for during the redemption process.
- Any errors or inconsistencies in updating collateral balances could lead to discrepancies and potential vulnerabilities.
Potential Issues:
- If the collateral balances are not updated correctly during redemptions, it could result in incorrect collateral ratios and affect the integrity of the protocol.
- Miscalculations or rounding errors in collateral updates could lead to small discrepancies that may accumulate over time.
Mitigation:
- Implement robust and precise collateral tracking mechanisms to ensure accurate updates during redemptions.
- Perform thorough testing and auditing of the collateral management system to identify and fix any potential issues.
- Implement safety checks and validations to prevent inconsistencies or errors in collateral updates.
- The redemption mechanism should align with the overall goals and design principles of the DittoETH protocol.
- It should complement other features such as liquidations, collateral management, and the overall economic model.
- The redemption process should be transparent, fair, and accessible to all users.
Potential Issues:
- If the redemption mechanism introduces any perverse incentives or conflicts with other protocol components, it could lead to unintended consequences.
- Complexity arising from the interaction of multiple mechanisms could increase the attack surface and introduce new vulnerabilities.
Mitigation:
- Analyze the incentive structures and game-theoretical aspects to identify any potential misalignments or exploitable scenarios.
- Implement comprehensive testing and simulation to observe the behavior of the redemption mechanism under various conditions.
An analysis of the RedemptionFacet.sol
contract and its dependencies to identify any vulnerabilities or design flaws. We've reviewed the code, paying attention to the logic flow, data validation, state updates, and external interactions.
-
RedemptionFacet.sol
contract:- The contract inherits from the
Modifiers
contract, which likely contains common modifiers used throughout the codebase. - It imports various libraries and contracts, such as
U256
,U104
,U88
,U80
,U64
,U32
,Errors
,Events
,STypes
,MTypes
,SR
,LibAsset
,LibShortRecord
,LibSRUtil
,LibOracle
,LibOrders
,LibBytes
,C
, andSSTORE2
. - The contract uses the
LibShortRecord
andSTypes.ShortRecord
libraries extensively for updating and managing short records. - It also uses the
U256
,U104
,U88
,U80
,U64
, andU32
libraries for safe arithmetic operations.
- The contract inherits from the
-
Logic Flow:
- The contract contains several external functions, such as
proposeRedemption
,disputeRedemption
,claimRedemption
, andclaimRemainingCollateral
. - The
proposeRedemption
function allows users to propose a redemption by providing a list of short records to be redeemed. - The
disputeRedemption
function enables users to dispute a proposed redemption if they believe it is invalid. - The
claimRedemption
function allows the proposer to claim the redeemed collateral after the dispute period has passed. - The
claimRemainingCollateral
function allows the short record owner to claim any remaining collateral if the proposer fails to claim the redemption.
- The contract contains several external functions, such as
-
Data Validation:
- The contract performs various checks and validations throughout the redemption process.
- In the
proposeRedemption
function:- It validates that the redemption amount is greater than the minimum short erc amount.
- It checks that the proposer has sufficient escrowed balance to cover the redemption amount.
- It verifies that the proposer doesn't have any existing proposed redemptions.
- In the
disputeRedemption
function:- It validates that the caller is not the redeemer themselves.
- It checks that the redeemer has a valid redemption proposal.
- It verifies that the dispute is raised within the allowed time frame.
- It ensures that the disputed short record is not already included in the redemption proposal.
- The contract also relies on external libraries and contracts for additional validations, such as
LibOrders
,LibAsset
, andLibSRUtil
.
-
State Updates:
- The contract updates various state variables throughout the redemption process.
- In the
proposeRedemption
function:- It updates the proposer's escrowed balance by deducting the redemption amount.
- It updates the asset's total erc debt by deducting the proposed redemption amount.
- It stores the redemption proposal data using the
SSTORE2
library.
- In the
disputeRedemption
function:- It updates the short record's collateral and erc debt if the dispute is successful.
- It updates the redeemer's escrowed balance by refunding the incorrect redemption amount minus the penalty.
- It updates the disputer's escrowed balance by adding the penalty amount.
- In the
claimRedemption
function:- It updates the redeemer's vault balance by adding the total collateral redeemed.
- It deletes the redemption proposal data from storage.
-
External Interactions:
- The contract interacts with external contracts and libraries, such as
Modifiers
,SSTORE2
, and various utility libraries. - It relies on the
LibBytes.readProposalData
function to decode the redemption proposal data stored usingSSTORE2
. - It calls the
LibShortRecord.getCollateralRatio
function to calculate the collateral ratio of short records. - It uses the
LibOrders.getOffsetTime
function to get the current timestamp for time-based validations.
- The contract interacts with external contracts and libraries, such as
-
Lack of Access Control:
- The contract does not have any access control mechanisms to restrict certain functions to specific roles or authorized users.
- Anyone can propose a redemption, dispute a redemption, or claim a redemption, which may lead to potential abuse or spamming of the system.
-
Improper Validation of Disputed Short Record:
- In the
disputeRedemption
function, the contract does not properly validate the disputed short record. - It only checks if the disputed short record is not already included in the redemption proposal, but it doesn't verify if the disputed short record is valid or meets the required criteria.
- This could allow users to dispute redemptions with invalid or malicious short records, leading to potential manipulation of the redemption process.
- In the
-
Dependence on External Libraries and Contracts:
- The contract heavily relies on external libraries and contracts for critical functionality, such as
LibShortRecord
,LibOrders
,LibAsset
, andLibSRUtil
. - Any vulnerabilities or bugs in these external dependencies could potentially impact the security and integrity of the redemption process.
- It is crucial to ensure that these dependencies are thoroughly audited and verified to minimize the risk of introducing vulnerabilities.
- The contract heavily relies on external libraries and contracts for critical functionality, such as
-
Lack of Comprehensive Error Handling:
- The contract uses
revert
statements to handle errors and validations, but the error messages may not provide sufficient information for debugging and troubleshooting. - Improve error handling by using more descriptive error messages and considering the use of custom error types to provide more granular error information.
- The contract uses
-
Potential Front-Running Risks:
- The redemption process involves multiple transactions, such as proposing a redemption, disputing a redemption, and claiming a redemption.
- There may be potential risks of front-running attacks, where an attacker can observe a pending redemption proposal or dispute and attempt to manipulate the process for their own benefit.
- Implement measures to mitigate front-running risks, such as using a commit-reveal scheme or a time-locked mechanism for critical transactions.
-
Implement Access Control:
- Introduce role-based access control mechanisms to restrict certain functions to authorized users or roles.
- Consider using the OpenZeppelin
AccessControl
contract or similar libraries to manage access control permissions. - Define specific roles, such as "Proposer," "Disputer," and "ClaimRedeemer," and assign appropriate permissions to each role.
-
Enhance Validation of Disputed Short Records:
- Implement thorough validation checks for disputed short records in the
disputeRedemption
function. - Verify that the disputed short record meets the required criteria, such as valid collateral ratio, erc debt, and other relevant parameters.
- Ensure that the disputed short record is not flagged, canceled, or in an invalid state.
- Implement thorough validation checks for disputed short records in the
-
Audit and Verify External Dependencies:
- Conduct thorough audits and security reviews of the external libraries and contracts used in the redemption process.
- Ensure that these dependencies are well-tested, secure, and free from known vulnerabilities.
- Consider using widely-used and audited libraries and contracts whenever possible to minimize the risk of introducing vulnerabilities.
-
Improve Error Handling:
- Enhance the error handling mechanism by providing more descriptive and informative error messages.
- Use custom error types to differentiate between different error scenarios and provide more granular error information.
- Consider implementing a centralized error handling mechanism to ensure consistent error reporting throughout the contract.
-
Mitigate Front-Running Risks:
- Implement measures to mitigate front-running risks in the redemption process.
- Consider using a commit-reveal scheme, where users first submit a hashed commitment of their redemption proposal or dispute, and later reveal the actual data.
- Utilize time-locked mechanisms, such as requiring a minimum time delay between proposing and executing a redemption, to reduce the window for front-running attacks.
The DittoETH protocol presents a novel approach to decentralized stablecoin design, leveraging an order book mechanism for enhanced staking yield. While the protocol's codebase demonstrates a well-structured and modular design, there are areas for improvement in terms of error handling, external dependencies, and access control mechanisms.
The protocol's architecture involves complex interactions between various components, introducing potential risks that require thorough testing and formal verification. The centralization risks associated with admin privileges can be mitigated through the implementation of robust governance mechanisms and distributed control.
The order book and redemption mechanisms, while well-designed, present challenges related to front-running, griefing, and insufficient validation. Addressing these risks through appropriate mitigation measures is crucial for the security and integrity of the protocol.
Systemic risks, such as dependence on staked ETH liquidity and oracle vulnerabilities, highlight the need for diversification and robust risk management strategies.
Overall, the DittoETH protocol shows promise as a decentralized stablecoin solution, but it requires further refinement, auditing, and community engagement to ensure its security, reliability, and long-term success.
- Conduct thorough testing, including unit tests, integration tests, and formal verification, to ensure the correctness and security of the protocol's complex interactions.
- Implement role-based access control mechanisms to restrict critical functions to authorized users or roles, mitigating potential abuse or spamming.
- Establish a robust governance framework, such as a DAO or multi-signature scheme, to distribute control and ensure transparency in admin actions.
- Enhance the validation of disputed short records in the redemption process to prevent invalid or malicious disputes.
- Adjust the incentive structure to encourage active and honest participation in the dispute process.
- Diversify collateral types to reduce dependence on a single staked ETH token and implement robust risk management mechanisms to handle liquidity crises or depegging events.
- Implement multiple redundant oracle systems and establish a robust oracle governance framework to ensure the reliability and security of price feeds.
- Conduct regular security audits, code reviews, and bug bounty programs to identify and address potential vulnerabilities.
- Foster an active and engaged community to provide feedback, contribute to protocol development, and participate in governance decisions.
- Continuously monitor and assess the protocol's performance, adapting and evolving as necessary to address emerging risks and market conditions.
22 hours