✨ Auction Round Improvements

[JuaniRios]

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.

[JuaniRios]

• 🧹 General Cleanup #450 : 2 dependent PRs (#452 , #454 )
• 🚮 Remove WAP #449
• ✨ Auction Round Improvements #447 👈 (View in Graphite)
• 🧹 Cleanup Credentials Serialization #440
• 🔥 Funding Rounds Simplification #436 : 2 other dependent PRs (#441 , #445 )
• ✅ WETH integration test #432
• bugfixes #438
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[lrazovic]

Merge activity

• Mar 5, 4:29 AM EST: A user started a stack merge that includes this pull request via Graphite.
• Mar 5, 4:30 AM EST: Graphite couldn't merge this pull request because a downstack PR 🔥 Funding Rounds Simplification #436 failed to merge.
• Mar 5, 4:34 AM EST: A user started a stack merge that includes this pull request via Graphite.
• Mar 5, 4:40 AM EST: Graphite rebased this pull request as part of a merge.
• Mar 5, 4:41 AM EST: A user merged this pull request with Graphite.