feat(auction): add an auctioneer to manage vault liquidation #7000

Chris-Hibbert · 2023-02-15T01:02:23Z

Description

Separate pieces include a scheduler that manages the phases of an auction, the AuctionBook that holds onto offers to buy, and the auctioneer, which accepts good for sale and has the APIs. Params are managed via governance. The classes are not durable.

The changes to VaultFactory to make use of this approach to liquidation rather than the AMM are in a separate PR, which will be available before this PR is finalized.

Security Considerations

Mainly economic. This will be a core part of our economy.

Scaling Considerations

As the vault economy grows, this will be a major point of contention. Traders will be very interested in getting trades executed quickly. The design is intended to allow traders to place the orders they want without requiring lots of interactive adjustments.

Documentation Considerations

The user focus will be mostly on the UI.

Testing Considerations

Decent tests of scheduler, book, and auction. I expect intensive manual testing once it's in a visible place.

turadg

Partial pass. Back soon.

packages/governance/src/constants.js

packages/governance/src/contractGovernance/assertions.js

packages/governance/src/contractGovernance/typedParamManager.js

packages/governance/src/contractHelper.js

packages/inter-protocol/src/auction/params.js

packages/inter-protocol/src/auction/sortedOffers.js

turadg

Another pass. Not a totally thorough review but it's draft. I'll look again when re-requested.

Quite an achievement already!

turadg · 2023-02-15T17:43:04Z

packages/inter-protocol/src/auction/sortedOffers.js

+  // until DB supports composite keys, copy its method for turning numbers to DB
+  // entry keys


good comment. @warner is there an issue for DB supporting composite keys?

I should have searched: #5263

Please include the issue in the comment

After a refactoring of sortedOffer keys suggested by MarkM, I'm getting composite keys by using encodeData on an array of the key components.

packages/inter-protocol/src/auction/sortedOffers.js

turadg · 2023-02-15T17:46:27Z

packages/inter-protocol/src/auction/sortedOffers.js

