Key-Price Update Frequency

[nfurfaro]

There's a concurrency issue around the keyPurchase flow: each purchase triggers a price change, possibly affecting the next purchase if tx has already been submitted at previous price.

2 possible mitigations are: 1.) Step-function: Have the price increase in steps rather than following the curve perfectly.

• concurrency still an issue when price is increased, but happens much less often.
• could save 5000 gas (SSTORE opcode) for writing to the lock's storage for each key purchase
• adds a small amount of complexity to contract.
• the mechanism used to track steps in function would have to use < 5000 gas for savings

2.) UI accounting for price slippage.

• Rather than adding to the smart contract, the concurrency issue could maybe be dealt with at the UI level.
• Calculate the price of the current key (based on the current supply), as well as the next key, and approve enough extra to buy a slightly more expensive key if necessary.
• Established pattern (uniswap)
• The extra amount needed to purchase the next key instead of the current one rapidly becomes negligible.

eg:

• by the 10th key sold, the price is increasing by only 5% per key.
• By the 50th key, only 1%
• under 0.5 % by the 75th key.

cc @julien51

[julien51]

Hey! I think we should take approach 1) but make it even simpler. I think for good practice/UI we should "round" the key price to the nearest 10cts. (It would be confusing for people to pay for $1.00213 for example.

So, the hook should compute the new key price and round it to the nearest 10 cts so that the price goes from from 10cts to 20 cts to 30 cts to... to 1 DAI to 1.10 DAI... etc.

This way, since we have a clear goal to reach about 10DAI when we get to 1Bn key sold, that means the price changes at most 100 times, and the changes will become less and less frequent with more keys sold.

What do you think?

[nfurfaro]

I like the rounding approach! I'll see about getting that feature working before my Rinkeby-test. Note that at the moment, the price for the 1Billionth key is $9, not 10. I could maybe tweak it if it's important to you that it be $10.

[julien51]

Nah, 9DAI is cool ;)

[nfurfaro]

closing as this is now resolved using price-rounding.