-
Notifications
You must be signed in to change notification settings - Fork 13
feat: add liquidity unbalanced permit2 #1117
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@@ -106,4 +134,22 @@ export class UnbalancedAddLiquidityHandler implements AddLiquidityHandler { | |||
kind: AddLiquidityKind.Unbalanced, | |||
} | |||
} | |||
|
|||
public constructBaseBuildCallInput({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will probably try to extract this method to be shared by all the handlers but for now I will keep it here until I implement the rest of the v3 handlers
slippage: Slippage.fromPercentage(`${Number(slippagePercent)}`), | ||
wethIsEth: this.helpers.includesNativeAsset(sdkQueryOutput.amountsIn), | ||
} | ||
// baseBuildCallParams.amountsIn = baseBuildCallParams.amountsIn.filter( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will delete this later. It is a reminder to try something...
lib/modules/pool/actions/add-liquidity/queries/useAddLiquidityBuildCallDataQuery.ts
Show resolved
Hide resolved
lib/modules/pool/actions/add-liquidity/handlers/UnbalancedAddLiquidity.handler.ts
Outdated
Show resolved
Hide resolved
lib/modules/pool/actions/add-liquidity/handlers/UnbalancedAddLiquidity.handler.ts
Outdated
Show resolved
Hide resolved
lib/modules/pool/actions/add-liquidity/handlers/UnbalancedAddLiquidity.handler.ts
Outdated
Show resolved
Hide resolved
lib/modules/pool/actions/add-liquidity/handlers/UnbalancedAddLiquidityV3.handler.ts
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,55 @@ | |||
//TODO: move all this file logic to a better place |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just call it add-liquidity.utils.ts for now.
lib/modules/tokens/approvals/permit2/Permit2SignatureProvider.tsx
Outdated
Show resolved
Hide resolved
lib/modules/tokens/approvals/permit2/signPermit2TokenTransfer.tsx
Outdated
Show resolved
Hide resolved
} | ||
} | ||
|
||
async function signPermit2({ | ||
sdkClient, | ||
pool, | ||
humanAmountsIn, | ||
permit2Input, | ||
nonces, | ||
}: SignPermit2Params): Promise<Permit2> { | ||
if (!sdkClient) throw new Error('Missing sdkClient') | ||
const baseInput = constructBaseBuildCallInput({ | ||
humanAmountsIn, | ||
slippagePercent: permit2Input.slippagePercent, | ||
// TODO: generalize for all v3 pool types | ||
sdkQueryOutput: permit2Input.sdkQueryOutput as AddLiquidityBaseQueryOutput, | ||
pool, | ||
}) | ||
|
||
const signature = await Permit2Helper.signAddLiquidityApproval({ | ||
...baseInput, | ||
client: sdkClient, | ||
owner: permit2Input.account, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be generalized or does it need to be two functions, one for add liquidity and one for swaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably both, I would wait until we implement V3 swaps.
}, [setSignPermit2State, sdkClient]) | ||
|
||
//TODO: Generalize for Swaps and other potential signatures | ||
const minimumBpt = queryOutput?.sdkQueryOutput.bptOut.amount |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The naming here is a bit misleading? It's not minimum, you're just checking that
we have a bptOut value right? If so, I'd change to:
const minimumBpt = queryOutput?.sdkQueryOutput.bptOut.amount | |
const hasBptOut = !!queryOutput?.sdkQueryOutput.bptOut.amount |
labels: { | ||
title: `Permit on balancer`, | ||
init: `Sign permit`, | ||
tooltip: 'Sign permit', | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should change user facing terminology for users from Approvals.
Because in the end it's the same thing, just the underlying tech is a bit
different. If they need more information about what type of a approval they are
doing then we can provide more information, but that should be nested. Please
confirm this with Pon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to wait until we have everything together (v3 adds/removes for different kinds of pools) and then review the labels and UX hints (tooltips, links etc) after some user testing.
Adds v3 permit2 flow only for unbalanced add handler.
Contains many TODOs but let's merge it before moving to the monorepo.
Note: It only works pointing to
test api
in.env.local
as sepolia v3 pools are not yet inproduction api
Unbalanced add
https://github.com/user-attachments/assets/dd105d30-3df6-40a7-a05d-d18689fca49a
Reuse signature in the next 24h after permit2 signature
https://github.com/user-attachments/assets/b824a3bf-b210-4956-b970-7d7aa1192574
@garethfuller we can avoid signing the permit2 for those tokens that have 0 amount but I got some errors when I tried that so I will do that in a different PR 👇

MAX amount during 24H: