POWDone

The front-end allows users to sign in with gmail utilising LIT protocol account abstraction, this mints a proxy for a wallet that the user has without having to actually onboard web3, nor do they need to know. This is important because the best strategy for onboarding web2 users is not to mention blockchain related terminology unfortunately. Then, the goal description, deadline, stake amount and verification method are selected. These are non-trivial parameters and users will be notified to think carefully when defining them.

The flow from here depends on the verification method. Let’s assume the user has selected a goal whereby a counter increments with every instance of activity related to the goal. That counter exists as an API endpoint saved on IPFS through an Infura end-point. When this goal is set by the user several things occur. Keep in mind that this would be an example of a public goal that anyone can verify.

First, the IPFS hash is read and assigned to the PKP that is being minted and populated with all the goal parameters. This PKP utilises the decentralised private key to sign any transactions, therefore if the Lit Action is called, it will only be executed if this particular PKP is connected.

The interesting step from here and the power of LIT protocol is that a burn and grant process occurs now to the PKP, all abstracted away from the user of course. The PKP has a public key associated to the decentralised private key held on all the LIT nodes, this pair in-turn is associated with the wallet the user created, meaning the user wallet can only initiate transactions signed by that PKP. This association can be severed and instead, replaced with the hash of the IPFS file, meaning that the code defining the activity progression can only use the specific PKP to sign transactions.

The consequences of this is that anyone calling the Lit Action can cause the transaction to be signed, but only by the particular PKP minted by the goal declaration. Meaning all calls of the Lit action, irrespective of their origin, all cause a state change on the smart contract that tracks the goal progression for the specific user and their specific goal. In this way, a similar technology to a POAP is achieved.

Now let’s assume the goal is shared amongst a group, an accountability group. In this case, the difference in the flow is that instead of a Mint-Burn-Grant and associating the IPFS hash to the PKP, we associate certain users to call the Lit Action and only then dissociate the original wallet. This is a common verification method used by goal tracking applications, this is the supervisor selection method.

Stack: nextjs tailwindcss shadcn ui bun js runtime aws hardhat

Lit protocol is used as a authentication method. The whole application is powered by lit, UMA is another verification method. Arbritrum and Scroll are used to store the goal hash which is IPFS. Filecoin is be used to pin IPFS file.

Lit Helper

PKP Ethers Wallet Fixes: Added call method to pkp ethers wallet to execute contract calls through pkps Utility to populate tx when using pkp to call contract methods. usage in mintgrantburn Tests Browser setTask flow fetchTasks flow markDone flow (unable to test) [] verify Node.js test script setTask tested fetchTasks tested markDone tested verify signature against stored ipfs hash tested

Uma as a verification method: https://github.com/Podima2/POWDoneProtocol/blob/3d6a4b02871f2af626569e137c5b3cf94b33ff00/services/3033-smart-contracts/packages/hardhat/contracts/PowDoneGoal.sol#L168

Scroll and Arbitrum to store goals and FileCoin as IPFS pinning service