- Join Sherlock Discord
- Submit findings using the Issues page in your private contest repo (label issues as Medium or High)
- Read for more details
We have two sets of contracts, one in Solidity (rova-contracts) and one in Move (rova-movement-contracts).
Chains:
- rova-contracts - Base, Ethereum
- rova-movement-contracts - Movement
Q: 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?
For rova-contracts
- The manager role can configure tokens that can be used as payment currency for token sales. These should be transferable ERC20 tokens.
- Examples of tokens we intend to use: USDC, USDT, Eth Mainnet MOVE (ERC20 with 8 decimals)
For rova-movement-contracts
- The only supported payment currency is the native MOVE token on Movement
Q: Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
For rova-contracts
- Admin, manager, signer, and operator roles are trusted
- Withdrawal role can update the role used for withdrawals and trigger withdrawal function
For rova-movement-contracts
- Admin, manager, and signer role are trusted
- Withdrawal role can update the role used for withdrawals
Q: Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
No
No
Q: Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.
Yes, all user interactions require a signature that is generated by Rova backend signers. These signers have the signer role. This allows us to perform offchain validation on users (e.g. KYC) and ensure only allowed requests go through.
To participate in a token sale launch, users are expected to go through Rova frontend, which facilitates retrieving the signature for the transaction. The flow would look like:
- User selects payment currency and token amount in Rova frontend, which sends a request to Rova backend to validate the participation request and generate the signature.
- Backend verifies that the user is allowed to initiate the request and performs preliminary validation on request parameters
- Backend generates signature for user if validation passes
- User submits transaction including the signature, which is then verified in the contract to make sure the signature is valid and generated by a member of the signer role.
A similar flow happens for participation updates and cancellations. These type of actions are only allowed in launch group structures like raffles where the participation is not considered finalized until the selection process happens.
For rova-contracts
- This contract supports launch group sale structures that finalize at participation (FCFS) and those that require manual processing to select winning participations to finalize (raffles). All requests by end users (participate, update/cancel participations, claim refund) require a valid signature.
For rova-movement-contracts
- This contract only supports first come first serve (FCFS) participation. The backend is expected to provide the correct MOVE payment amount based on token price in MOVE and token purchase amount.
Backend checks before generating the signatures for user participation requests:
- Verify user authentication using access token in request headers
- Validate user is not blocked previously on Rova and IP geoblocks
- Ensure user has completed KYC
- Make sure user address is not sanctioned (Chainalysis API)
- Project based eligibility check if any (this will be determined by the token sale project)
- Make sure user has no other pending transactions or reached their allocation limits. This is for better error UX, since the contract expected to have validation to prevent users from crossing their max token allocation as well.
For the purposes of this audit we can assume signer role is trusted. However, the Launch contract handles payment calculation/transfers, manages token allocation per user and allocation limits, and processes refunds and withdrawals so we want to make sure there are no issues or concerns in the logic there. We will use the Launch contract as the source of truth for whether or not a user has successfully participated and funded a token sale, and how much tokens are allocated to them for distribution once vesting starts.
For a given payment currency, The total amount of payment currency tokens that can be withdrawn should equal the total amount of payment currency tokens funded for finalized token sale participations. The rest of the payment currency tokens for “unfinalized” participations should be available for user refund.
rova-contracts
- Handling refunds - Users can intentionally claim refunds on their own for launch groups that have been completed. We also allow anyone with the operator role to trigger batch refunds for unfinalized participations. This is so we can make sure to process all refunds on behalf of users, but allow users the option to get their refund earlier than our automated refund system.
- Batch actions - Finalizing winning participations and handling refunds for a set of participations can be done in batch to reduce the number of automated transactions our backend system needs to process. It can be assumed that the batch count submitted will not go over the block gas limit.
- Launch group setting updates are intended to be handled manually to coordinate with relevant teams involved in the launch and backend processes.
rova-movement-contracts
- These were designed to be a much simpler, scaled-down version of rova-contracts for the following reasons:
- We do not plan to handle alternative coin payment methods other than native MOVE on Movement.
- Only FCFS launch structure is supported. Once a user funds the sale contract, their participation in the sale is considered finalized. We do not need to support sale commitment updates, cancellations, or refunds.
- We do not plan to support multiple launch groups. All users participating will fall under one bucket with the same start/end time and token price.
N/A
https://github.com/dpm-labs/rova-contracts/blob/main/README.md
https://github.com/dpm-labs/rova-movement-contracts/blob/main/README.md
rova-contracts @ b6e0f7228a068dbdfceeca0fb4b8839e3566abb5
rova-movement-contracts @ ac6231be4db9b9372c3614d2677b069418285896