I'll hav eto look that up, there are many ways to exploit these contracts ( I don't call them smart, because often they are dumb!) But I think the point of this series is to get you up to speed, he has other videos where he goes over exploits, think of this as a 101 or 102 course.
dear scp~ I have some questions. 1. so as dx will always be equal to dy, the price for x and y will always be 1:1? 2. what kind of exchange will use this 1:1 price model? as the price will never change? 3. when adding liquidity into the pool, someone adds 100x and 150y, so the 50y will never be able to withdraw?
1. yes 2. No exchange. Hybrid of CSAMM and CPAMM exists. (Curve and Yield Space) 3. X and Y are treated equally. So they will be able to withdraw both tokens
I have a question. Generally a lot of AMMs handle decimals explicitly in case in which you don't have tokens with same decimals by upscaling the amount and downscaling to make it 18 deicmals. Can you tell how important is that ?
Note what happens if the user tries to swap 1 wei of token0 for token1; they get 0 wei of token1, since 1*997/1000 = 0 in integer math! That's kind of silly, but I did notice that. I saw that AAVE uses fixed point decimal arithmetic, but I guess that has a higher gas cost.
Thank you for your video. And I have a question. There is no need to consider about token price?? Always swap 1:1 token pairs? If initial added liquidity 100:400 then, is it swap 1:1 too?
If you did away with the private function _update(), what would that do to the gas expenditure? It's be a little more to deploy the contract, since there'd be repetitive code, but wouldn't it save gas for the users when they call swap / addlqiuidity / removeliquidity? I assume there is some gas overhead involved in calling a private function.
I think on line 13 you should have called totalSupply totalShares to be clearer, just a small disagreement. Because when I see supply, my brain goes, 'supply of what? Shares or tokens?'
Why the red"!"(line 6) disappear after you compile it at 3:36? I have observed that kind of case happened several times in your other class videos? some magic happen?
At about 31:30 you say you're going to put token 0 (0xD9...) in and get token 1 (0xD8...) out, but you approved a transfer for 10 of token 0 (0xD9), and then you go on to swap 10 of token 1 for 10 of token 0. But you didn't approve a spend of 10 of token 1. What am I missing here?
0:00 - Intro
0:45 - State variables and constructor
3:35 - Internal functions - mint and burn
5:04 - Swap
13:20 - Refactor swap function
19:40 - Add liquidity
23:48 - Remove liquidity
26:26 - Fix compilation errors
26:50 - Deploy
28:08 - Demo add liquidity
30:04 - Demo swap
31:36 - Demo remove liquidity
CSAMM math
ruclips.net/video/-JhgcqvyYeM/видео.html
Code
solidity-by-example.org/defi/constant-sum-amm
Take a course
www.smartcontract.engineer/
Most needed Solidity video in EVM's history!
Ohh lord! Thank you so much SCP for this. I really needed this explanation in solidity
Excellent youtube channel! THE BEST. Please make more tutorials like complicated contracts etc.
Constant product AMM just published
This is more than GOLD! Thank you
great video man, love these sort of tutorials !
Great explanation! Very clear!
Sooo this is how DEX work... thanks a lot!
Great example. Also, a caveat about sandwich attacks could be said. There is no sandwich attack protection within the example!
I'll hav eto look that up, there are many ways to exploit these contracts ( I don't call them smart, because often they are dumb!) But I think the point of this series is to get you up to speed, he has other videos where he goes over exploits, think of this as a 101 or 102 course.
Why the reserves in 'swap()' are updated by incoming '_amountIn'. Shouldn't they be updated by more precise recalculated 'amountIn'?
I think typo
dear scp~ I have some questions.
1. so as dx will always be equal to dy, the price for x and y will always be 1:1?
2. what kind of exchange will use this 1:1 price model? as the price will never change?
3. when adding liquidity into the pool, someone adds 100x and 150y, so the 50y will never be able to withdraw?
1. yes
2. No exchange. Hybrid of CSAMM and CPAMM exists. (Curve and Yield Space)
3. X and Y are treated equally. So they will be able to withdraw both tokens
@@smartcontractprogrammer ok ,maybe just do the dx==dy check when adding the liquidity? In the PAMM you do the dx*y = dy*x.
I have a question.
Generally a lot of AMMs handle decimals explicitly in case in which you don't have tokens with same decimals by upscaling the amount and downscaling to make it 18 deicmals.
Can you tell how important is that ?
Very important, I forgot to mention in the video
@@smartcontractprogrammer haha cool answer :D
Note what happens if the user tries to swap 1 wei of token0 for token1; they get 0 wei of token1, since 1*997/1000 = 0 in integer math! That's kind of silly, but I did notice that. I saw that AAVE uses fixed point decimal arithmetic, but I guess that has a higher gas cost.
most tokens will have 6 or 18 decimals to mitigate loss of precision
Hii... Please also cover a full series of Solidity smart Contracts Audit... Examples....
Thank you for your video. And I have a question. There is no need to consider about token price?? Always swap 1:1 token pairs? If initial added liquidity 100:400 then, is it swap 1:1 too?
yes
If you did away with the private function _update(), what would that do to the gas expenditure? It's be a little more to deploy the contract, since there'd be repetitive code, but wouldn't it save gas for the users when they call swap / addlqiuidity / removeliquidity? I assume there is some gas overhead involved in calling a private function.
yes
this is gold!!!!!
I think on line 13 you should have called totalSupply totalShares to be clearer, just a small disagreement. Because when I see supply, my brain goes, 'supply of what? Shares or tokens?'
Why the red"!"(line 6) disappear after you compile it at 3:36? I have observed that kind of case happened several times in your other class videos? some magic happen?
video edit
@@smartcontractprogrammer Thanks! but why? Is the complier bug problem?
At about 31:30 you say you're going to put token 0 (0xD9...) in and get token 1 (0xD8...) out, but you approved a transfer for 10 of token 0 (0xD9), and then you go on to swap 10 of token 1 for 10 of token 0. But you didn't approve a spend of 10 of token 1. What am I missing here?
i might have recorded something wrong
why do you even need line 51, isn't amountIn==_amountIn? Maybe it's safer to do it this way? Seems like a waste of gas?
some ERC20 tokens have transfer on fees and other ERC20 token allow transfer of type(uint256).max to mean transfer all the balance
Great video 😎. How do we factor in fees into this model?
it's usually taken from amount that goes out
@@smartcontractprogrammer ooohhh.... got it. Thanks
🤓🍜