Pectra’s Impact on Peer-to-Peer UX: A New Era for Decentralized Markets - Skas

Transcript

[Music] Hello everybody. Thank you for the warm introduction. Um well as it was said uh this talk about going to be primarily about upgrade and how it reshaped peer-to-peer UX and especially POM protocol. I'm going to be talking about that very briefly. Uh first I'd like to introduce myself. Uh I came from the nursing background. um finished my nursing school then I get to work in fintech for a couple of years and then I switched to be a D5 builder. Uh my take is that future of the D5 is purely endgame actually of the D5 is going to be

peer-to-peer. Um and I'll probably die on this hill. Uh before we dive deep, I will try to take 30 seconds to explain what the pawn is. Um essentially we have lenders and borrowers meeting together on the platform to settle on their own terms and uh figuring out what's the interest going to be, what's the duration of the loan and what assets are being used. That's pretty much everything we need to know about this. Uh we'll now compare this with peer-to-pool solutions. Uh kind of more popular ones. Uh just as I said direct mesh between borrowers and lenders um happening uh on our side in a peer-to-peer protocol for peer um for pools people interacting with smart

contracts representing the pool um on the peer-to-peer side we have a full terms customization on the peer-to-pool model it's algorithmically determined um UX for peer-to-peer is also can be quite slow as uh we need some matching process to happen for peer-to-pool It's very fast. Just few clicks, you immediately borrow or lend liquidity. Um that's pretty much everything we would need to understand at this point on the difference. And um from the definition, we can also imply the fact that they will be multiple peers uh potentially in every deal. So it's like one lender providing liquidity and there is multiple borrowers on the other side

borrowing it or uh other way around. Oh, it messed up a little bit, but it should not be a big deal actually. Okay, let's check that out as an example. So, we have a lender. Lender is going to lend 100 D from AVA directly and 400 USDC from Morpho against Rob teeth or Rob BTC at 75% LTV loan to value for 180 days and fixed 8% of interest. So UX- wise it will require at least two transactions for for issuing approvals two more for issuing approvals for pool adapter to be

able to spend the money. Then each and every existing offer from somebody else will be additional transaction once more. If there is previous offer that needs to be revoked plus one more transaction um and creation of the new uh new offers it's one more uh signed type message which represents the miracle tree of user intents. So with all of that uh I'll calculate it at least six steps plus n which could be any accepting existing offers and uh doing that for multisync will require u at least two times more signatures. So overviewing all the problems here um we have to issue infinite approvals to

reduce future traction of the user with the protocol which can look scary for some users. Um each pull hook that has been added requires additional approval. Merkelized intents um which I'm going to explain on the next slide is very hard to verify for the users and they have to be pretty technical to understand what they actually doing. Um state update uh somewhere in the middle may invalidate uh the latest transactions. Um it's very tricky to estimate the gas and as I said for multiscallets this UX came straight from hell. So here is how it actually looks like. To the left we can see message that user initially signs as

intense of terms. Uh in the middle we can see the miracle tree that I was previously mentioning. It's not really human readable. And to the right we can see the toast which includes all the user actions that needs to be sequentially executed to be able to provide the liquidity. Well, with uh Pectra hard fork, we are now able to batch user transactions together for any type of user accounts. Previously, it was possible for any account abstraction. And now it's also available for externally owned accounts like MetaMask or any wallet of your choice. And um this slide is a little bit uh messed up but important thing here is that the

same use case always results in the single transaction depending if user also wants to create uh additional offers and sign a message but we can actually move this part also on chain. Um here how it looks uh from the user perspective. Uh you just see the full preview of your transaction. Please notice that the gas is like less than three three cents pretty cheap. Um it also includes the user nons and just below they will be the full overview of all the actions that user is executing.

Pretty uh pretty easy. I would say it's hidden for some reason it's hidden for like under um detailed settings for developers. I don't know why I think everybody should be looking at those things and for uh creating additional offers uh user needs to sign the Merkel tree as I previously said. Uh so this is approximately how it looks. Um so the support for batching user actions together uh on the infrastructure level was actually added just in the 23rd of April which made it possible for us to start using almost right away and uh tested before the petra upgrades on the test nets. Um

it also kind of reshaped our understanding of user interactions that it's always going to be array of certain calls that would be executed usually with the length greater than one because if it's uh if length is equal one we'll probably just send the normal transaction. 77 delegation is the tricky part which may put user funds in risk and the greatest thing about that is that we don't even have to u manually do it and everything is handled for us by wallets.

