SCSVS-GOV-1 |
S3.1.G1 |
No Test ID |
Verify correct handling of operational pauses and liquidations. |
- Does the protocol prevent liquidations during operational pauses or interruptions? |
|
|
|
|
- Are there mechanisms to handle user intentions to increase collateral during such pauses? |
|
|
|
|
- How does the system manage collateral and liquidation processes during temporary pauses? |
SCSVS-GOV-1 |
S3.1.G2 |
No Test ID |
Verify resumption of paused liquidations without issues. |
- What specific procedures are in place for resuming liquidations after a pause? |
|
|
|
|
- How is solvency monitored and maintained during and after a liquidation pause? |
|
|
|
|
- Are there mechanisms to ensure that resumed liquidations do not disrupt system stability? |
SCSVS-GOV-1 |
S3.1.G3 |
No Test ID |
Verify fair distribution of small position incentives. |
- Does the protocol provide adequate incentives for liquidators to address small positions? |
|
|
|
|
- How are incentives structured to ensure small positions are effectively managed? |
|
|
|
|
- Are there measures in place to prevent neglect of small liquidation opportunities? |
SCSVS-GOV-1 |
S3.1.G4 |
No Test ID |
Verify correct interest rate calculations in LTV computations. |
- Is accrued interest included in the Loan-to-Value (LTV) calculations? |
|
|
|
|
- How does the system ensure that interest is factored into credit evaluations accurately? |
|
|
|
|
- Are there checks to confirm that interest calculations do not affect LTV assessments? |
SCSVS-GOV-1 |
S3.1.G5 |
No Test ID |
Verify consistency in liquidation and repayment logic. |
- Can the liquidation and repaying mechanisms be independently enabled or disabled? |
|
|
|
|
- What controls are in place to ensure consistent operation of both mechanisms? |
|
|
|
|
- How does the protocol prevent operational discrepancies between liquidation and repaying functions? |
SCSVS-GOV-1 |
S3.1.G6 |
No Test ID |
Verify accuracy of liquidation return calculations. |
- Is there a mechanism to ensure that liquidation returns are consistent and predictable? |
|
|
|
|
- How does the protocol handle discrepancies in liquidation returns? |
|
|
|
|
- What steps are taken to ensure that liquidators receive the expected returns? |
SCSVS-GOV-1 |
S3.1.G7 |
No Test ID |
Verify mitigation of perpetual debt risks. |
- Can users be trapped in perpetual debt due to protocol conditions or system design? |
|
|
|
|
- What safeguards are in place to prevent users from being unable to repay their loans? |
|
|
|
|
- How does the protocol address situations where repayment becomes unfeasible? |
SCSVS-GOV-1 |
S3.1.G8 |
No Test ID |
Verify prevention of arbitrary exchange rate settings in withdrawals. |
- Can an arbitrary exchange rate be set during the processing of queued withdrawals? |
|
|
|
|
- Does the protocol ensure that the exchange rate used during withdrawal matches the rate at the time of withdrawal request? |
|
|
|
|
- Are there safeguards to prevent manipulation of the exchange rate during withdrawal processing? |
SCSVS-GOV-1 |
S3.1.G9 |
No Test ID |
Verify security of time lock amplification. |
- Can users extend another user’s time lock duration by stacking tokens on their behalf? |
|
|
|
|
- If token stacking is possible, are there checks to prevent unintended extensions of time locks? |
|
|
|
|
- Are there controls to ensure that time locks cannot be manipulated through token stacking? |
SCSVS-GOV-1 |
S3.1.G10 |
No Test ID |
Verify fairness of reward distribution mechanisms. |
- Can reward distribution be manipulated to delay or accelerate payouts? |
|
|
|
|
- If rewards are distributed, are there controls to ensure timely and correct distribution? |
|
|
|
|
- Are there mechanisms to prevent premature or delayed reward claims? |
SCSVS-GOV-1 |
S3.1.G11 |
No Test ID |
Verify security of update rewards function. |
- Does the updateRewards function get called appropriately before relevant operations? |
|
|
|
|
- Can the reward update function be overlooked or missed in any use-case scenarios? |
|
|
|
|
- Are there checks to ensure that rewards are up-to-date in all relevant cases? |
SCSVS-GOV-1 |
S3.1.G12 |
No Test ID |
Verify financial operation consistency. |
- Does calling a function multiple times with smaller amounts produce the same contract state as calling it once with the aggregate amount? |
|
|
|
|
- Are there inconsistencies or unintended discrepancies when performing financial operations in parts versus as a whole? |
|
|
|
|
- If variations exist, are they intentional and well-documented, or do they indicate potential issues? |
SCSVS-GOV-1 |
S3.1.G13 |
No Test ID |
Verify correct enforcement of AAVE protocol pauses. |
- What happens to protocol interactions if the AAVE protocol is paused? |
|
|
|
|
- Are there contingency plans or alternative mechanisms in place if AAVE is paused? |
|
|
|
|
- Does the protocol handle the paused state of AAVE without causing disruptions? |
SCSVS-GOV-1 |
S3.1.G14 |
No Test ID |
Verify removal of deprecated pools. |
- What mechanisms are in place to handle pools that become deprecated? |
|
|
|
|
- If a pool is deprecated, how does the protocol adjust or manage its operations? |
|
|
|
|
- Are there fallback strategies for deprecated pools to avoid service interruptions? |
SCSVS-GOV-1 |
S3.1.G15 |
No Test ID |
Verify correct classification of eMode category assets. |
- What are the rules or limitations when lending or borrowing assets within the same eMode category? |
|
|
|
|
- Does the protocol handle transactions involving assets in the same eMode category without issues? |
|
|
|
|
- Are there constraints in place for interacting with assets in the same eMode category? |
SCSVS-GOV-1 |
S3.1.G16 |
No Test ID |
Verify accuracy of flash loan pool index calculations. |
- Do flash loans impact the pool index, and if so, how is this managed? |
|
|
|
|
- Are there mechanisms to mitigate the effects of flash loans on the pool index? |
|
|
|
|
- How does the protocol address the maximum number of flash loans per block affecting the pool index? |
SCSVS-GOV-1 |
S3.1.G17 |
No Test ID |
Verify correct implementation of on-chain slippage calculations. |
- Is slippage calculated on-chain? |
|
|
|
|
- Can users specify the slippage parameter in the asset amount? |
|
|
|
|
- What measures are in place to ensure accurate slippage calculation? |
SCSVS-GOV-1 |
S3.1.G18 |
No Test ID |
Verify minimization of intermediate swap slippage. |
- Is the slippage parameter enforced at the last step before transferring funds to users? |
|
|
|
|
- How is slippage enforced during the final fund transfer step? |
|
|
|
|
- Does the system check the slippage parameter before completing transactions? |
SCSVS-GOV-1 |
S3.1.G19 |
No Test ID |
Verify enforcement of zero denominator checks. |
- Is there a non-zero check for the denominator before division or modulo operations? |
|
|
|
|
- How does the system handle division or modulo by zero in Yul/inline assembly? |
|
|
|
|
- What measures are in place to prevent division or modulo by zero? |
SCSVS-GOV-1 |
S3.1.G20 |
No Test ID |
Verify Two Transaction Actions Frontrunning |
- Are two-transaction actions designed with measures to prevent frontrunning? Verify if there are checks or locks between transactions. |
|
|
|
|
- How does the protocol ensure that critical two-step actions are not vulnerable to attack during the intermediary state? |
|
|
|
|
- Are there safeguards to prevent malicious actors from intervening between the two transactions? |
SCSVS-GOV-1 |
S3.1.G21 |
No Test ID |
Verify Dust Transactions Reversion |
- Can users front-run transactions with negligible amounts to cause reverts? Verify the contract’s handling of such scenarios. |
|
|
|
|
- Are there checks to prevent transactions with minimal amounts from impacting the contract's state or execution flow? |
|
|
|
|
- How does the contract manage or mitigate the effects of dust transactions on legitimate operations? |
SCSVS-GOV-1 |
S3.1.G22 |
No Test ID |
Verify Unexpected Rewards Handling |
- Are there additional rewards accruing for user deposited assets? |
|
|
|
|
- Does the protocol track and manage all potential rewards for user deposits? |
|
|
|
|
- Are users provided with clear methods to claim or manage unexpected rewards? |
SCSVS-GOV-1 |
S3.1.G23 |
No Test ID |
Ensure Stability for Pegged Tokens |
- Are the protocol tokens pegged to any other asset? |
|
|
|
|
- Have you tested the protocol’s behavior when the pegged asset depegs? |
SCSVS-GOV-1 |
S3.1.G24 |
No Test ID |
Verify Visibility Modifier |
- Is the visibility of each function limited to the strictest level necessary (private or internal)? |
|
|
|
|
- Are there any functions that are currently public or external but could be restricted to internal or private? |
|
|
|
|
- Does the contract expose any sensitive operations or state changes to external parties that should be restricted? |
SCSVS-GOV-2 |
S3.2.G1 |
No Test ID |
Verify ERC20 Compliance |
- Are the token's transfer functions (transfer, transferFrom) fully compliant with the EIP20 standard, including returning a boolean flag and reverting on failure? |
|
|
|
|
- Are safe transfer functions (safeTransfer, safeTransferFrom) consistently used throughout the contract? |
SCSVS-GOV-2 |
S3.2.G2 |
No Test ID |
Verify Approval Race Condition |
- Is there a risk of race conditions in the approval process that could lead to unexpected fund loss for the signer? |
|
|
|
|
- Are there mechanisms in place to prevent double-spending or front-running attacks? |
SCSVS-GOV-2 |
S3.2.G3 |
No Test ID |
Verify Decimal Discrepancies |
- Could differences in the number of decimals between various ERC20 tokens lead to calculation or interpretation errors? |
|
|
|
|
- Are there any conversions or calculations that might be affected by differing decimal places? |
SCSVS-GOV-2 |
S3.2.G4 |
No Test ID |
Verify Caller Checking |
- Does the function restrict calls to only externally owned accounts (EOA) or only contract addresses as intended? |
|
|
|
|
- Are there access control checks in place to differentiate between EOA and contract callers when required? |
|
|
|
|
- Has the protocol been reviewed to ensure it meets the intended caller requirements? |
SCSVS-GOV-2 |
S3.2.G5 |
No Test ID |
Verify Address Checks |
- Does the token implement any forms of address whitelisting, blacklisting, or validation checks that could introduce issues? |
|
|
|
|
- Are there any hardcoded addresses in the contract that could pose security risks? |
SCSVS-GOV-2 |
S3.2.G6 |
No Test ID |
Verify Transfer Fees |
- Does the token impose a fee on transfers, resulting in the receiver getting less than the specified amount? |
|
|
|
|
- How are transfer fees calculated and collected? |
SCSVS-GOV-2 |
S3.2.G7 |
No Test ID |
Verify ERC777 Compatibility |
- Can the token also function as an ERC777 token, which includes hooks that execute code before and after transfers, potentially leading to reentrancy attacks? |
|
|
|
|
- Are there safeguards in place to handle the hooks securely? |
SCSVS-GOV-2 |
S3.2.G8 |
No Test ID |
Verify Solmate's ERC20.safeTransferLib Usage |
- Does the protocol utilize Solmate's ERC20.safeTransferLib, which does not check for the existence of a contract and could be exploited for honeypot attacks? |
|
|
|
|
- Are there alternative libraries or methods that could enhance security? |
SCSVS-GOV-2 |
S3.2.G9 |
No Test ID |
Verify Zero Amount Transfers |
- What is the token's behavior when transferring a zero amount? Does it revert, and could this cause issues in certain integrations and operations? |
|
|
|
|
- Are there any edge cases related to zero-amount transfers? |
SCSVS-GOV-2 |
S3.2.G10 |
No Test ID |
Verify ERC2612 Implementation |
- Is the token an ERC2612 implementation, and is the DOMAIN_SEPARATOR() function properly implemented to avoid vulnerabilities? |
|
|
|
|
- How is the permit() function implemented, and are there any potential issues? |
SCSVS-GOV-2 |
S3.2.G11 |
No Test ID |
Verify Permit Function Replay Protection |
- Does the permit() function have adequate replay protection, or could someone reuse a permit signature multiple times to authorize multiple transfers? |
|
|
|
|
- Is the nonces mapping updated correctly, and does the implementation properly prevent replays? |
SCSVS-GOV-3 |
S3.3.G1 |
No Test ID |
Verify Token Donation Manipulation |
- Does the contract rely on balance or balanceOf for determining token balances or ownership? If so, are there safeguards against manipulation through token donations? |
|
|
|
|
- Are token balances verified against internal accounting records rather than solely using balanceOf? |
|
|
|
|
- Does the contract implement additional validation to ensure donated tokens do not alter accounting in unexpected ways? |
SCSVS-GOV-3 |
S3.3.G2 |
No Test ID |
Detect On-Chain Slippage Manipulation |
- Is slippage calculated directly on-chain? |
|
|
|
|
- Can the slippage calculation be influenced or manipulated by attackers? |
|
|
|
|
- Is there a mechanism to allow users to specify slippage based on off-chain calculations? |
SCSVS-GOV-3 |
S3.3.G3 |
No Test ID |
Ensure Slippage is Enforced at All Stages |
- Is the slippage parameter enforced at all stages of the swap process, including the final step? |
|
|
|
|
- Can users receive less than the specified minimum if the final step does not enforce slippage? |
SCSVS-GOV-3 |
S3.3.G4 |
No Test ID |
Verify Initial Deposit Behavior |
- Does the initial deposit set parameters or conditions for subsequent deposits? |
|
|
|
|
- Have you tested to ensure that the first deposit initializes parameters correctly? |
SCSVS-GOV-3 |
S3.3.G5 |
No Test ID |
Verify Read-Only Reentrancy |
- Are there view functions that could be reentered in a way that might return stale or inconsistent values? |
|
|
|
|
- Does the contract have measures to prevent reentrancy issues in view functions, such as extending reentrancy guards? |
|
|
|
|
- How does the protocol ensure that read-only functions do not lead to inconsistent state or unintended actions? |
SCSVS-GOV-3 |
S3.3.G6 |
No Test ID |
Prevent Flashloan-Based Withdrawals |
- Is it possible to withdraw in the same transaction as the deposit? |
|
|
|
|
- Does the protocol have protections against flashloan-based deposit-harvest-withdraw cycles? |
SCSVS-GOV-3 |
S3.3.G7 |
No Test ID |
Ensure Liquidation Resilience in Volatile Markets |
- Does the liquidation mechanism include logic to handle extreme price drops effectively? |
|
|
|
|
- Is there a safeguard to ensure liquidation occurs even when price volatility is high? |
|
|
|
|
- How is the liquidation trigger threshold adjusted during rapid market downturns? |
SCSVS-GOV-3 |
S3.3.G8 |
No Test ID |
Manage Risks in Liquidation Processes |
- Is there a mechanism to automatically trigger liquidation if a position's collateral falls below the required threshold? |
|
|
|
|
- Are there specific conditions that can prevent liquidation, and how are these managed? |
|
|
|
|
- How does the system handle outstanding loans when the collateral value drops significantly? |
SCSVS-GOV-3 |
S3.3.G9 |
No Test ID |
Prevent Self-Liquidation Abuse |
- Is there validation to prevent users from exploiting self-liquidation for profit? |
|
|
|
|
- How are self-liquidation scenarios tested for potential vulnerabilities? |
|
|
|
|
- Are there limits or conditions imposed on self-liquidation to prevent abuse? |
SCSVS-GOV-3 |
S3.3.G10 |
No Test ID |
Verify Parent Contract Visibility |
- Have you reviewed the visibility of functions in parent contracts to ensure they are appropriately exposed? |
|
|
|
|
- Are there any public or external functions in parent contracts that should be restricted or hidden in the derived contract? |
|
|
|
|
- Is the visibility of inherited functions aligned with the desired access levels? |
SCSVS-GOV-3 |
S3.3.G11 |
No Test ID |
Verify Commit Reveal Scheme |
- Does the protocol implement a commit-reveal scheme to protect against front-running? Verify the presence of both commit and reveal phases. |
|
|
|
|
- How does the protocol ensure that the commit-reveal pattern is followed to prevent adversaries from gaining insight into actions before they are finalized? |
|
|
|
|
- Are there mechanisms in place to ensure confidentiality and integrity of actions until the reveal phase? |
SCSVS-GOV-3 |
S3.3.G12 |
No Test ID |
Ensure Dynamic Slippage Implementation |
- Is slippage implemented as a hardcoded value in the contract? |
|
|
|
|
- Have you ensured that slippage can be adjusted dynamically based on market conditions? |
|
|
|
|
- Is there functionality allowing users to specify slippage parameters based on their own calculations? |
SCSVS-GOV-3 |
S3.3.G13 |
No Test ID |
Validate Deadline Protection Mechanisms |
- Does the protocol implement deadline protection to prevent transactions from being manipulated? |
|
|
|
|
- Is there an option for users to set deadlines for their transactions? |
|
|
|
|
- Have you validated that transactions cannot be processed outside the specified deadline? |
SCSVS-GOV-3 |
S3.3.G14 |
No Test ID |
Ensure Proper Reserve Validation |
- Is there a validation check in place for protocol reserves? |
|
|
|
|
- Have you ensured that reserves are verified before being used or lent out? |
|
|
|
|
- Does the protocol include mechanisms to safeguard against reserve depletion? |
SCSVS-GOV-3 |
S3.3.G15 |
No Test ID |
Ensure Slippage Protection |
- Is there a mechanism to protect against excessive slippage in trades? |
|
|
|
|
- Can users specify their own slippage parameters to manage risk? |
|
|
|
|
- Are there safeguards to prevent losses from large price deviations? |
SCSVS-GOV-3 |
S3.3.G16 |
No Test ID |
Ensure Reliable Min Amount Out Calculation |
- Does the protocol calculate minAmountOut before executing swaps? |
|
|
|
|
- Is the source of rates for minAmountOut reliable and protected from manipulation? |
|
|
|
|
- Have you validated the minAmountOut logic to prevent unfavorable rates and potential vulnerabilities? |