You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## What?
Improve the auction system to achieve the following goals:
- No limit on the amount of bids per project or per user
- Early releases of failed bids so they can bid again
- Make extrinsics as light-weight as possible
- Avoid limiting min and max tickets
## Why?
- We removed the other funding rounds and were left with only auction.
- We also were using a bucket system when the initial system was designed for a free pricing auction
- It was time to go back to the drawing board and see if we could optimize things
## How?
### Mark I
We achieved infinite bids, but had to bound ticket sizes so the total amount of winning bids was known. We would process only the winning bids in the funding end transition and store the cutoff. Any bids after the cutoff were assumed rejected.
Main problem was that you couldn't release your bid early to bid again if it was rejected.
### Mark II
Infinite bids, and less strict bounded ticket sizes. Instead of processing the winning bids at the end of a project, each bidder would need to process the bids they would kick out at the moment of bidding. Any bids not processed were assumed accepted.
Here we now allowed releasing your bid early since the processing was done after each bid and not at the end. But still the ticket sizes were too strict (min 100USD max 100k USD) because we had to limit the total number of bids one had to process when oversubscribed.
### Mark III
Here we solved both the ticket sizes (min 10, max unlimited), and the releasing bid early.
Bid extrinsics were now very light weight as well.
We now processed bids that were outbid in a separate extrinsic which has to run during the auction round. This is called either by a user, or by the on-idle hook.
Every new bid made from the second bucket onwards was considered to be outbidding an existing bid, so we stored that amount in storage, and then a new extrinsic would look at this storage and if theres any tokens outbid, start reading the bids in order of rejection.
To know the order, we have a new map storing the bucket price to starting and ending bid id.
The processing goes from lowest to highest bucket price, and inside the bucket from highest bid index to lowest.
## Testing?
Several tests written and benchmarks modified.
0 commit comments