An auction should have an is_mutable flag that can only be set on creation. If this isn't set, the auction is immutable, which provides stability and certainty to those auctions because the people bidding in them know that auction cannot change, be deleted, or what have you. It's a different mindset, that we'd like to preserve as a toggle. I suspect it won't be used often after we introduce this feature though.
If it is set, then the auctioneer can:
Change ended_at
Change gap_time
Change the tick size
Change the price floor (but not invalidate current bids that got on before the price floor)
And finally:
Hide the auction by moving it to a new deleted state. This only is workable if last_bid is empty. This is for "accidental" auctions.
The UI will need to be modified to only show deleted auctions to people who created them (fairly easy filter to add) and to people who have bid in them so they can refund bids, and the is_winner logic will need updates to consider an auction in this state as having zero winners, which is an interface leak since bid_state doesn't know about it, but it's parent container object (auction) does. This is fine since bid_state isn;'t directly called but the parent wrapper method is, so the logic can be there.
This may also cause issues due to the issue we have with borsh + adding new fields to AuctionData, so a lot of these new fields will need to go on AuctionDataExtended. Be aware.
An auction should have an is_mutable flag that can only be set on creation. If this isn't set, the auction is immutable, which provides stability and certainty to those auctions because the people bidding in them know that auction cannot change, be deleted, or what have you. It's a different mindset, that we'd like to preserve as a toggle. I suspect it won't be used often after we introduce this feature though.
If it is set, then the auctioneer can:
And finally:
The UI will need to be modified to only show deleted auctions to people who created them (fairly easy filter to add) and to people who have bid in them so they can refund bids, and the is_winner logic will need updates to consider an auction in this state as having zero winners, which is an interface leak since bid_state doesn't know about it, but it's parent container object (auction) does. This is fine since bid_state isn;'t directly called but the parent wrapper method is, so the logic can be there.
This may also cause issues due to the issue we have with borsh + adding new fields to AuctionData, so a lot of these new fields will need to go on AuctionDataExtended. Be aware.