um if we would be supporting any uh previous I would say implementations of batching user transactions together in some cases we would need to also wait for um like kind of I would say uh some state in the middle to finalize it later. Uh obviously we don't have to do that anymore. U as I already said sign type data still needs to be handled separately. So we cannot uh sign type data inside of the send calls uh by now. Um it's pretty cheap gas wise as I said also after your first delegation it's going to be half times cheaper on the each time and I also noticed that some of the providers are limiting calls to

the 10 for some reason. There is uh nothing about that in the specification but uh some of them do that. It might also change um in the future. So uh to address the previous problem that I was bringing with signing some not really understandable hash and understand what it what it is, we can also move or uh offer placing um directly on chain. In this case we would not need to store any of the user signatures anywhere. It will work natively for externally owned accounts and any account abstraction. It also makes data indexable by subgraphs. Um user would have to pay additional gas

for replacing those offers but thankfully it can also be sponsored and it's only safe to do for the proposals that are using onchain data aka oracles. Uh for the offchain price for the offchain creation of offers there are some benefits as well. Um I would say we can aggregate intents also across different chains and it doesn't have to be limited to a single one. Uh so it's pretty uh I would say good UX for the lenders or for the borrowers would like to expose themselves to multiple chains at once. Um in this case if you're doing offchain uh offer placement DAP needs to uh preserve the signature somehow. Uh but creating of off-chain offers allows

us to have the private or public uh placement of those offers and also the price is uh zero gas for sending the message only the approvals themselves. Uh here's some more screenshots of um how things uh actually look like. The first screenshot is the popup window that you can see in your wallet when you'll be uh asked if you would like to upgrade your account to smart account. Uh unfortunately you cannot see the delegation code here directly. Some of the other wallets that supported uh showing the code that is actually being deployed for you. Uh in the middle once more the overview of the user transactions together. And to the right is something that is u going to be

natively accessible as an example of safe wallet which uses account abstraction and everything that works for EOA automatically works uh with this solution as well. Um so as a recap now we can we don't have to issue infinite approvals anymore. We can issue the exact amount that user wants to want to transact the API or application programming interface that we are using for sending those action is shared between different implementations and users can actually see what they're signing which is a quite big problem which led to few problems historically. Um and now also each flow would rather be executed atomically or

returned as the list of user actions that would need to be uh handled by application and uh somehow rendered. U on the other hand there is obviously an adoption lag. Most of the wallets and users still haven't opt in. Uh may I ask uh to raise the hand if you already delegated your uh converted your EOA into smart account? How many people will be here? Okay, for the record, two hands. I see it pretty much reflects the data on that I'm going to be talking about in a in a few minutes. Uh and also quite important part is that we still must preserve a fallback for situations when something went wrong or user just don't want to

upgrade it um externally on the account. Um well also kind of good idea as we can be placing code directly to EOA why not to just make uh sideloadad our scripts into user account right no no no it's not how it was intended to be used um and the application must not expect that user will sign type data so it means that it's a potential improvement for somebody who would like to get their account um upgraded and in this case they will have a certain benefit methods and also it exposes certain risks. So do it on your own uh after your own research on this one. There's also QR code that you can sign and uh see the

same information on the EAP page. Um and also I got some statistics from um great dashboard from Vinterm about AP7702 adoption and uh 92% of the wallets only delegated to a single account. It means that it's those people who are probably safe. So they only delegated uh to the to the single account. It means that they probably using MetaMask and uh accepted their delegation. For anybody who will be using more than a single one, they are um almost exponentially increasing the risk of uh being drained at some point uh at the future.

Uh there is also a great resource that I just recently found. It's called Swiss knife 7702bit. Uh it was updated this morning and now there is the third wallet that also support supports 7702 which OKX wallet. Um not sure about the change though. I would need to go and check it out myself. So um let's review how to stay safe with uh kind of this new meta. Um, first make sure that you review any delegations that are happening. I I displayed the example of MetaMask and said that it's probably not a good thing that they're not showing uh what actually being happen what actually happening. And there is a great service that I discovered called scope.s s that allows you to see uh any delegations

that you uh created for every uh for every chain and also be able to delegate or uh call your account code directly from the service. Uh also try to stay in 92% it uh will increase your chances of being safe. Uh preview and simulate transactions using tenderly. um it might be slightly technically challenging to do but it will for sure will uh keep you safe in the future. There is also such things as wallet alerts and watchtower. If you're not familiar with them, check them out and set it up.

There is also onchain insurance that are partially covering 7702s and for sure don't wipe sign. Uh that's pretty much it from my side. So, you have a couple of minutes. I'll be able to answer your questions. [Music] [Applause] [Music]