feat: evm-swap example #330

anshss · 2024-08-22T08:54:44Z

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.

Type of change

Introducing new feature (non-breaking change which adds functionality)

Link to the relevant updated sections in the Netlify preview

added a new page for evm-swap example

Checklist:

General

I have performed a self-review of my code
I have fixed all grammar issues (can use an AI tool to check), and explanations are in active voice
I have checked the additions are concise
Language is consistent with existing documentation
My changes generate no new warnings
Any dependent changes have been merged and published (ie. SDK changes, node dependencies)

If I have added a new concept, I have

included a beginner friendly explanation
included a basic technical introduction and code sample
new terms are defined, both in relevant new pages and in the glossary

netlify · 2024-08-22T08:55:02Z

✅ Deploy Preview for lit-dev-docs ready!

Name	Link
🔨 Latest commit	`9eb974d`
🔍 Latest deploy log	https://app.netlify.com/sites/lit-dev-docs/deploys/66db6b35b22f2f00080a03a3
😎 Deploy Preview	https://deploy-preview-330--lit-dev-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

docs/additional-examples/evm-swap.md

a1ttech · 2024-08-22T20:24:38Z

docs/additional-examples/evm-swap.md

+
+## 1) Understanding Lit PKPs as escrow
+
+A Private key is meant for signing transactions which are executed on the blockchain, a network verifies if the transaction is a legitimate one and then executes it. With Lit Network we can generate a special type of private keys which can be programmed to sign transactions only when certain conditions are met. With this, we can create several escrow mechanisms, and we will look into how we can execute a cross-chain swap.


