Component M1: complete core implementation and enable discoverability
[x] auction: add new actions to action reference in protocol spec
[x] #4303
[x] EventDutchAuctionScheduled
[x] EventDutchAuctionUpdated
[x] EventDutchAuctionEnded
[x] #4356
[ ] #4268
[ ] #4304
[ ] auction: add high-level design of auction component to spec
pcli M1: to lay the groundwork for minifront M0
[x] #4302
Prax M0 (to be tracked in web repos - presented here for context)
[x] prax: pull in new protos
[x] prax: define react views for each auction actions:
[x] ActionDutchAuctionSchedule
[x] ActionDutchAuctionEnd
[x] ActionDutchAuctionWithdraw
[x] prax: update view server for auctions
[x] prax: add planner support
Implementation strategy notes:
The Component M0 and pcli M0 milestones should be done together, in keeping with our previous practice of using pcli as a testbed for new features. These should be done as soon as possible. Component functionality that doesn't affect the external action interfaces (e.g., value balance accounting, event emission, etc) can be deferred.
Note that pcli M1 is not in itself a valuable product feature; the only reason to do it is to be able to parallelize the work of automatic parameter selection for GDAs so that the Minifront M0 can adapt or copy it.
The proto package for the new component should be v1alpha1; this is still going to cause breaking proto changes because we'll add new Transaction fields that use the v1alpha1 types and then break them to point at the new package, but this shouldn't cause problems because other software won't use them and the entire project will be completed in a short time horizon.
This issue is tracking completion of Dutch Auction for Penumbra:
Design doc and context: https://hackmd.io/@hdevalence/B1RjyYJgR
Implementation plan: We break the implementation into the following milestones:
pcli
M0pcli
M1with the following dependency relations:
Tracking issue:
Component
Component M0: to build a protocol MVP for DAs
AuctionId
AuctionNft
DutchAuctionDescription
DutchAuctionState
DutchAuction
ActionDutchAuctionSchedule
ActionDutchAuctionEnd
ActionDutchAuctionWithdraw
ActionDutchAuctionWithdrawView
ActionDutchAuctionScheduleView
Transaction
because they will lack the equivalent trait implActionDutchAuctionSchedule
ActionDutchAuctionEnd
ActionDutchAuctionWithdraw
pcli
M0: to exercise and fill in the RPC implspcli tx auction dutch schedule
pcli tx auction dutch end
pcli tx auction dutch withdraw
pcli q auction id AUCTION_ID
pcli v auction list [--include-inactive]
Component M1: complete core implementation and enable discoverability
EventDutchAuctionScheduled
EventDutchAuctionUpdated
EventDutchAuctionEnded
pcli
M1: to lay the groundwork for minifront M0Prax M0 (to be tracked in web repos - presented here for context)
ActionDutchAuctionSchedule
ActionDutchAuctionEnd
ActionDutchAuctionWithdraw
Implementation strategy notes:
The Component M0 and
pcli
M0 milestones should be done together, in keeping with our previous practice of usingpcli
as a testbed for new features. These should be done as soon as possible. Component functionality that doesn't affect the external action interfaces (e.g., value balance accounting, event emission, etc) can be deferred.Note that
pcli
M1 is not in itself a valuable product feature; the only reason to do it is to be able to parallelize the work of automatic parameter selection for GDAs so that the Minifront M0 can adapt or copy it.The proto package for the new component should be
v1alpha1
; this is still going to cause breaking proto changes because we'll add newTransaction
fields that use thev1alpha1
types and then break them to point at the new package, but this shouldn't cause problems because other software won't use them and the entire project will be completed in a short time horizon.