Starting today you can manage your LP positions directly from your dashboard. What we are rolling out today supports Uniswap v3 positions only for now, but we’ll soon be adding the same functionality for Uniswap v2 and Sushiswap as well as other protocols to be announced.

A position card will display buttons that allow LPs to perform the following actions:

• Add liquidity to an existing position: Using the connected wallet’s balances with a nifty slider to increase liquidity in the required proportions to any position.

• Remove liquidity from an existing position: After connecting your wallet, you are able to withdraw any amount of liquidity from a position you own.

• Collect fees from positions: You can likewise use the nifty slides to collect any amount of uncollected fees from a position you own

You are interacting directly with the protocols (Uniswap v3 in this case) and using Revert only as a frontend. When adding, removing, or claiming fees, you interact with Uniswap’s V3 NonFungiblePositionManager.

This contact was deployed with address 0xC36442b4a4522E871399CD717aBDD847Ab11FE88 on all currently supported chains.

You can (and should) alternatively verify addresses match what you expect with other sources like the etherscan link, and in this case, the uniswap docs.

When you get to the signing transaction step you should always verify that addresses match what you expect. In this case, the address for the contract described above. Here it is again: 0xC36442b4a4522E871399CD717aBDD847Ab11FE88

• You should be checking first that the addresses displayed above match the linked contract address on etherscan.

• That the etherscan page for the contract is what you expect, in this case, The Uniswap’s NonFungiblePositionManager.

• Additionally you are checking on the Uniswap docs, that the deployment address for the contract matches the above.

• Now that you are totally sure you have the correct address, you verify that it is the same one you are interacting with on your wallet when signing transactions.

Just a horrible set of almost unfollowable steps you are bound to skip on at some point.

The recent bout of DNS hijackings are a good example of why it is not safe to blindly trust any frontend. And it would be easy to derail off-topic here on how wallets could do a better job of protecting users, so let’s do it!

• Wallets should recognize and verify that you are interacting with the Uniswap NFT Manager contract. Sure, this is not possible for any arbitrary contracts, but wallets can recognize addresses for the most widely used protocols. Only a failure to display some form of Verified ID would require the user to manually check the addresses. This could be done without introducing centralization, like Token Lists.

• Addresses are obviously just the first step and wallets should be able to use contract ABIs to give users a much more descriptive view of which method they are calling and with what parameters.

• Identified attacker addresses should be marked as such by the wallet. Wallets shouldn’t prevent users from interacting with any contract they want, needless to say, but identified attacker addresses should be marked so as to alert the user.

For sure we are not the first to suggest any of these, some wallets even have partial implementations of what is suggested above, and needless to say there are better ideas out there. But the current state of things could be accurately described as “pretty bad”, and not for the hypothetical next billion users who will absolutely not be bothered to check any of this, but for the experienced DEFIor who has been around the block and just wants to use their wallet to interact with some risky protocols safely.

Will you be supporting other protocols? Definitely.

What protocols are currently supported? Uniswap v3 on Ethereum Mainnet and Matic.

Are you charging a fee for this? No, and you are interacting directly with the protocol contracts.

-

Our mission is to build powerful tools for liquidity providers in AMM protocols, while keeping them open and accessible by everyone. In the next few months, we will be releasing further integrations with protocols, contracts, L2s, and sidechains as we build the ultimate AMM LP management interface. So, more stuff coming soon!

Starting today you can manage your LP positions directly from your dashboard. What we are rolling out today supports Uniswap v3 positions only for now, but we’ll soon be adding the same functionality for Uniswap v2 and Sushiswap as well as other protocols to be announced.

A position card will display buttons that allow LPs to perform the following actions:

• Add liquidity to an existing position: Using the connected wallet’s balances with a nifty slider to increase liquidity in the required proportions to any position.

• Remove liquidity from an existing position: After connecting your wallet, you are able to withdraw any amount of liquidity from a position you own.

• Collect fees from positions: You can likewise use the nifty slides to collect any amount of uncollected fees from a position you own

You are interacting directly with the protocols (Uniswap v3 in this case) and using Revert only as a frontend. When adding, removing, or claiming fees, you interact with Uniswap’s V3 NonFungiblePositionManager.

This contact was deployed with address 0xC36442b4a4522E871399CD717aBDD847Ab11FE88 on all currently supported chains.

You can (and should) alternatively verify addresses match what you expect with other sources like the etherscan link, and in this case, the uniswap docs.

When you get to the signing transaction step you should always verify that addresses match what you expect. In this case, the address for the contract described above. Here it is again: 0xC36442b4a4522E871399CD717aBDD847Ab11FE88

• You should be checking first that the addresses displayed above match the linked contract address on etherscan.

• That the etherscan page for the contract is what you expect, in this case, The Uniswap’s NonFungiblePositionManager.

• Additionally you are checking on the Uniswap docs, that the deployment address for the contract matches the above.

• Now that you are totally sure you have the correct address, you verify that it is the same one you are interacting with on your wallet when signing transactions.

Just a horrible set of almost unfollowable steps you are bound to skip on at some point.

The recent bout of DNS hijackings are a good example of why it is not safe to blindly trust any frontend. And it would be easy to derail off-topic here on how wallets could do a better job of protecting users, so let’s do it!

• Wallets should recognize and verify that you are interacting with the Uniswap NFT Manager contract. Sure, this is not possible for any arbitrary contracts, but wallets can recognize addresses for the most widely used protocols. Only a failure to display some form of Verified ID would require the user to manually check the addresses. This could be done without introducing centralization, like Token Lists.

• Addresses are obviously just the first step and wallets should be able to use contract ABIs to give users a much more descriptive view of which method they are calling and with what parameters.

• Identified attacker addresses should be marked as such by the wallet. Wallets shouldn’t prevent users from interacting with any contract they want, needless to say, but identified attacker addresses should be marked so as to alert the user.

For sure we are not the first to suggest any of these, some wallets even have partial implementations of what is suggested above, and needless to say there are better ideas out there. But the current state of things could be accurately described as “pretty bad”, and not for the hypothetical next billion users who will absolutely not be bothered to check any of this, but for the experienced DEFIor who has been around the block and just wants to use their wallet to interact with some risky protocols safely.

Will you be supporting other protocols? Definitely.

What protocols are currently supported? Uniswap v3 on Ethereum Mainnet and Matic.

Are you charging a fee for this? No, and you are interacting directly with the protocol contracts.

-

Our mission is to build powerful tools for liquidity providers in AMM protocols, while keeping them open and accessible by everyone. In the next few months, we will be releasing further integrations with protocols, contracts, L2s, and sidechains as we build the ultimate AMM LP management interface. So, more stuff coming soon!