TRUST Summit | Nov 3, 2025 | NYCWhere decision-makers define the next chapter of secure blockchain adoption.
Learn more

Re Protocol

Audit name:

[SCA] Re | Re-Contracts | Nov2024

Date:

Dec 31, 2024

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Appendix 3. Additional Valuables
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Re team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

The Re Protocol is a decentralized foundation built to invest in Reinsurance contracts in exchange for profits.

Document

NameSmart Contract Code Review and Security Analysis Report for Re
Audited ByNiccolò Pozzolini, Viktor Raboshchuk
Approved ByPrzemyslaw Swiatowiec
Websitehttps://re.xyz→
Changelog13/12/2024 - Preliminary Report; 31/12/2024 - Second Review
PlatformEVM, Avalanche, Arbiturm, Base
LanguageSolidity
TagsPool; Insurance
Methodologyhttps://hackenio.cc/sc_methodology→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Re
    Audited By
    Niccolò Pozzolini, Viktor Raboshchuk
    Approved By
    Przemyslaw Swiatowiec
    Website
    https://re.xyz→
    Changelog
    13/12/2024 - Preliminary Report; 31/12/2024 - Second Review
    Platform
    EVM, Avalanche, Arbiturm, Base
    Language
    Solidity
    Tags
    Pool; Insurance
    Methodology
    https://hackenio.cc/sc_methodology→

Review Scope

Repositoryhttps://github.com/resilience-foundation/re-defi→
Commit11ec0f4019b1441ef6eedf642c03cff8761fd9bf

Audit Summary

15Total Findings
15Resolved
0Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Functional requirements are complete.

  • Technical description is provided.

Code quality

  • The development environment requires fixes to be run.

Test coverage

Code coverage of the project is N/A.

  • The tests predominantly rely on mock contracts rather than the original implementations, which raises concerns about their effectiveness in verifying the correctness of the contract logic. As a result, the reliability of the tests is compromised.

System Overview

The Re Protocol is a decentralized foundation designed to invest in reinsurance contracts, enabling members to earn profits through strategic investments. It has the following contracts:

The InsuranceCapitalLayer (ICL) serves as the primary repository for all unallocated funds within the Re Protocol. Members deposit approved tokens into the ICL, receiving USDRE tokens in return based on the current conversion rate. The ICL categorizes assets into three distinct buckets: unallocated assets available for new proposals, allocated but undeployed assets designated for risk pools, and assets earmarked for redemptions

The CollateralManager contract handles the reservation, withdrawal, and return of collateral from the InsuranceCapitalLayer (ICL) to individual pools.

The Pool contract represents individual investment pools managed by Cell Managers within the Re Protocol. Each Pool is associated with a specific Cell Manager who is responsible for creating and overseeing the pool’s operations. Pools are created based on proposals that outline the terms, conditions, and reinsurance targets. Upon approval, Pools receive funds from the InsuranceCapitalLayer to deploy into reinsurance contracts.

The Prestaking contract facilitates the initial deposit phase for users before they complete KYC verification. It securely holds users’ tokens and allows for their transfer to the InsuranceCapitalLayer (ICL) once verification is complete and the depositTokenRegistry is updated. By managing pre-verification deposits, Prestaking ensures that funds are safely stored and only moved into the protocol’s active investment mechanisms upon meeting compliance requirements.

The ConvertDecimals library is a utility contract designed to facilitate the conversion of token amounts between varying decimal precisions and a standardized 18 decimal places.

