-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ Auction Round Improvements #447
Open
JuaniRios
wants to merge
1
commit into
01-27-refactor_cleanup_credentials_serialization
Choose a base branch
from
02-05-auction_round_improvements
base: 01-27-refactor_cleanup_credentials_serialization
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
✨ Auction Round Improvements #447
JuaniRios
wants to merge
1
commit into
01-27-refactor_cleanup_credentials_serialization
from
02-05-auction_round_improvements
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Feb 5, 2025
Closed
Closed
Closed
Closed
Closed
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
7414bf9
to
3d334e6
Compare
3d334e6
to
b16a2f1
Compare
b16a2f1
to
ede7645
Compare
f61a62d
to
95583d0
Compare
ede7645
to
9686d17
Compare
95583d0
to
e3c2999
Compare
e3c2999
to
e46808c
Compare
9686d17
to
21220b2
Compare
e46808c
to
ecc1d3d
Compare
21220b2
to
d5880dd
Compare
d5880dd
to
ec99d8a
Compare
ecc1d3d
to
2139407
Compare
This was referenced Feb 12, 2025
Closed
ec99d8a
to
e499ad2
Compare
18720a2
to
b44dd90
Compare
This was referenced Feb 17, 2025
Closed
2139407
to
ecc1d3d
Compare
b44dd90
to
3d5992e
Compare
lrazovic
approved these changes
Mar 3, 2025
This was referenced Mar 3, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Improve the auction system to achieve the following goals:
Why?
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.