+  );
+};
+
+const discountRatioFromFloat = (


I don't understand why there are parallel functions for price/discount that do the same thing.

They're conceptually different types. Prices are currency/collateral, while discounts are currency/currency. I've dropped denomBrand from discounts, and made the assertions more precise.

packages/inter-protocol/src/auction/auctioneer.js

turadg · 2023-02-15T19:00:40Z

packages/inter-protocol/src/auction/discountBook.js

+// prices in this book are expressed as percentage of full price. .4 is 60% off.
+// 1.1 is 10% above par.


This comment is helpful. I think it suggests choosing a different word than "Discount" for this functionality. It also sounds like "more discount" is "smaller price" but it's the other way around.

brainstorming,

Coefficient

Coeff

Proportion

Prop

Premium

Multiplier

QuoteFactor

None seem obviously better on balance than Discount.

Your point about the directionality is persuasive. priceScalingFactor is the most explicit description I've come up with. coeff is okay, but I prefer factor. opinions about 'scaling' vs. 'scale'?

Multiplier seems less on-point than factor.

proportion has the same drawback as discount in sounding like it's restricted to less than one.

premium has the opposite problem, like markup.

quoteFactor has a subtle appeal. It says that it's markup or markdown that will be applied to the quote, but doesn't say that it's part of a bid.

How about bidScaleFactor or bidScaling?

"bid" definitely clarifies. Slight preference for Scaling over ScaleFactor. ScaleFactor is a bit of Hungarian notation and is longer without adding clarity. So 👍 to bidScaling.

done. Fairly pervasively. I didn't change parameter names, which are visible to EC governance, etc. I think they'll be happier with 'discount', and if not, PM can say what term to use instead.

packages/inter-protocol/src/auction/discountBook.js

packages/inter-protocol/src/auction/params.js

erights · 2023-02-26T05:42:55Z

@Chris-Hibbert @turadg in reading the conversations you two have above, to help my review process, I'll Resolve those conversations that seem resolved, to help focus attention on the remainder. These aren't my conversations, so please let me know if this interferes with the way you two are coordinating, and unresolve as needed. Thanks.

erights · 2023-02-24T07:18:06Z

packages/inter-protocol/src/auction/sortedOffers.js

+// This will work just fine for at least 250 years. And notice that these
+// timestamps are used for sorting during an auction and don't need to be stored
+// long-term. We could safely subtract from a timestamp that's now + 1 month.
+const FarFuture = 10000000000000n;


Suggested change

const FarFuture = 10000000000000n;

const FarFuture = 10_000_000_000_000n;

Switched to sequence numbers so this was no longer needed. Then you made me realize that sorting in the store never needs to care about times, so it's gone.

erights · 2023-02-26T02:50:58Z

packages/inter-protocol/src/auction/auctioneer.js

+/**
+ * @param {ZCF<GovernanceTerms<{
+ *   StartFrequency: 'relativeTime',
+ *   ClockStep: 'relativeTime',
+ *   StartingRate: 'nat',
+ *   lowestRate: 'nat',
+ *   DiscountStep: 'nat',
+ * }> & {timerService: import('@agoric/time/src/types').TimerService, priceAuthority: PriceAuthority}>} zcf
+ * @param {{initialPoserInvitation: Invitation, storageNode: StorageNode, marshaller: Marshaller}} privateArgs
+ * @param {Baggage} baggage
+ */


In order to review this, I found myself reformatting it to

Suggested change

/**

* @param {ZCF<GovernanceTerms<{

* StartFrequency: 'relativeTime',

* ClockStep: 'relativeTime',

* StartingRate: 'nat',

* lowestRate: 'nat',

* DiscountStep: 'nat',

* }> & {timerService: import('@agoric/time/src/types').TimerService, priceAuthority: PriceAuthority}>} zcf

* @param {{initialPoserInvitation: Invitation, storageNode: StorageNode, marshaller: Marshaller}} privateArgs

* @param {Baggage} baggage

*/

/**

* @param {ZCF<GovernanceTerms<{

* StartFrequency: 'relativeTime',

* ClockStep: 'relativeTime',

* StartingRate: 'nat',

* lowestRate: 'nat',

* DiscountStep: 'nat',

* }> & {

* timerService: import('@agoric/time/src/types').TimerService,

* priceAuthority: PriceAuthority

* }>} zcf

* @param {{

* initialPoserInvitation: Invitation,

* storageNode: StorageNode,

* marshaller: Marshaller

* }} privateArgs

* @param {Baggage} baggage

*/

The params to GovernedTerms seems annoyingly redundant with auctioneerParamTypes. Can we reduce the redundancy? If not, or in the meantime, are they checked against each other for consistency?

Aside from auctioneerParamTypes, the privateArgs are exactly what is needed for handleParamGovernance. Is this expected to be a typical pattern? Any way to make this more convenient?

I agree on the redundancy. I don't think they're checked directly against each other, but I think typescript knows that the params returned from handleParamGovernance (line 157) match this declaration, and compare that to the requirements of makeScheduler, which declares params to be AuctionParamManaager which was declared in params.js.

privateArgs are exactly what is needed for handleParamGovernance. Is this expected to be a typical pattern?
yes.

@turadg understands these interconnections much better than I do. Would you respond?

Any way to make this more convenient?

There's a bunch of refactoring we could do to governance. I'd like to make it require less repetition. Not a priority tho.

For this particular case we could have a type like ParamGovernancePrivateArgs and union that here. But the args marshaller and storageNode probably will leave handleParamGovernance once we stop using the deprecated StoredPublishKit for governance. I expect that to happen when we make governance durable.

erights · 2023-02-26T05:15:32Z

packages/inter-protocol/src/auction/auctioneer.js

+  const brandToKeyword = provide(baggage, 'brandToKeyword', () =>
+    makeScalarBigMapStore('deposits', {
+      durable: true,
+    }),
+  );


AFAICT, the only difference between this and

Suggested change

const brandToKeyword = provide(baggage, 'brandToKeyword', () =>

makeScalarBigMapStore('deposits', {

durable: true,

}),

);

const brandToKeyword = provideDurableMapStore(baggage, 'brandToKeyword');

is the use of two different literal strings, so that the errors associated with this mapStore are labeled deposits instead of brandToKeyword. Is that the motivation? If so, ok.

No. I should convert to provideDurableMapStore(). AIR, Turadg suggested it here, but I missed one of the MapStores.

packages/governance/src/constants.js

erights · 2023-02-26T05:55:55Z

packages/zoe/src/contractSupport/ratio.js

+ * @param {Ratio} ratio
+ * @returns {number}
+ */
+export const coerceToNumber = ratio => {


While there may not be a widely accepted definition of coercion in programming languages, I use the term only for conversion functions that are idempotent in the following sense:

coerceToX(y) is equivalent to coerceToX(coerceToX(y))

IOW, whatever the target form this is coercing to, if the input is already of that form, then it does not need to be coerced and is passed through unmodified.

I saw @turadg 's other suggestion ratioAsFloat. This seems more right, as this is just converting from one representation to another. In JS, "number" means "double precision floating point", so I'd be equally happy with ratioAsNumber or ratioToNumber.

ratioAsNumber makes it sound like they're equivalent representations, but you can't convert back to the same ratio, so I'm going with ratioToNumber.

erights · 2023-02-26T06:19:58Z

packages/inter-protocol/src/auction/auctionBook.js

+    },
+    {
+      want: AmountShape,
+      offerDiscount: makeRatioPattern(currencyBrand, currencyBrand),


as you point out above this can be markup.

I first read that as "markup" as in HTML, and was momentarily confused ;)

I can't think of one word for both either. But it seems like a concept that must have a word. Weird.

erights · 2023-02-26T06:32:55Z

packages/inter-protocol/src/auction/auctionBook.js

+      );
+
+      trace(`settling`, pricedOffers.length, discOffers.length);
+      prioritizedOffers.forEach(([key, { seat, price: p, wanted }]) => {


I also prefer syntactic for loops over forEach specifically. (For the other higher order array methods, I have no general preference, but evaluate case by case.)

Two reasons I prefer syntax:

usually easier to step through iterations in a debugger, depending on the debugger

easy to exit early, which often arises after the code is initially written

erights · 2023-02-26T06:39:07Z

packages/inter-protocol/src/auction/auctioneer.js

+    if (deposits.has(amount.brand)) {
+      const depositListForBrand = deposits.get(amount.brand);
+      deposits.set(
+        amount.brand,
+        harden([...depositListForBrand, { seat, amount }]),
+      );
+    } else {
+      deposits.init(amount.brand, harden([{ seat, amount }]));
+    }


@turadg , I see it didn't make it into #6961 , but it does still seem like a useful helper.

erights · 2023-02-26T06:41:32Z

packages/inter-protocol/src/auction/auctioneer.js

+  };
+
+  const driver = Far('Auctioneer', {
+    descendingStep: () => {


Became reducePriceAndTrade?

packages/inter-protocol/src/auction/discountBook.js

erights · 2023-02-27T05:55:34Z

Please try to wakeup CI so we can see what it has to say.

erights · 2023-02-27T05:56:39Z

If CI is reasonably happy, should this be Ready for review?

erights · 2023-02-27T07:22:20Z

packages/inter-protocol/src/auction/auctionBook.js

+  const makeZeroRatio = () =>
+    makeRatioFromAmounts(
+      AmountMath.makeEmpty(currencyBrand),
+      AmountMath.make(collateralBrand, 1n),
+    );


Suggested change

const makeZeroRatio = () =>

makeRatioFromAmounts(

AmountMath.makeEmpty(currencyBrand),

AmountMath.make(collateralBrand, 1n),

);

const zeroRatio =

makeRatioFromAmounts(

AmountMath.makeEmpty(currencyBrand),

AmountMath.make(collateralBrand, 1n),

);

and then replace every makeZeroRatio() with zeroRatio.

I noticed that somewhere else and removed it, but I apparently missed it here. I don't know what evolution the code must have gone through for that to have happened, but it sure looks dumb now.

erights · 2023-02-27T07:33:02Z

packages/inter-protocol/src/auction/auctioneer.js

+
+        const collShare = makeRatioFromAmounts(collatRaise, totCollDeposited);
+        const currShare = makeRatioFromAmounts(currencyRaise, totCollDeposited);
+        /** @type {import('@agoric/zoe/src/contractSupport/atomicTransfer.js').TransferPart[]} */


Ugh, should not need a deep import just to use normal helper APIs. This is on me. Any idea how to export the type so it can be imported simply?

In any case, very cool use of a temporarily mutable array to gather all the parts of a rearrange!

Imo deep imports aren't so bad with types since they don't affect runtime import graph.

For the particular case, it'll be solved by putting the atomicTransfer capability on Zoe proper (instead of this contractSupport helper). Since that's already scheduled I don't think it's worth trying to address this case that will be obviated.

erights · 2023-02-27T07:43:07Z

packages/inter-protocol/src/auction/params.js

+export const RelativeTimeRecordShape = harden({
+  timerBrand: TimerBrandShape,
+  relValue: RelativeTimeValueShape,
+});


Suggested change

export const RelativeTimeRecordShape = harden({

timerBrand: TimerBrandShape,

relValue: RelativeTimeValueShape,

});

Anyone who needs this should import it from @agoric/time

agreed. done.

erights · 2023-02-27T07:45:42Z

packages/inter-protocol/src/auction/scheduler.js

+const trace = makeTracer('SCHED', false);
+
+/**
+ * @file The scheduler is presumed to be quiescent between auction rounds. Each


"presumed" huh?

How confident are we that this presumption cannot be violated?

If it is violated, what happens? How bad is it?

I mostly wrote that to simplify my mental model for testing. The manual clock complicates things, since in tests, it doesn't seem to reliably hit all intermediate times. (I think this is related to the fact that eventLoopIteration() is required.)

If the clock steps through every time, and turns have time to finish, then the states change correctly and the auction will be quiescent. I'm pretty confident that I've checked the incoming parameters so that successive auctions cannot overlap, which is the main thing that would violate this rule.
If auction periods overlap, the auctioneer will be confused about what's being sold at which price.

Chris-Hibbert · 2023-02-27T23:59:27Z

@erights requested some cleanup of the sorted offers in discussion. I don't think I'm making any use of the multipart key, and should simplify to just the first part. If I do that, then the other part of the discussion about not needing to encode the time part becomes moot.

turadg

Not done but after the 4th signal to Refresh the review I figure I should post these before they're stale! ;-)

turadg · 2023-02-28T23:08:31Z

packages/governance/src/contractGovernance/paramManager.js

@@ -184,6 +188,18 @@ const makeParamManagerBuilder = (publisherKit, zoe) => {
    return builder;
  };

+  /** @type {(name: string, value: import('@agoric/time/src/types').Timestamp, builder: ParamManagerBuilder) => ParamManagerBuilder} */
+  const addTimestamp = (name, value, builder) => {
+    buildCopyParam(name, value, assertTimestamp, ParamTypes.TIMESTAMP);


out of scope: consider making buildCopyParam take a shape in the assert/coerce parameter. If it's a function, then it's a coercer and if it's not then it's a shape to match.

Good idea. #7118

turadg · 2023-02-28T23:12:46Z

packages/inter-protocol/src/auction/auctionBook.js

+ * The book contains orders for the collateral. It holds two kinds of
+ * orders:
+ *   - Prices express the bid in terms of a Currency amount
+ *   - Scaled bid  express the bid in terms of a discount (or markup) from the


Suggested change

* - Scaled bid express the bid in terms of a discount (or markup) from the

* - Scaled bids express the bid in terms of a discount (or markup) from the

turadg · 2023-02-28T23:15:44Z

packages/inter-protocol/src/auction/auctionBook.js

+ * Offers can be added in three ways. When the auction is not active, prices are
+ * automatically added to the appropriate collection. If a new offer is at or
+ * above the current price of an active auction, it will be settled immediately.
+ * If the offer is below the current price, it will be added, and settled when
+ * the price reaches that level.


Suggested change

* Offers can be added in three ways. When the auction is not active, prices are

* automatically added to the appropriate collection. If a new offer is at or

* above the current price of an active auction, it will be settled immediately.

* If the offer is below the current price, it will be added, and settled when

* the price reaches that level.

* Offers can be added in three ways. 1) When the auction is not active, prices are

* automatically added to the appropriate collection. When the auction is active:

* 2) If a new offer is at or above the current price, it will be settled immediately;

* 3) If the offer is below the current price, it will be added, and settled when

* the price reaches that level.

yes, that's clearer.

turadg · 2023-02-28T23:20:04Z

packages/inter-protocol/src/auction/auctionBook.js

+  );
+  const BidSpecShape = M.or(
+    {
+      want: AmountShape,


good time to use E(brand).getAmountShape()

and I think makeBrandedRatioPattern should use the same shapes for its amounts.

though looking at makeBrandedRatioPattern I see we can match on the exact brand by just using the brand object. I suppose Brand has getAmountShape() because you might not know the kind from the brand, but if you already do, why spend a remote call to get that shape? shouldn't we have a makeNatAmountshape(brand) function? That would make the TODOs in #7041 pretty trivial.

done. (at least some interpretation of what you said.) I wanted the patterns to enforce the brands but hadn't noticed brand.getAmountShape().

packages/inter-protocol/src/auction/auctionBook.js

turadg · 2023-03-01T00:08:42Z

packages/inter-protocol/src/auction/auctioneer.js

+
+  // @ts-expect-error types are correct. How to convince TS?
+  const scheduler = await makeScheduler(driver, timer, params, timerBrand);
+  const depositOfferHandler = zcfSeat => {


consider inlining.

I don't think that makes it easier to read.

packages/inter-protocol/src/auction/auctioneer.js

packages/inter-protocol/src/auction/offerBook.js

turadg · 2023-03-01T00:14:31Z

packages/inter-protocol/src/auction/params.js

+/** in seconds, how often to reduce the price */
+export const CLOCK_STEP = 'ClockStep';
+/** discount or markup for starting price in basis points. 9999 = 1bp discount */
+export const STARTING_RATE = 'StartingRate';


this comment won't appear when setting this params in UIs. WDYT of appending 'BP' for all the basis points values?

alternately, express as a ratio? if it's too cumbersome to include the brands I think we should consider a RATIONAL param type because the work-around of a Nat is worse

The UI ought to want to provide help text to the user, right? If I were writing that help text, I'd look here. Is there a better place?

appending 'BP' is good.

The brands are a hassle when setting governed params, AFAICT.

When governance is trying to setup a vote, ISTM that creating a ratio would be an issue. Can you think of a way for that UI/CLI to make that palatable?

turadg · 2023-03-01T00:17:01Z

packages/inter-protocol/src/auction/params.js

+ * @param {RelativeTime} initial.priceLockPeriod
+ * @param {import('@agoric/time/src/types').TimerBrand} initial.timerBrand
+ */
+export const makeAuctioneerParamManager = (publisherKit, zoe, initial) => {


hoping to find time eventually to DRY out governance params. there's lots of repetition to define a parameter.

turadg · 2023-03-01T00:26:28Z

packages/inter-protocol/src/proposals/econ-behaviors.js

@@ -81,6 +84,12 @@ const MILLI = 1_000_000n;
 *     governorCreatorFacet: GovernedContractFacetAccess<VaultFactoryPublicFacet, VaultFactoryCreatorFacet>,
 *     adminFacet: AdminFacet,
 *   },
+ *   auctionKit: {


most of those are ${contractName}Kit.

Suggested change

* auctionKit: {

* auctioneerKit: {

turadg · 2023-03-01T00:27:40Z

packages/inter-protocol/src/auction/util.js

+ * TRUE if the discount(/markup) applied to the price is higher than the quote.
+ *
+ * @param {Ratio} bidScaling
+ * @param {Ratio} currentPrice
+ * @param {Ratio} oraclePrice


Suggested change

* TRUE if the discount(/markup) applied to the price is higher than the quote.

*

* @param {Ratio} bidScaling

* @param {Ratio} currentPrice

* @param {Ratio} oraclePrice

* @param {Ratio} bidScaling

* @param {Ratio} currentPrice

* @param {Ratio} oraclePrice

* @returns {boolean} TRUE iff the discount(/markup) applied to the price is higher than the quote.

turadg · 2023-03-01T00:29:03Z

packages/inter-protocol/src/auction/scheduler.js

+  /** @type {'active' | 'waiting'} */
+  let auctionState = AuctionState.WAITING;
+
+  const computeRoundTiming = baseTime => {


wdt of extracting this to unit test with arbitrary params?

good idea; done.

It will be introduced with #7047 when vaultfactory makes use of the auction for liquidation

It'll be removed in #7074, I think, but for now it like a change in this PR.

Add a test for this case. make all auctionContract tests serial

for loops rather than foreach better type extraneous line

…7000)

Chris-Hibbert added enhancement New feature or request Zoe Contract Contracts within Zoe Vaults VaultFactor (née Treasury) MUST-HAVE labels Feb 15, 2023

Chris-Hibbert added this to the Vaults Functional Testing milestone Feb 15, 2023

Chris-Hibbert self-assigned this Feb 15, 2023

Chris-Hibbert marked this pull request as draft February 15, 2023 01:02

Chris-Hibbert requested review from turadg and erights February 15, 2023 01:02

turadg reviewed Feb 15, 2023

View reviewed changes

This was referenced Feb 22, 2023

Auction starts based on current oracle price; not locked price #6948

Closed

Auction starts after the hour to give liquidator time to liquidate all vaults #6949

Closed

Vaults subscribe to price updates continuously #6946

Closed

ivanlei requested a review from dtribble February 22, 2023 20:49

This was referenced Feb 23, 2023

remove the AMM #7055

Closed

feat(AMM)!: remove the AMM and cleanup bootstrap etc. dependencies #7074

Merged

erights reviewed Feb 26, 2023

View reviewed changes

erights self-requested a review February 26, 2023 06:45

erights reviewed Feb 27, 2023

View reviewed changes

erights self-requested a review February 27, 2023 20:08

Chris-Hibbert mentioned this pull request Feb 27, 2023

allow auction Bids to specify "exit on partial satisfaction" #7088

Closed

Chris-Hibbert marked this pull request as ready for review February 28, 2023 00:21

Chris-Hibbert force-pushed the 6992-auctioneer branch from 4eef984 to 2b4e795 Compare February 28, 2023 20:50

turadg reviewed Mar 1, 2023

View reviewed changes

Chris-Hibbert added 19 commits March 5, 2023 15:15

refactor: cleanups from working on vault liquidation

3d96042

chore: cleanups suggested in review

64ee0bd

refactor: simplify keys in sortOffers

5a96e6f

chore: cosmetic cleanups from review

e5ff84d

chore: auction was introduced to vaultfactory too early.

fcb3056

It will be introduced with #7047 when vaultfactory makes use of the auction for liquidation

chore: correctly revert removal of param declaration

4d07a53

It'll be removed in #7074, I think, but for now it like a change in this PR.

test: repair dependencies for startAuction

c193026

chore: responses to reviews

8bed4d5

test: refactor proportional distribution test to use macros

d94b6e6

refactor: correct sorting of orders by time

2141de9

Add a test for this case. make all auctionContract tests serial

chore: cleanups suggested in review

bf5e721

for loops rather than foreach better type extraneous line

chore: clean up scheduler; add test for computeRoundTiming

7150b7e

chore: minor cleanups from review

e137415

chore: rename auctionKit to auctioneerKit

ea0d0c4

chore: drop auction from startPSM

7ee7210

chore: clean-ups from review

8d641af

refactor: computeRoundTiming should not allow duration === frequency

42dd965

chore: clean up governance, add invitation patterns in auctioneer

feda838

refactor: don't reschedule next if price is already locked

bfaa587

Chris-Hibbert force-pushed the 6992-auctioneer branch from c29f2c2 to bfaa587 Compare March 5, 2023 23:16

Chris-Hibbert added the automerge:squash Automatically squash merge label Mar 5, 2023

Merge branch 'master' into 6992-auctioneer

5a66425

mergify bot merged commit 398b70f into master Mar 6, 2023

mergify bot deleted the 6992-auctioneer branch March 6, 2023 01:24

warner mentioned this pull request Mar 6, 2023

vat-timer thinks time=0 during bootstrap block #7124

Closed

mhofman mentioned this pull request Mar 6, 2023

Failed GH Action reports as skipped, bypassing merge checks #7126

Closed

turadg mentioned this pull request Mar 8, 2023

misc refactorings #7131

Merged

turadg added a commit that referenced this pull request Mar 15, 2023

fixup! feat(auction): add an auctioneer to manage vault liquidation (#…

8b31141

…7000)

Chris-Hibbert mentioned this pull request Mar 21, 2023

Add delay before price update triggers Liquidation #5843

Closed

Chris-Hibbert mentioned this pull request Mar 30, 2023

Liquidation proceeds are handled by Vault Manager #7123

Closed

		// until DB supports composite keys, copy its method for turning numbers to DB
		// entry keys

		// prices in this book are expressed as percentage of full price. .4 is 60% off.
		// 1.1 is 10% above par.

	const FarFuture = 10000000000000n;
	const FarFuture = 10_000_000_000_000n;

	* - Scaled bid express the bid in terms of a discount (or markup) from the
	* - Scaled bids express the bid in terms of a discount (or markup) from the

feat(auction): add an auctioneer to manage vault liquidation #7000

feat(auction): add an auctioneer to manage vault liquidation #7000

Conversation

Chris-Hibbert commented Feb 15, 2023 • edited Loading

Description

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

turadg left a comment

Choose a reason for hiding this comment

turadg left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erights commented Feb 26, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erights Feb 26, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erights commented Feb 27, 2023

erights commented Feb 27, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Chris-Hibbert commented Feb 27, 2023

turadg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Chris-Hibbert commented Feb 15, 2023 •

edited

Loading

turadg left a comment •

edited

Loading

erights Feb 26, 2023 •

edited

Loading