Privileged roles

  • The Prestaking contract has several roles. ADMIN_ROLE  can update the deposit token registry reference using setDepositTokenRegistry, change the verifier authorized to sign deposit requests using setVerifier, adjust the signature expiration timeframe with setSignatureExpiration, or enable and disable new deposits. OPERATOR_ROLE can process or cancel deposits. UPGRADER_ROLE have the ability to upgrade the contract’s implementation. PAUSER_ROLE can pause or unpause contract functionality.

  • The COLLATERAL_ADMIN role from CollateralManager contract have full authority over approving, rejecting, and canceling requests related to collateral handling. This includes verifying collateral reservation requests, allowing or blocking actual collateral transfers to pools, overseeing both undeployed and deployed collateral returns. Additionally, they manage profit return requests and collateral limit increases.

  • The Pool contract has several roles. Holders of the CONTROLLER_ROLE can update the deposit token registry reference. Addresses with the COLLATERAL_PROVIDER_ROLE can update the pool’s collateral limit via the updateCollateralLimit function.

  • The InsuranceCapitalLayer contract has several roles. The OPERATOR_ROLE  can enable or disable deposits, update references to token registries or share price calculators, and set collateral or redemption managers. FEE_MANAGER_ROLE can claim accumulated deposit fees. The CUSTODIAN_MANAGER_ROLE is responsible for adding or removing custodians for specific tokens. Addresses with the PAUSER_ROLE can pause and unpause contract operations.

Potential Risks

The depositNative function in the InsuranceCapitalLayer contract assumes that the value of Wrapped Ether (WETH) is equivalent to the value of Ether (ETH). This assumption may not hold true in the event of a depeg, potentially exposing the protocol to risks associated with inflated deposit valuations.

The CollateralManager contract prematurely reserves capital when pools submit reservation requests, rather than waiting for administrative approval. This design choice allows a malicious pool to artificially inflate the total reserved amount by continuously submitting reservation requests, potentially making capital unavailable to legitimate pools. While this denial-of-service attack can be mitigated by the protocol administrator unregistering the malicious pool, the system remains vulnerable until such intervention occurs.  This behavior also affects the output of CollateralManager.getReservedAmount which does not take into account the un-approved reservations, thus the actually reserved amount would be higher.

The audit scope excludes several critical dependencies including PoolRegistry, DepositTokenRegistry, SharePriceCalculator, and KYCRegistry contracts. This represents a significant security concern as the in-scope contracts heavily rely on interactions with these external contracts for core functionality. Without a comprehensive audit of these dependencies, it's impossible to fully assess the security implications of their interactions with the audited contracts.

Findings

Code
―
Title
Status
Severity
F-2024-7499Potential Funds Lock Due to CANCEL_TIMEOUT Restriction in cancelDeposit Function
fixed

High
F-2024-7497Incorrect Allowance Handling in Pool Contract for Collateral Return Functions
fixed

High
F-2024-7489Incorrect Fee Handling in Collateral Return and Profit Return Processes
fixed

High
F-2024-7551Lack of Available Balance Check in approveCollateralTransfer Function
fixed

Medium
F-2024-7490Incorrect Collateral Return Check in requestProfitReturn Function
fixed

Medium
F-2024-7640Lack of Dedicated Capital Deployment Mechanism and Related Accounting
fixed

Medium
F-2024-7637Missing Transfer Date Validation in requestCollateralTransfer
fixed

Low
F-2024-7550Lack of Capital Reservation Mechanism in approveCollateralReservation Function
fixed

Low
F-2024-7533CEI Violation in processDeposits Function
fixed

Low
F-2024-7632Recurring Checks Should Be Implemented As Modifiers
fixed

Observation
1-10 of 15 findings

Identify vulnerabilities in your smart contracts.

Appendix 1. Definitions

Severities

When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.

Reference on how risk scoring is done is available through the repository in our Github organization:

Severity

Description

Critical
Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

High
High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

Medium
Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

Low
Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

  • Severity

    Critical

    Description

    Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

    Severity

    High

    Description

    High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

    Severity

    Medium

    Description

    Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

    Severity

    Low

    Description

    Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

Potential Risks

The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.

Appendix 2. Scope

The scope of the project includes the following smart contracts from the provided repository:

Scope Details

Repositoryhttps://github.com/resilience-foundation/re-defi→
Commit11ec0f4019b1441ef6eedf642c03cff8761fd9bf
Whitepaper-
RequirementsTechnical and functional doc→
Technical RequirementsTechnical and functional doc→

