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

Integrations/uni v3 #49

Closed
wants to merge 5 commits into from
Closed

Integrations/uni v3 #49

wants to merge 5 commits into from

Conversation

jwarmuz99
Copy link
Contributor

This PR implements an ape-based sdk for Uniswap V3

Copy link
Contributor

@Gonmeso Gonmeso left a comment

Choose a reason for hiding this comment

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

Great work, but there are some things that we could look into.

Taking the test as an example of the usage, it feels more like a standalone ape script than something that should be integrated with Agents, the agents handles the default sender, the chain and the instantiation of the contracts which is done manually in this script and in the uniswap classes.

Maybe some things that we could do:

  • Create a base class for the uniswap contracts so we can have common functionality in the instantiation, logging, utils...
  • Think about de DX like for example calling directly to the function rather than calling the underlying contract (uni.foo(...) vs uni.router.foo(...)
  • If we are thinking of having multiple integrations, we might need to define how to develop the new ones to focus on extensibility and modularity


from giza_actions.integrations.uniswap.uniswap import Uniswap

networks.parse_network_choice(f"ethereum:mainnet-fork:foundry").__enter__()
Copy link
Contributor

Choose a reason for hiding this comment

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

I would rather use the with statement rather than the __enter__ method:

with networks.parse_network_choice(f"ethereum:mainnet-fork:foundry"):
    ...

Copy link
Contributor

Choose a reason for hiding this comment

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

Keep the folder name in lower: giza_actions/integrations/uniswap/assets/erc20.json

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm guessing that these .json are basically the contracts definitions, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, the ABIs

Copy link
Contributor

Choose a reason for hiding this comment

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

We could consider the addresses as constants and we could add it here rather than having two separate files

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I didn't want to clutter the constants.py with a long dictionary and whenever I'm working with a web3 project, I find it helpful to have one place with all the addresses so I can go to the explorer and get a better feel of a contract... having said that, happy to move to constants.py if you deem it better

Copy link
Contributor

Choose a reason for hiding this comment

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

Missing docstrings and type hints

uni = Uniswap(sender=sender, version=3)
pool = uni.get_pool(token0, token1, fee)
price = pool.get_pool_price(invert=True)
print(f"--------- Pool Price: {price}")
Copy link
Contributor

Choose a reason for hiding this comment

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

Even if its for testing purposes i would rather use logging than print:

import logging

logger = logging.getLogger(__name__)

logger.info(f"--------- Pool Price: {price}")

@@ -0,0 +1,39 @@
ADDRESSES = {
# mainnet
1: {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not using names directly, rather than the chain_id?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To avoid errors when testing with local forks. If I used the name (e.g. ethereum:mainnet) but I wanted to test on e.g. ethereum:mainnet-fork:foundry, I would need to add another parsing method. This way I have a unique id that will always work

ADDRESSES = {
# mainnet
1: {
3: {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why there is always this 3 as a key in all the addresses?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

uniswap version 3. I don't have v2 support yet but it definitely should be one of the next todos

address, abi=os.path.join(os.path.dirname(__file__), "ASSETS/pool.json")
)
self.sender = sender
self.token0 = Contract(
Copy link
Contributor

Choose a reason for hiding this comment

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

Are all of these variables supposed to be used by the user? We need to think what we tell the user "This is for you to use" or "This is 'private' and use at your own risk"

### Quoter ###
amount_in = int(1e8)
# calling using pool object
amount_out = uni.quoter.quote_exact_input_single(amount_in, pool=pool)
Copy link
Contributor

Choose a reason for hiding this comment

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

I feel like using uni.quoter or uni.nft_manager everytime that we want to execute makes the Uniswap class a little bit useless as we could just do the init by ourselves of the other classes and call directly de quoter or router.

Maybe we need to think about how we organize the code

@jwarmuz99 jwarmuz99 closed this Jun 12, 2024
@jwarmuz99 jwarmuz99 deleted the integrations/uni-v3 branch June 12, 2024 14:02
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.

None yet

2 participants