Lottery Mechanism

Implemented in the FeeHandler contract

To redistribute a portion of fees back to users, the protocol implements a lottery mechanism to periodically select a winner.

It works as such:

1. Fees slowly accumulate in the lottery pot.

2. When the size of the lottery pot is at least 4.2 ETH, it is large enough to be paid out.

3. Whenever a token is created, traded or launched, there is a 1% chance that the lottery pot is paid out. Otherwise, it continues to accumulate ETH and grows in size.

4. When (3) occurs, the current lottery pot is locked and jackpotId is incremented. Subsequent fees accumulate to a new lottery pot.

5. Users call commitCrowdEntropy() to commit entropy for locked lotteries.

6. The protocol admin calls awardJackpot() and provides another source of entropy. Using crowd and admin entropy, a winner is selected and awarded the lottery pot.

7. If (6) does not occur for an extended period of time, users call forceAwardJackpot() to forcefully select a winner and pay out the lottery.

8. The winner calls collectETH() to collect their winnings.

Security Assumptions

Under the hood, the protocol uses block hashes to generate entropy for the lottery.

The Abstract sequencer is trusted to not manipulate block hashes to affect the outcome of the lottery.

The protocol uses a two-step entropy commitment process to prevent any single party from manipulating the outcome of the lottery:

1. Admin entropy - When the protocol is first launched, the protocol admin commits the hash of 32 bytes of entropy for each lottery. When awardJackpot() is called, the randomly generated 32 bytes are then revealed.

2. Crowd entropy - After the lottery is locked, regular users call commitCrowdEntropy(). This uses the hash of the 5th block after the lottery was locked. If the lottery was locked more than 256 blocks ago, crowd entropy is taken from the earliest blockhash available instead.

These two sources of entropy are then combined to select a random winner for the lottery. This prevents any single party from manipulating the selected winner as:

1. Regular users do not know the random 32 bytes of admin entropy.

2. The protocol admin cannot manipulate the blockhash used for crowd entropy if there are other transactions in the past 5 blocks. Users wishing to guarantee a fair random could submit a dummy transaction with above market gas price in these blocks. A sophisticated admin could in theory fill the crowd entropy blocks but such an attack cannot be economical, as honest users only need to contribute a single transaction with high enough gas to nullify the entire effort.

If regular users do not commit crowd entropy, crowd entropy will automatically be generated when awardJackpot() is called.

In the event where admin entropy is not committed before the lottery is locked, the random winner will be selected solely based on crowd entropy (ie. using forceAwardJackpot()). This ensures lotteries will still be paid out even without admin intervention.