Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding UniswapV2 properties #38

Draft
wants to merge 9 commits into
base: main
Choose a base branch
from
Draft

Conversation

tuturu-tech
Copy link
Contributor

Initial draft of UniswapV2 basic properties.

Providing liquidity

  • always increases K
  • always increases LP token supply
  • always increases user LP token supply
  • never impacts token prices
  • always increases token reserves

Withdrawing liquidity

  • always decreases K
  • always decreases LP token supply
  • always decreases user LP token supply
  • never impacts token prices
  • always decreases token reserves

Swapping

  • never decreases K
  • swapping in both directions does not result in tokens gained
  • always increases user token out balance
  • price of tokenIn always decreases
  • price of tokenOut always increases

Blockers: Properties fail with ErrorUnrecognizedOpcode crytic/echidna#984, so far haven't been able to figure out why
Cons: Only tests UniswapV2 pair and router. Next step will be to generalize this so the properties can be easily used in a harness for testing UniV2-based AMMs

@aviggiano
Copy link
Contributor

Hi,
This is a great feature, I'm excited to try this out.

By the way, while working on a fuzzer comparison, I noticed that "Withdrawing liquidity always decreases LP token supply" is not always true:

When the feeTo address is on, withdrawing liquidity can increase the total supply of LP tokens. This is because UniswapV2Pair.burn can trigger a UniswapV2Pair._mint, so depending on the amount minted/burned the net effect can be either positive or negative.

Comment on lines +159 to +163
uint256 actualAmountIn = _between(
amountIn,
1,
inToken.balanceOf(address(user))
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may revert with an underflow, as the high parameter of the _between function inToken.balanceOf(address(user)) can be 0, while low is 1.

I believe it is necessary to add a require(inToken.balanceOf(user) >= 1); before this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants