Reward Amounts

Critical

• $50000 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

Platform Rule

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

Known Issues and Acceptable Risks

• The authorized actor on the Rumpel module can execute arbitrary actions on behalf of Rumpel Wallets. Similar for the Vault. It is known that this is a risk, and that the management of privileged roles is crucial to the safe functioning of our system.
• In addition, signature-based reward claiming from external protocols is a risky with the Rumpel wallets, because we're dependent on them conforming to the erc 1271 standard, and if they accept owner-based signatures, we can't stop users from claiming themselves.
• We chose to block all user actions by default in the Rumpel Wallet, so that there's no chance they can claim and withdraw tokens that should be swept into the vault for pToken redemption.
• We chose a "fee on the borders" strategy in the vault where users are only charged for redemption if they redeem in excess of what they minted, pToken wise.
• We chose to depend on an off-chain actor to push merkle roots with the right pToken distribution, according to what each address/wallet earned. In the future, we plan to decentralize this function via AVS.

Previous Audits

2024.04.25 FPS Points Vault Audit: https://github.com/sense-finance/point-tokenization-vault/blob/main/audits/2024.04.25%20FPS%20Points%20Tokenization.pdf

2024.05.02 Darklinear Vault Audit: https://github.com/sense-finance/point-tokenization-vault/blob/main/audits/2024.05.02%20Darklinear%20Points%20Tokenization.pdf

2024.07.15 FPS Rumpel Wallet Audit: https://github.com/sense-finance/rumpel-wallet/blob/main/audits/2024.07.15%20FPS%20Rumpel%20Wallet.pdf

2024.08.29 Rumpel Point Tokenization Protoco: https://github.com/sherlock-protocol/sherlock-reports/blob/main/audits/2024.08.29%20-%20Final%20-%20Rumpel%20Point%20Tokenization%20Protocol%20Audit%20Report.pdf

Additional Context

Chains in scope

• Ethereum mainnet.

Expected tokens

• Whitelisted tokens only.
• They're assumed to not be reentrant, but fee-on-transfer, pausable, and blocklist tokens are OK.

Trusted protocol roles

• Protocol admins

Offchain mechanisms and procedures

1. There is an off-chain authorized responsibility to push merkle roots to the Vault on some interval.

2. Once reward tokens are released from added external protocols, an authorized actor must send claim and sweep transactions to every Rumpel Wallet (Safe with the Rumpel Guard and Rumpel Module added). These transactions would claim tokens from the external protocol, and pull them into the vault for pToken redemption.

Protocol Resources

The two READMEs are the best resources.

Vault: https://github.com/sense-finance/point-tokenization-vault/blob/dev/README.md

Wallet: https://github.com/sense-finance/rumpel-wallet/blob/main/README.md