Logic for local tracking of _reserves_ is totally solid. But it raises couple of questions. What is damage estimation for direct `transfer`? Does it justify these state vars? And if we track locally, then should we `update` values from token contracts? What risks of confusing behavior does it introduce? These are interesting topics for discussion to me. Thanks for the tutorial!
why didnt you update the reserves in the swap using: (reserveA + amountIn , reserveB - amountOut) like you did in CSAMM. Why use the balance of the contract especially when the point was to maintain an internal state immune to external deposits.
I think this is to allow mistakenly sent tokens to not be locked forever For the imbalance, It creates an opportunity for arbitrageurs who balance the pools back. Doesn't affect LPs, it actually brings in more fees for them.
I have two questions: 1. If we directly send the token0 to contract, that means that we increase the price of token1 and decrease the price of token0 in terms of token0 and token1. 2. If we directly send the 1000 token0 to contract, that means that 1000 token0 will be distributed between share holders?
So in this case, there are no LP tokens actually minted? its that balanceOf and totalSupply is used to manage liquidity provided, and thus there cant be transfer of LP token or Liquidity Ownership?
18:27 Why are you giving the minimum value as the share instead of saving both share0 and share1 as individual values? Now when someone tries to burn their shares, they always get back their tokens in a 50:50 proportion based on the smallest value of (token0, token1). Is this to incentivize giving equal proportion of token0 and token1 to the AMM when someone provides liquidity?
On the swap method, to save some gas for the user wouldn't it be better to make then 2 methods? One swapToken0(amount) and the other swapToken1(amount)? Just wondering :)
I have one question 1. you set the fee on the amountIn , and in another video, about sum AMM you set the fee on amoutOut , are there any reason you use the two different directions?
theres nothig explained here properly.. what is the IERC contract, what about the erc contract code. you haven't shared it. the last explanation you sort of mess up by saying supplier1 supplier1 again and again. What about the frontend connection if I want.. how do I connect it? We need more fluent info please!
no - for add liquidity and swap, token balances are tracked internally by reserve0 and reserve1 for removeLiquidity, direct transfer will benefit the caller of remove liquidity
@@smartcontractprogrammer Great tutorial codes featured. It works flawlessly and direct transfer of tokens to the contract benefits all existing stakers indeed. On your other video on single staking reward using Synthetic algorithm, will it make sense to implement here too based off users' share over total share?
any help will be appricated ,getting below error while trying to add liquidity , am confused how token got minted that is which address is provided on minting , the address using which contract is getting deployed or the new address which got generated after contract deployment. ?
While running Slither, it gave a critical warning that returned value of transferFrom isn't checked. Would it be possible, say the tokenIn.transferFrom(msg.sender, address(this), _amountIn) returned false and user ended up getting amount Out for free in the "swap function?
0:00 - State variables and constructor
2:38: Internal functions - mint and burn
3:55 - Public functions - swap, add liquidity and remove liquidity
5:03 - swap
13:47 - addLiquidity
20:10 - removeLiquidity
24:33 - Demo - deploy contracts
25:32 - Demo - add liquidity
26:53 - Demo - swap
28:14 - Demo - remove liquidity
CPAMM math
ua-cam.com/video/QNPyFs8Wybk/v-deo.html
Code
solidity-by-example.org/defi/constant-product-amm
Take a course
www.smartcontract.engineer/
You are a legend 🐐
Logic for local tracking of _reserves_ is totally solid. But it raises couple of questions.
What is damage estimation for direct `transfer`? Does it justify these state vars?
And if we track locally, then should we `update` values from token contracts? What risks of confusing behavior does it introduce?
These are interesting topics for discussion to me. Thanks for the tutorial!
You are amazing! Thanks
why didnt you update the reserves in the swap using:
(reserveA + amountIn , reserveB - amountOut) like you did in CSAMM.
Why use the balance of the contract especially when the point was to maintain an internal state immune to external deposits.
following Uniswap V2 code
I think this is to allow mistakenly sent tokens to not be locked forever
For the imbalance, It creates an opportunity for arbitrageurs who balance the pools back. Doesn't affect LPs, it actually brings in more fees for them.
Thanks Michael!
Great video as usual. is it more populare the Constant sum AMM or the Constant product AMM?
product
banger
I have two questions:
1. If we directly send the token0 to contract, that means that we increase the price of token1 and decrease the price of token0 in terms of token0 and token1.
2. If we directly send the 1000 token0 to contract, that means that 1000 token0 will be distributed between share holders?
1. yes.
2. I think the one who first updates the reserve will get the 1000 token0.
@@呆湾南坡丸 2. can you proof this?
So in this case, there are no LP tokens actually minted? its that balanceOf and totalSupply is used to manage liquidity provided, and thus there cant be transfer of LP token or Liquidity Ownership?
yes, no LP tokens
it's easy to modify the contract to support LP tokens (inherit ERC20, define mint and burn functions)
18:27 Why are you giving the minimum value as the share instead of saving both share0 and share1 as individual values? Now when someone tries to burn their shares, they always get back their tokens in a 50:50 proportion based on the smallest value of (token0, token1).
Is this to incentivize giving equal proportion of token0 and token1 to the AMM when someone provides liquidity?
liquidity is one unit, not liquidity1 and liquidity2
share1 and share2 should be close but from rounding error, be safe and give the minimum
On the swap method, to save some gas for the user wouldn't it be better to make then 2 methods?
One swapToken0(amount) and the other swapToken1(amount)?
Just wondering :)
It's a trade-off of simple contract functions and gas saving
Hey can you please make a video on rebase Stablecoin such as ampleforth
I have one question
1. you set the fee on the amountIn , and in another video, about sum AMM you set the fee on amoutOut , are there any reason you use the two different directions?
CPAMM - following Uniswap V2
CSAMM - 2 tokens are equally priced so it doesn't matter how the fees are calculated
@@smartcontractprogrammer Thanks.😀 I think uniswap V2 may just randomly select the amountOut and put the fee on it.
I get confused when you say "this function should be internal so it is private" when internal is a different keyword with a different meaning.
i meant internal to the contract. Both the keywords internal and private will do
theres nothig explained here properly.. what is the IERC contract, what about the erc contract code. you haven't shared it. the last explanation you sort of mess up by saying supplier1 supplier1 again and again. What about the frontend connection if I want.. how do I connect it? We need more fluent info please!
ERC20 and CPAMM math are fully explained in other videos
Can a user not transfer token0 or token1 to the contract directly prior to calling any function and mess up the balance of reserve0 and reserve1?
no - for add liquidity and swap, token balances are tracked internally by reserve0 and reserve1
for removeLiquidity, direct transfer will benefit the caller of remove liquidity
@@smartcontractprogrammer Great tutorial codes featured. It works flawlessly and direct transfer of tokens to the contract benefits all existing stakers indeed.
On your other video on single staking reward using Synthetic algorithm, will it make sense to implement here too based off users' share over total share?
@Raymond Fam I thought of that too, but after looking through the code and comparing, i think the total share does the job too and is less complex
so stable swap is next right?
you bet
any help will be appricated ,getting below error while trying to add liquidity , am confused how token got minted that is which address is provided on minting , the address using which contract is getting deployed or the new address which got generated after contract deployment. ?
While running Slither, it gave a critical warning that returned value of transferFrom isn't checked. Would it be possible, say the tokenIn.transferFrom(msg.sender, address(this), _amountIn) returned false and user ended up getting amount Out for free in the "swap function?
Depends on the contract. Most ERC20 fail or return true. They never return false
@@smartcontractprogrammer Thank you. Precisely as you explained after going through OpenZeppelin's ERC20 contract.