Rumpel Point Tokenization Protocol
Rumpel Point Tokenization ProtocolSherlock Judging
Rumpel enables points earned via any incentive or loyalty scheme – from Ethena, Zircuit, Symbiotic, etc – to be tokenized, traded, and used in DeFi without lockups or derivatives.
Details
Scope
On what chains are the smart contracts going to be deployed?
Ethereum mainnet.
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
Yes, whitelisted tokens only. They're assumed to not be reentrant, but fee-on-transfer, pausable, and blocklist tokens are OK.
Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
No
Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
Only those already implemented in Safe (for example that threshold must be greater than 0)
For permissioned functions, please list all checks and requirements that will be made before calling the function.
Simply that the role is correct, and, if the root is being updated on the vault, that users will be able to claim pTokens as expected afterwards (via fork test).
Is the codebase expected to comply with any EIPs? Can there be/are there any deviations from the specification?
No
Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, arbitrage bots, etc.)?
Yes.
There is an off-chain authorized responsibility to push merkle roots to the Vault on some interval.
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.
Are there any hardcoded values that you intend to change before (some) deployments?
Mainly just the role addresses in the forge deployment scripts.
If the codebase is to be deployed on an L2, what should be the behavior of the protocol in case of sequencer issues (if applicable)? Should Sherlock assume that the Sequencer won't misbehave, including going offline?
n/a
Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold?
No
Please discuss any design choices you made.
We chose to build on top of Safe.
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.
Please list any known issues and explicitly state the acceptable risks for each known issue.
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 will report issues where the core protocol functionality is inaccessible for at least 7 days. Would you like to override this value?
No
Please provide links to previous audits (if any).
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
Please list any relevant 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
Additional audit information.
The wallet is quite dependent on Safe, so familiarity with that system and its extensions is likely helpful. In addition, for the vault, while all of the code is in scope for the audit, this PR covers the changes since the most recent previous audit: https://github.com/sense-finance/point-tokenization-vault/pull/20/files
Total Rewards
16,000 USDC
Contest Pool
Lead Senior Watson
Judging Pool
Lead Judge
10,500 USDC
4,500 USDC
400 USDC
600 USDC
Status
Scope
Start Time
End Time
Judging Rules
