Going to add all my notes when reading through EasyAuction here. Will continue to edit this.

The whitelist stuff is a bit confusing how it works - maybe ignore it for now.

It seems like they use this single contract for all auctions and differentiate between them though auctionId

Modifiers

They have four modifiers that define each stage of the auction.
atStageOrderPlacement This is any time before the end date of the auction.
atStageOrderPlacementAndCancelation the stage where orders can be placed and canceled
atStageSolutionSubmission this checks if an auction end date has been set, if it's past the auction date, and that the clearingPriceOrder has not been set. I assume this is modifier is protecting a function that calculates and sets the clearingPriceOrder
atStageFinished this is after the auction has finished (works by assuming clearingPriceOrder is set at conclusion of an auction)

I wonder why they specifically differentiate between atStageOrderPlacement and atStageOrderPlacementAndCancelation as they will have periods of overlap.

Events

They have 7 different events that get emitted by the EasyAuction. Need to figure out the significance of these. Is it possible to index them? Or are they always transient.
NewSellOrder
CancellationSellOrder
ClaimedFromOrder
NewUser
NewAuction
AuctionCleared
UserRegistration

Methods

setFeeParameters

The contract owner has the ability to set a new fee as long as it's less than 1.5% (artificial cap) and the ability to set the address who receives the fee. The fee is global across all auctions - no variance from auction to auction.

initiateAuction

auctioningToken and biddingToken ERC20 Tokens. AuctioningToken is what they are selling and biddingToken is what investors are bidding in and what is paid to the DAO.
orderCancellationEndDate, auctionEndDate - why isn't there an auction start date?
isAtomicClosureAllowed - what does this do?
accessManagerContract - is this just for accessControl?
minFundingThreshold - minimum amount of tokens needed denominated in biddingToken
minBuyAmount, minimumBiddingAmountPerOrder- minBuyAmount denominated in #of tokens_auctionedSellAmount` - amount of tokens to sell

This method sends the # of tokens to sell from the person calling the contract to the auction contract.
Then it does sanity checks
Then increments the auction number and creates a list that will contain each of the sell orders in the sellOrders mapping
Then adds AuctionData to auctionData[auctionCounter] with all auction metadata
Then emits event NewAuction

placeSellOrders

Example transaction: https://rinkeby.etherscan.io/tx/0x344cb6cda34859d9d9392bdb7c369971d9fc4a8eac877415a2bee8e56ed6932b

This method is public and called directly from the frontend. This checks the modifier atStageOrderPlacement
Why do they use memory for some of the parameters? (linked to them being arrays?)
auctionId id for the auction to place the order for -
_minBuyAmounts this is the minimum amount of bonds the user would get (1/20th from screenshot) - this is determined by dividing the sellAmount by the Max Bidding Price
_sellAmounts this is the amount of the biddingToken to sell (1 from screenshot)
_prevSellOrders
allowListCallData,

registerUser

user takes in an address
This increments the number of users, and inserts the user to the registeredUsers biMap
Userid is just the users current # - I'm guessing this is to make it easier to be able to map through all users
Then emits an event UserRegistration

getUserId

user takes in an address to get userId for
This checks if the given user has been registered in the registeredUsers biMap - if they aren't is adds them and returns their ID

settleAuction

auctionID id of the auction to settle
This settles the auction and calculates the price.
gets auctioneerId, minAuctionedBuyAmount and fullAuctionedAmount from the initialAuctionOrder (which is when the auction is initalized)

'settleAuctionAtomically`

auctionId id of the auction to settle
_minBuyAmount
_sellAmount
_prevSellOrder
Can only be called at atStageSolutionSubmission stage. Checks that automatic closure is allowed and that only one order is being placed

Need to call ERC20(BiddingToken).approve(this.address,0) before a user can call placeSellOrders

Why do they use IdToAddressBiMap ? - seems like they use that so they have a an easy way to iterate through all biders

Things we will need to change

from v1-core.

How to send out bond tokens on successful auction?
Gnosis makes bidders claim their proceeds.
https://gnosis-auction.eth.link/#:~:text=4.%20Bidders%3A%20Claiming,their%20auction%20proceeds.

How I'm thinking about it right now is,

• a new auction is requested
• a new ERC-20 token is created
• a new auction is created with the new token used as the auction's _auctioningToken
• the token address maps to the auction ID

bidders then bid with the _biddingToken e.g. DAI, and can claim the unique ERC-20 for the auction.

Multiple EasyAuction contracts or just one?
I can't think of a reason to have multiple auctions. each newly created auction can have it's own parameters in their current contract.

from v1-core.

How I'm thinking about it right now is,

Is there a reason we would want to deploy the new token before the auction finishes? Gnosis does not allow a claim until atStageFinished - benefit might be saving on gas for auctions that don't get enough bids to successfully clear

I can't think of a reason to have multiple auctions. each newly created auction can have it's own parameters in their current contract.

I think 1 makes sense. If we need to we can still probably deploy a new version of it without too much hassle.

from v1-core.

From peteris:

generally, you should have a strong preference for:

• using existing deployed code / factories

I wonder if we can use the deployed auction contract https://etherscan.io/address/0x0b7ffc1f4ad541a4ed16b40d8c37f0929158d101#code

from v1-core.

Is there a reason we would want to deploy the new token before the auction finishes? Gnosis does not allow a claim until atStageFinished - benefit might be saving on gas for auctions that don't get enough bids to successfully clear

We need the token address (a valid ERC20) at auction creation

from v1-core.

We need the token address (a valid ERC20) at auction creation

With the current implementation but we could change that right?

I wonder if we can use the deployed auction contract https://etherscan.io/address/0x0b7ffc1f4ad541a4ed16b40d8c37f0929158d101#code

I don't think so they have some variables that we'd need to be able to configure

from v1-core.

How to send out bond tokens on successful auction? Gnosis makes bidders claim their proceeds. https://gnosis-auction.eth.link/#:~:text=4.%20Bidders%3A%20Claiming,their%20auction%20proceeds.

How I'm thinking about it right now is,

• a new auction is requested
• a new ERC-20 token is created
• a new auction is created with the new token used as the auction's _auctioningToken
• the token address maps to the auction ID

bidders then bid with the _biddingToken e.g. DAI, and can claim the unique ERC-20 for the auction.

Multiple EasyAuction contracts or just one? I can't think of a reason to have multiple auctions. each newly created auction can have it's own parameters in their current contract.

PS i'm working on the new token contract as part of #4

• a new ERC-20 token is created

Let me know if you prefer to take it though !

from v1-core.

PS i'm working on the new token contract as part of #4

Right - I'm modifying the auction now to see what it'd look like without using an auctioning token, and triggering token creation upon successful auction

from v1-core.

Right - I'm modifying the auction now to see what it'd look like without using an auctioning token, and triggering token creation upon successful auction

We could do it either way - so I'm curious what you think is best. Biggest difference I'm thinking from the user perspective is when the token deployment gas needs paid. (On createAuction transaction vs the settleAuction transaction)

@luckyrobot is looking into the gas cost for deploying a new bond token #4 (comment)

from v1-core.

Fixed with #6

from v1-core.