reserve to offer Token or ETH for sale

[szerintedmi]

The Stability Board (SB) should be able to offer tokens or ethers from the reserves for sale with an ETH or token amount and an A-EUR/EUR price.

There can be potentially both sales and buy offers at the same time open (with different price and amount).

We don't need multiple offers from the same type open at the same time (i.e. only 0 or 1 sell token and 0 or 1 buy token can be open at the same time)

SB should be able to cancel any of its sales offers.

Anyone should be able to take a sell or buy token offer. Deal price is calculated from ETH/EUR actual market price from Rates contract at the moment of tx and the A-EUR/EUR provided by SB when placed the offer.

TBD:

• should it be a MonetarySupervisor (MS) interface which calls Reserve or SB would call directly on Reserves?
• Should the amounts on sale stay in Reserve contract or move to/from a separate ReserveSales contract? If the former then we need keep accounting offers on sale vs. reserve available

[krosza]

ad. 1 opinion: SB could call directly and transfer to ReserveSale contract tokens
ad. 2. it is sub optimal is users are to transact directly with Reserve, so it is better if we have a separate ReserveSales contract

[szerintedmi]

First pass for discussion.

Notes:

1. One ReserveSales contract handles one type of AugminToken only
2. The ETH or token balance of ReserveSales is what is on sale, on the A-EUR/EUR price provided in last increase sale amount call (a call with 0 value for increase amount can be used to update price)
3. increaseReserveTokenSale, increaseReserveEthSale, reduceTokenSellOrder and reduceEthSellOrder is called directly on AugmintReserves. I didn't see a point to pass it through MonetarySupervisor. It's assuming that any amount in reserve could go on sales based on MonetaryBoard decision. Passing through MS would have been unnecessary complication.

[krosza]

1. mirror txs. it seems that all user initiated tx (take) is followed by a tx between an automatic ReserevSales and AugmintReserves. There can be thousands of takes for one MB sales order. From accounting and portfolio management point of view this is fine, but is that necessary? It is a bit costly compare to one or two reduce txs when the MB order is depleted. TBD if that is the case.A 2. Consider to have two ResereveSales contract instead of one in case of any Augmint token. One for eth sale, one for eth buy. 3. Tx narrative.not clear if there is one. Augmint commercial use require that in case of both buy and sell A-EUR. The narrative is the a-eur/eur price. 4. Will be a minimum take amount? 5. Will be a maximum order increase amount? To avoid/mitigate MB mistakes. 6. How to handle the trade bot's actions? I.e. Augmint as an escape tool in case of volatile eth/eur price movement. Corion died in this. I can see no other solution than to refrain to be on the two side in the same time. TBD <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

…

On 18 February 2018 at 10:38, Peter Petrovics ***@***.***> wrote: First pass for discussion. Notes: 1. One ReserveSales contract handles one type of AugminToken only 2. The ETH or token balance of ReserveSales is what is on sale, on the A-EUR/EUR price provided in last increase sale amount call (a call with 0 value for increase amount can be used to update price) 3. increaseReserveTokenSale, increaseReserveEthSale, reduceTokenSellOrder and reduceEthSellOrder is called directly on AugmintReserves. I didn't see a point to pass it through MonetarySupervisor. It's assuming that any amount in reserve could go on sales based on MonetaryBoard decision. Passing through MS would have been unnecessary complication. [image: ReserveSales flow first pass] <https://github.com/Augmint/augmint-contracts/raw/634b8105cad1c3ca45cd0bec2350b6cb1fa5a467/docs/reserveSalesFlow.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMNFgsRAJ3v3Q2G5OjWgmkesHW7gmSGGks5tV--OgaJpZM4SHYy6> .

[szerintedmi]

1. mirror txs. it seems that all user initiated tx (take) is followed by a
   tx between an automatic ReserevSales and AugmintReserves. There can be
   thousands of takes for one MB sales order. From accounting and portfolio
   management point of view this is fine, but is that necessary? It is a bit
   costly compare to one or two reduce txs when the MB order is depleted.
   TBD if that is the case.A

We might be able to save some gas but less than you expect. If we don't immediately transfer traded ETH or tokens to Reserve then we would need maintain two extra state vars (how much sold) + have an extra tx to withdraw those. Both cost gas. In return for a minor gas save we would add a lot extra complexity (count in these balances to reserve balance everywhere, extra tx, security considerations etc.)

2. Consider to have two ResereveSales contract instead of one in case of
   any Augmint token. One for eth sale, one for eth buy.

What's the requirement there?

3. Tx narrative.not clear if there is one. Augmint commercial use require
   that in case of both buy and sell A-EUR. The narrative is the a-eur/eur
   price.

Adding data to the narrative is not obvious. Event logs from the trades will generated so UI can display additional information.

4. Will be a minimum take amount?

No. Why would?

5. Will be a maximum order increase amount? To avoid/mitigate MB mistakes.

No. MB can make so many other mistakes too - that's why we will have a multisig board and not a single person. We should add these checks to the MB UI.

6. How to handle the trade bot's actions? I.e. Augmint as an escape tool
   in case of volatile eth/eur price movement. Corion died in this. I can see
   no other solution than to refrain to be on the two side in the same time.
   TBD

I assume that's a separate discussion, let's see any requirement falls out from that.

[szerintedmi]

We discussed that that limited pilot could potentially start without ReserveSales contract. Pilot participants could "act as reserve" by placing orders directly on internal exchange during the limited pilot.
We park discussing this feature further for now but these are the outcomes so far:

1.&2.: we will do some test to see the actual gas difference and decide based on the results

3. Narrative won't contain order data - UI will handle that based on event logs. Tx readability on etherscan is expected to improve by adding ENS names to ReserveSales contract + will check how much it help if contract code is uploaded to etherscan (ie. it might decode event logs in a more readable format?)

4. Contract won't limit take amount, UI can do it if necessary

5. neither AugmintReserves or ReserveSales will have max limits for SB. Multisig SB and the SB UI should take care of this.

6. separate conversation