Reward Amounts

Critical

• $150,000 maximum payout

• Payout shall not exceed 10% of funds at risk at time of submission

Severity Criteria

Critical Definition

• Definite and significant loss of funds without limitations of external conditions
• Definite and significant freezing of funds for >1 year without limitations of external conditions

General Notes

• Sherlock’s Criteria for Issue Validity guide (used in Sherlock audit contests) can be a helpful resource for more context on out-of-scope issues, etc. but nothing in the guide should overrule the definitions above

• A coded Proof of Concept (POC) with instructions to run the POC is required

• If the protocol team has the ability to take measures (upgrade the contract, pause the contract, etc.) against an exploit, the potential damage is limited to a 1-hour exploit period before it is assumed that the protocol team takes measures to prevent further damage

• Only the first occurrence of a repeatable attack will be eligible for a payout. This rule applies regardless of the smart contract's upgradability, pausable state, or ability to be terminated.

Platform Rule

Please review the Sherlock Bug Bounty Platform Rules before submitting any vulnerability.

Known Issues and Acceptable Risks

Previously acknowledged issues from past audits must be considered acceptable risks.

This condition can be overridden if a previously acknowledged issue can cause an issue of higher severity than reported or combined with other acknowledged issues to cause a critical severity issue.

In the case where SuperPool vault tokens are used as collateral in Positions, it is acceptable that liquidations don't go through during periods of high utilization because of lack of liquidity to service SuperPool redemptions
The deposit and withdraw flows in the SuperPool sequentially deposit and withdraw from pools. This can be inefficient at times. We assume that the SuperPool owner will use the reallocate function to rebalance liquidity among pools.

The purpose of bad debt liquidation is to ensure that the pool can revert back to a functional state after socialization of bad debt. It is expected that a small share of lenders might be able to withdraw funds before the function is executed.

Previous Audits

1. https://github.com/sentimentxyz/protocol-v2/blob/master/audits/sentiment_v2_zobront.md
2. https://github.com/sentimentxyz/protocol-v2/blob/master/audits/sentiment_v2_guardian.pdf
3. https://github.com/sherlock-protocol/sherlock-reports/blob/main/audits/2024.08.24%20-%20Final%20-%20Sentiment%20V2%20Audit%20Report.pdf

Additional Context

Chains in scope

• Any EVM-compatbile network

Expected tokens

• Tokens are whitelisted, only tokens with valid oracles can be used to create Base Pools.

• Protocol governance will ensure that oracles are only set for standard ERC-20 tokens (plus USDC/USDT)

Trusted protocol roles

Offchain mechanisms and procedures

• Liquidator bots: maintain protocol solvency through timely liquidation of risky positions
• Reallocation bots: used to rebalance SuperPool deposits among respective base pools

Protocol Resources

• https://docs.sentiment.xyz