i think we can abstract away some of these details here, they feel a bit excessive. I think we can just briefly introduce PKPs (like we do here https://developer.litprotocol.com/user-wallets/pkps/overview in the overview) and then say that for this use case we are going to use them as escrow accounts to support the cross chain swap flow

This was meant to give an overview of how we can "generally" use pkps for escrow-like cases and not only limit to defining pkps. As for bridging, messaging and swapping, the only thing that'll change will be the lit action.

I tried to make it use friendly but if it feels overwhelming, I can reduce it.

yea imo i think we can simplify things a bit. I think we should start by briefly introducing PKPs generally before honing in the specific use case of escrow

check below
30185e8#diff-0e36021eb2e9b13aa34e50ec77474d75d50bab8d18cba35c954841b81d9efee7R10

docs/additional-examples/evm-swap.md

a1ttech · 2024-08-22T20:41:25Z

docs/additional-examples/evm-swap.md

+
+Lit Actions are programmable code written in Javascript which can run on the LIT Network. We can program a Lit Action so that if certain permissions are met for a pkp, it must sign specific transactions that can be sent to the blockchain. We need to grant a Lit Action as a permitted action to the PKP to allow the Lit Action to generate signatures with it.
+
+We can create an escrow pkp in the following way (Mint/ Grant/ Burn)


We can create an escrow pkp in the following way (Mint/ Grant/ Burn)

Consider, "We can create a PKP "escrow" using the Mint/Grant/Burn [link to docs] method in the following way:"

with [link to docs] you mean the link to current page where the example resides or exactly what page of the docs?

i was referring to the docs on m/g/b, but i realize that we don't have dedicated docs for this rn

lmk, i can shoot another pr for that as well

docs/additional-examples/evm-swap.md

a1ttech · 2024-08-22T20:52:06Z

docs/additional-examples/evm-swap.md

+
+If the swap conditions aren't met then the Lit Action execution shall revert the funds to their depositors.
+
+### Architecture for Mint/Grant/Burn


I think we should title this "Complete Swap Architecture"

The diagram depicts how the general m/g/b function and lit actions built through it works. This should be the general flow of any such scenario as swap, messaging, bridging etc.

Swap definition is provided in the lit action

docs/additional-examples/evm-swap.md

a1ttech · 2024-08-22T21:16:27Z

docs/additional-examples/evm-swap.md

+
+You can find a generator which takes the above params to generate a Lit Action for swap: [swapActionGenerator.js](https://github.com/anshss/lit-evm-swap/blob/main/lit/swapActionGenerator.js)
+
+Remember, once a Mint/Grant/Burn PKP is created, anyone can execute the Lit Action on the Lit Network. This execution needs to define the parameters needed by the Lit Action to run. While generating a sign or checking conditions on the action, we need information around the pkp for which we are doing it. Due to this, we need to construct our Lit Action in a way that works with any PKP.


Remember, once a Mint/Grant/Burn PKP is created, anyone can execute the Lit Action on the Lit Network. This execution needs to define the parameters needed by the Lit Action to run. While generating a sign or checking conditions on the action, we need information around the pkp for which we are doing it. Due to this, we need to construct our Lit Action in a way that works with any PKP.

Do we need to include this info here? Also, anyone could technically 'call' it, but wouldn't it depend on where the publisher stored it in the first place?

for a m/g/b function on the contracts or while simulating its approach like this example, we need to pass the cid for action in both the ways which makes a lit action an immutable piece of code. This makes it independent of the storage provider as anyway on using ipfs or arweave, your lit action would be immutable and visible to all.

As a specific session signature is not needed to just run a lit action on lit network, we need to construct our lit action in a way that it doesn't hardcode or depend on a specific pkp (in order, need to first construct the lit action and will then mint a pkp). This works like a wallet being created, then you fund the wallet, run the only action that can make a wallet create a sign, and get transactions as per conditions.

The above info describes the nature of the action where an action is independent of the pkp data and made to run for a specific pkp. We can definitely short this information.

We could make it to where a valid Auth Sig from either Alice or Bob has to be provided in order for the LA to execute, but not sure if it's worth adding this complexity to this example

Either way, I find the paragraph a bit confusing

a1ttech · 2024-08-22T21:17:34Z

docs/additional-examples/evm-swap.md

+
+Our Lit Action primarily focuses on three factors:
+
+- Access Conditions for checking funds on both chains


are these access control conditions?

yes, renaming them to "access control conditions"

docs/additional-examples/evm-swap.md

spacesailor24 · 2024-09-04T06:33:20Z

docs/additional-examples/evm-swap.md

+let chainATransaction = {
+    to: "0xad50f302a957C165d865eD398fC3ca5A5A2cDA85",
+    gasLimit: "60000",
+    from: "0x291B0E3aA139b2bC9Ebd92168575b5c6bAD5236C",


I think you could just omit this property. We don't usually specify the from property in an ETH transaction since it's derived from the signature

spacesailor24 · 2024-09-04T06:36:25Z

docs/additional-examples/evm-swap.md

+    const chainACondition = {"conditionType":"evmBasic","contractAddress":"0xad50f302a957C165d865eD398fC3ca5A5A2cDA85","standardContractType":"ERC20","chain":"baseSepolia","method":"balanceOf","parameters":["address"],"returnValueTest":{"comparator":">=","value":"4000000000000000000"}}
+    const chainBCondition = {"conditionType":"evmBasic","contractAddress":"0x2dcA1a80c89c81C37efa7b401e2d20c1ED99C72F","standardContractType":"ERC20","chain":"yellowstone","method":"balanceOf","parameters":["address"],"returnValueTest":{"comparator":">=","value":"8000000000000000000"}}
+    let chainATransaction = {"to":"0xad50f302a957C165d865eD398fC3ca5A5A2cDA85","gasLimit":"60000","from":"0x48e6a467852Fa29710AaaCDB275F85db4Fa420eB","data":"0xa9059cbb000000000000000000000000291b0e3aa139b2bc9ebd92168575b5c6bad5236c0000000000000000000000000000000000000000000000003782dace9d900000","type":2}
+    let chainBTransaction = {"to":"0x2dcA1a80c89c81C37efa7b401e2d20c1ED99C72F","gasLimit":"60000","from":"0x291B0E3aA139b2bC9Ebd92168575b5c6bAD5236C","data":"0xa9059cbb00000000000000000000000048e6a467852fa29710aaacdb275f85db4fa420eb0000000000000000000000000000000000000000000000006f05b59d3b200000","type":2}
+    let chainAClawbackTransaction = {"to":"0xad50f302a957C165d865eD398fC3ca5A5A2cDA85","gasLimit":"60000","from":"0x48e6a467852Fa29710AaaCDB275F85db4Fa420eB","data":"0xa9059cbb00000000000000000000000048e6a467852fa29710aaacdb275f85db4fa420eb0000000000000000000000000000000000000000000000003782dace9d900000","type":2}
+    let chainBClawbackTransaction = {"to":"0x2dcA1a80c89c81C37efa7b401e2d20c1ED99C72F","gasLimit":"60000","from":"0x291B0E3aA139b2bC9Ebd92168575b5c6bAD5236C","data":"0xa9059cbb000000000000000000000000291b0e3aa139b2bc9ebd92168575b5c6bad5236c0000000000000000000000000000000000000000000000006f05b59d3b200000","type":2}


Wouldn't we want to pass these in as a parameter to the LA? This way the LA could be reused by anyone for swaps

Passing these as a parameter to the la would disrupt the meaning of "trustless swap" being offered by lit protocol as the action could then be ran with wrong values at runtime as well

I've made a separate la generator script where you pass a simple set of swap parameters and it will return you a swap la, have mentioned that in the docs
my flow is to pass simple set of swap parameter like

const chainAParams = { from: "0x48e6a467852Fa29710AaaCDB275F85db4Fa420eB", to: "0x291B0E3aA139b2bC9Ebd92168575b5c6bAD5236C", tokenAddress: "0xad50f302a957C165d865eD398fC3ca5A5A2cDA85", chain: "baseSepolia", amount: "4", decimals: 18, chainId: 84532, }; const chainBParams = { from: "0x291B0E3aA139b2bC9Ebd92168575b5c6bAD5236C", to: "0x48e6a467852Fa29710AaaCDB275F85db4Fa420eB", tokenAddress: "0x2dcA1a80c89c81C37efa7b401e2d20c1ED99C72F", chain: "yellowstone", amount: "8", decimals: 18, chainId: 175188, };

to swapGenerator, then that cook you a la

spacesailor24 · 2024-09-04T06:37:30Z

docs/additional-examples/evm-swap.md

+    let chainAClawbackTransaction = {"to":"0xad50f302a957C165d865eD398fC3ca5A5A2cDA85","gasLimit":"60000","from":"0x48e6a467852Fa29710AaaCDB275F85db4Fa420eB","data":"0xa9059cbb00000000000000000000000048e6a467852fa29710aaacdb275f85db4fa420eb0000000000000000000000000000000000000000000000003782dace9d900000","type":2}
+    let chainBClawbackTransaction = {"to":"0x2dcA1a80c89c81C37efa7b401e2d20c1ED99C72F","gasLimit":"60000","from":"0x291B0E3aA139b2bC9Ebd92168575b5c6bAD5236C","data":"0xa9059cbb000000000000000000000000291b0e3aa139b2bc9ebd92168575b5c6bad5236c0000000000000000000000000000000000000000000000006f05b59d3b200000","type":2}
+
+    chainATransaction.from = chainBTransaction.from = pkpAddress;


Don't think this is necessary either?

docs/additional-examples/evm-swap.md

spacesailor24 · 2024-09-04T06:47:43Z

docs/additional-examples/evm-swap.md

+```js
+async function getWalletA() {
+    const provider = new ethers.providers.JsonRpcProvider(
+        `https://yellowstone-rpc.litprotocol.com/`


Suggested change

`https://yellowstone-rpc.litprotocol.com/`

LIT_RPC.CHRONICLE_YELLOWSTONE

docs/additional-examples/evm-swap.md

spacesailor24 · 2024-09-04T06:54:56Z

docs/additional-examples/evm-swap.md

+            true,
+            {
+                value: pkpMintCost,
+                maxFeePerGas: ethers.BigNumber.from("1800000000"),


I don't think this property is required?

my transaction was failing so I had to configure the gases manually

Co-authored-by: Wyatt Barnes <[email protected]>

anshss added 2 commits August 22, 2024 14:18

feat: evm-swap example

e1a8353

Merge branch 'LIT-Protocol:main' into evmswap

6eb0c46

anshss requested a review from a1ttech August 22, 2024 08:54

a1ttech reviewed Aug 22, 2024

View reviewed changes