Assets in Scope

CollateralManager.sol - CollateralManager.sol
InsuranceCapitalLayer.sol - InsuranceCapitalLayer.sol
interfaces
ICollateralAdmin.sol - interfaces › ICollateralAdmin.sol
ICollateralProvider.sol - interfaces › ICollateralProvider.sol
ICollateralTokenHandler.sol - interfaces › ICollateralTokenHandler.sol
ICustodianManager.sol - interfaces › ICustodianManager.sol
IDecentralizedFund.sol - interfaces › IDecentralizedFund.sol
IDepositManager.sol - interfaces › IDepositManager.sol
IDepositTokenRegistry.sol - interfaces › IDepositTokenRegistry.sol
IInsuranceCapitalLayer.sol - interfaces › IInsuranceCapitalLayer.sol
IKYCRegistry.sol - interfaces › IKYCRegistry.sol
IPool.sol - interfaces › IPool.sol
IPoolRegistry.sol - interfaces › IPoolRegistry.sol
IPrestaking.sol - interfaces › IPrestaking.sol
IRedemptionTokenHandler.sol - interfaces › IRedemptionTokenHandler.sol
ISharePriceCalculator.sol - interfaces › ISharePriceCalculator.sol
IWETH.sol - interfaces › IWETH.sol
Pool.sol - Pool.sol
Prestaking.sol - Prestaking.sol
utils
ConvertDecimals.sol - utils › ConvertDecimals.sol

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Resilience-Foundation, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.

Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 30 invariants were tested over 20000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.

Invariant

Test Result

Run Count

