Prize Pools are pools of funds whose yield is awarded as a prize to one or more winners.
The flow goes like so:
- Users deposit tokens and receive wrapped tokens as “tickets” in returrn. tickets are redeemable 1:1 with the deposited token
- Time passes
- The prize pool selects a winner, who is transferred more tickets as a prize.
- At any time a user can burn their tickets in exchange for the underlying token.
Behind the scenes, Prize Pools utilize a Yield Source contract to generate yield. The Yield Source contract may be a singleton, or an instance can be created per-pool.
The yield source serves as an adapter to protocols such as Aave, Compound, etc. In this case the adapter is for xSushi as a yield source.
We’d like the Sushi Yield Source code to be reviewed. This review is intended to be part functional, part security. In particular, we’re looking to assert that:
- The math is correct, and that there are no dangerous edge cases
- The yield source isn’t exploitable
- The yield source adheres to the expected behaviour by the prize pool
- The yield source’s interactions with the SushiBar are in accordance with the SushiBar’s actual behaviour.
The deadline for this review is May 10, but the earlier the better.
This review will require knowledge of:
- PoolTogether Prize Pools
- SushiSwap’s SushiBar
- Fixed point math in Solidity
- Security concerns such as re-entrancy
PoolTogether and Sushi are co-sponsoring this review for a total of $5000 USD in stablecoins.
To encourage participation, we’re going to follow the Code 423n4 approach to rewards so that anyone that finds exploits will be rewarded.
Keep the deliverables confidential until the time has elapsed! At that point we’ll publish all of the reports.