testFuzz_RequestCollateralTransfer verifies that the pool's token balance accurately reflects the transfer and that the collateral handler's balance decreases accordingly. The test confirms that attempts to cancel a non-pending transfer correctly revert, maintaining the integrity of the transfer processPassed20K+
testFuzz_RequestCollateralLimitIncrease verifies that any request to increase the collateral limit is only approved when the requested limit surpasses the current limit. It ensures that the collateral limit is updated accurately upon approval, preventing unauthorized or insufficient limit adjustments.Passed20K+
testFuzz_GetTotalValue verifies that the total value of reserved collateral accurately reflects the sum of individual reservations. It ensures that the pool's token balance decreases by the total transferred amount and that the collateral handler's balance increases accordingly.Passed20K+
testFuzz_CancelCollateralReservation ensures that canceling a collateral reservation correctly updates the reservation's status to "Canceled" without affecting the pool's or collateral handler's token balances. It verifies that the cancellation process does not inadvertently alter token distributions.Passed20K+
testFuzz_GetTotalReturnedCollateral verifies that the total returned collateral accurately accounts for all approved return requests.Passed20K+
testFuzz_UndeployedReturnRequestStatusTransitions verifies that the status transitions of undeployed collateral return requests adhere to the defined workflow, moving from "Pending" to "Approved" only upon proper authorization. It ensures that only valid status transitions occur, preventing unauthorized changes and maintaining the correct lifecycle of return requests.Passed20K+
testFuzz_Deposit ensures that when a user deposits a valid amount of tokens, the corresponding share tokens are correctly minted, and the contract's token balance accurately reflects the deposited amount. It verifies that the user's share balance increases proportionally and that the token handler's balance decreases accordingly, maintaining the consistency of token distributions.Passed20K+
testFuzz_DepositWhenDisabled verifies that deposits are appropriately restricted when deposit functionality is disabled. It ensures that any attempt to deposit tokens while deposits are turned off results in a revertPassed20K+
testFuzz_DepositWithFees verifies that when a user makes a deposit with applicable fees, the deposit amount is correctly adjusted after deducting the fixed fee. It confirms that the user's share balance reflects the net amount after fees and that the total deposit fees are accurately recorded.Passed20K+
testFuzz_DepositNative verifies that users can deposit native tokens (e.g., WETH) correctly, updating the corresponding share balances. It verifies that the contract accurately reflects the deposited native amount and that the user's share balance aligns with the expected value.Passed20K+
testFuzz_DepositNativeWithFees confirms that depositing native tokens with applicable fees results in the correct deduction of fees and accurate reflection of net deposit amounts. It ensures that the user's share balance accounts for the deducted fees and that the total deposit fees are properly tracked.Passed20K+
testFuzz_CustodianManagement validates the proper addition and removal of custodians for specific tokens. It ensures that only authorized custodians can be added or removed and that the custodial relationships are accurately reflected in the contract's statePassed20K+
testFuzz_TransferToCustodian verifies that transferring assets to a designated custodian is executed correctly. It ensures that the specified amount is accurately moved from the contract to the custodian's address and that the token balances of both the custodian and the contract are updated appropriately.Passed20K+
testFuzz_SharePriceConversion verifies accurate conversion between share tokens and underlying token amounts. It verifies that the conversion functions correctly calculate the expected share amounts and token amounts.Passed20K+
testFuzz_RedemptionTokenManagement validates the proper handling of token redemptions, including burning and transferring share tokens. It ensures that share tokens are correctly burned or transferred as part of the redemption process and that the user's redemption deposits are accurately updated.Passed20K+
testFuzz_ClaimDepositFees validates that deposit fees are correctly claimed by the designated fee manager. It verifies that the claimed fee amount matches the expected fixed fee and that the fee manager's token balance increases accordingly.Passed20K+
testFuzz_RequestCollateralTransfer_ExceedsReservedAmount verifies that the system correctly enforces reservation limits by reverting the transfer request when the transfer amount surpasses the reserved collateral.Passed20K+
testFuzz_RequestDeployedCollateralReturn_DifferentTokens verifies that collateral return requests involving different tokens with varying decimals are handled accurately. It verifies that the contract correctly registers the return request, sets appropriate allowances, and maintains consistent token balancesPassed20K+
testFuzz_RequestUndeployedCollateralReturn_DifferentDecimals confirms that undeployed collateral return requests for tokens with varying decimals are processed correctly. It ensures that the system accurately registers the return request, manages token allowances appropriately, and maintains precise token balances.Passed20K+
testFuzz_CollateralLimitIncrease verifies that collateral limit increases adhere strictly to predefined constraints and authorization protocols. It ensures that only requests exceeding the current collateral limit are approved, prevents unauthorized actors from modifying the collateral limit, and enforces that the collateral limit cannot be decreased.Passed20K+
testFuzz_RequestDeposit verifies that when a user requests a deposit with a valid signature and sufficient token balance, the deposit is accurately recorded in the contract. It verifies that the user's token balance decreases by the deposited amount and that the contract's balance increases accordingly.Passed20K+
testFuzz_CancelDeposit verifies that a user can successfully cancel a previously made deposit before it is processed. It ensures that the deposit status is updated to "Cancelled" and that the user's token balance is correctly restored.Passed20K+
testFuzz_ProcessDeposits verifies that the contract correctly processes multiple pending deposits for a user. It verifies that each processed deposit updates the contract's internal state appropriately, marks deposits as processed, and increments the count of processed deposits.Passed20K+
testFuzz_MaxDepositsPerUser verifies that the contract enforces a strict limit on the number of concurrent deposits a user can have. It ensures that once a user reaches the maximum allowed deposits, any additional deposit requests are rejected.Passed20K+
testFuzz_SignatureExpiration verifies that the contract correctly handles deposit requests with expired signatures. It verifies that any attempt to make a deposit using a signature beyond its validity period results in a revert.Passed20K+
testFuzz_convertTo18 verifies that the convertTo18 function accurately scales amounts from varying decimal precisions to 18 decimals without causing overflows. It verifies that the converted amount matches the expected scaled value.Passed20K+
testFuzz_convertFrom18 verifies that the convertFrom18 function correctly converts amounts from 18 decimals down to varying lower decimal precisions without causing overflows. It ensures that the resulting amount aligns with the expected scaled-down value, preserving the correctness of the decimal normalization process.Passed20K+
testFuzz_normaliseTo18 verifies that the normaliseTo18 function properly adjusts amounts to 18 decimals based on a given precision factor, preventing overflows during the normalization process. It verifies that the normalized amount accurately reflects the expected scaled value.Passed20K+
testFuzz_normaliseFrom18 verifies that the normaliseFrom18 function effectively scales amounts from 18 decimals to a specified precision factor without causing overflows. It ensures that the normalized amount matches the expected value, maintaining the correctness of the normalization from 18 decimals.Passed20K+
testFuzz_convertFrom18AndRoundUpverifies that the convertFrom18AndRoundUp function accurately converts amounts from 18 decimals to lower decimals and appropriately rounds up when necessary, without causing overflows. It verifies that the conversion and rounding logic produces the expected scaled and rounded amount.Passed20K+

  • Invariant

    testFuzz_RequestCollateralTransfer verifies that the pool's token balance accurately reflects the transfer and that the collateral handler's balance decreases accordingly. The test confirms that attempts to cancel a non-pending transfer correctly revert, maintaining the integrity of the transfer process

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_RequestCollateralLimitIncrease verifies that any request to increase the collateral limit is only approved when the requested limit surpasses the current limit. It ensures that the collateral limit is updated accurately upon approval, preventing unauthorized or insufficient limit adjustments.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_GetTotalValue verifies that the total value of reserved collateral accurately reflects the sum of individual reservations. It ensures that the pool's token balance decreases by the total transferred amount and that the collateral handler's balance increases accordingly.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_CancelCollateralReservation ensures that canceling a collateral reservation correctly updates the reservation's status to "Canceled" without affecting the pool's or collateral handler's token balances. It verifies that the cancellation process does not inadvertently alter token distributions.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_GetTotalReturnedCollateral verifies that the total returned collateral accurately accounts for all approved return requests.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_UndeployedReturnRequestStatusTransitions verifies that the status transitions of undeployed collateral return requests adhere to the defined workflow, moving from "Pending" to "Approved" only upon proper authorization. It ensures that only valid status transitions occur, preventing unauthorized changes and maintaining the correct lifecycle of return requests.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_Deposit ensures that when a user deposits a valid amount of tokens, the corresponding share tokens are correctly minted, and the contract's token balance accurately reflects the deposited amount. It verifies that the user's share balance increases proportionally and that the token handler's balance decreases accordingly, maintaining the consistency of token distributions.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_DepositWhenDisabled verifies that deposits are appropriately restricted when deposit functionality is disabled. It ensures that any attempt to deposit tokens while deposits are turned off results in a revert

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_DepositWithFees verifies that when a user makes a deposit with applicable fees, the deposit amount is correctly adjusted after deducting the fixed fee. It confirms that the user's share balance reflects the net amount after fees and that the total deposit fees are accurately recorded.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_DepositNative verifies that users can deposit native tokens (e.g., WETH) correctly, updating the corresponding share balances. It verifies that the contract accurately reflects the deposited native amount and that the user's share balance aligns with the expected value.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_DepositNativeWithFees confirms that depositing native tokens with applicable fees results in the correct deduction of fees and accurate reflection of net deposit amounts. It ensures that the user's share balance accounts for the deducted fees and that the total deposit fees are properly tracked.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_CustodianManagement validates the proper addition and removal of custodians for specific tokens. It ensures that only authorized custodians can be added or removed and that the custodial relationships are accurately reflected in the contract's state

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_TransferToCustodian verifies that transferring assets to a designated custodian is executed correctly. It ensures that the specified amount is accurately moved from the contract to the custodian's address and that the token balances of both the custodian and the contract are updated appropriately.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_SharePriceConversion verifies accurate conversion between share tokens and underlying token amounts. It verifies that the conversion functions correctly calculate the expected share amounts and token amounts.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_RedemptionTokenManagement validates the proper handling of token redemptions, including burning and transferring share tokens. It ensures that share tokens are correctly burned or transferred as part of the redemption process and that the user's redemption deposits are accurately updated.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_ClaimDepositFees validates that deposit fees are correctly claimed by the designated fee manager. It verifies that the claimed fee amount matches the expected fixed fee and that the fee manager's token balance increases accordingly.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_RequestCollateralTransfer_ExceedsReservedAmount verifies that the system correctly enforces reservation limits by reverting the transfer request when the transfer amount surpasses the reserved collateral.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_RequestDeployedCollateralReturn_DifferentTokens verifies that collateral return requests involving different tokens with varying decimals are handled accurately. It verifies that the contract correctly registers the return request, sets appropriate allowances, and maintains consistent token balances

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_RequestUndeployedCollateralReturn_DifferentDecimals confirms that undeployed collateral return requests for tokens with varying decimals are processed correctly. It ensures that the system accurately registers the return request, manages token allowances appropriately, and maintains precise token balances.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_CollateralLimitIncrease verifies that collateral limit increases adhere strictly to predefined constraints and authorization protocols. It ensures that only requests exceeding the current collateral limit are approved, prevents unauthorized actors from modifying the collateral limit, and enforces that the collateral limit cannot be decreased.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_RequestDeposit verifies that when a user requests a deposit with a valid signature and sufficient token balance, the deposit is accurately recorded in the contract. It verifies that the user's token balance decreases by the deposited amount and that the contract's balance increases accordingly.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_CancelDeposit verifies that a user can successfully cancel a previously made deposit before it is processed. It ensures that the deposit status is updated to "Cancelled" and that the user's token balance is correctly restored.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_ProcessDeposits verifies that the contract correctly processes multiple pending deposits for a user. It verifies that each processed deposit updates the contract's internal state appropriately, marks deposits as processed, and increments the count of processed deposits.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_MaxDepositsPerUser verifies that the contract enforces a strict limit on the number of concurrent deposits a user can have. It ensures that once a user reaches the maximum allowed deposits, any additional deposit requests are rejected.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_SignatureExpiration verifies that the contract correctly handles deposit requests with expired signatures. It verifies that any attempt to make a deposit using a signature beyond its validity period results in a revert.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_convertTo18 verifies that the convertTo18 function accurately scales amounts from varying decimal precisions to 18 decimals without causing overflows. It verifies that the converted amount matches the expected scaled value.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_convertFrom18 verifies that the convertFrom18 function correctly converts amounts from 18 decimals down to varying lower decimal precisions without causing overflows. It ensures that the resulting amount aligns with the expected scaled-down value, preserving the correctness of the decimal normalization process.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_normaliseTo18 verifies that the normaliseTo18 function properly adjusts amounts to 18 decimals based on a given precision factor, preventing overflows during the normalization process. It verifies that the normalized amount accurately reflects the expected scaled value.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_normaliseFrom18 verifies that the normaliseFrom18 function effectively scales amounts from 18 decimals to a specified precision factor without causing overflows. It ensures that the normalized amount matches the expected value, maintaining the correctness of the normalization from 18 decimals.

    Test Result

    Passed

    Run Count

    20K+

    Invariant

    testFuzz_convertFrom18AndRoundUpverifies that the convertFrom18AndRoundUp function accurately converts amounts from 18 decimals to lower decimals and appropriately rounds up when necessary, without causing overflows. It verifies that the conversion and rounding logic produces the expected scaled and rounded amount.

    Test Result

    Passed

    Run Count

    20K+

Additional Recommendations

The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.

To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:

  • Detecting changes to ownership or critical permissions.

  • Monitoring large or unexpected transactions and minting events.

  • Pausing operations when irregularities are identified.

These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.

Disclaimer