Practical Meta-Transactions | Zac L, Suberra | ETHTaipei 2023

just to have a gauge on an audience who heard of meta transactions before that's what I know about metadata transactions so it's a key concept behind enabling guestless experience for your users my name is Zach I'm the CTO of superior protocol we are payments company and we altered the EIP 5827 which allows users to satisfy spending limits on the eic20 tokens so just a quick introduction of super protocol our goal is to allow anyone to accept crypto payments for anywhere for anything so our first product is actually a crypto payments checkout so in this example you are able to pay for telegram premium on a recurring basis with our checkout page so every three months we'll be charging your eoa wallet for 15 usdc so this is the agenda for today we'll be talking about meta transactions and the general approaches to enabling this experience for your users and we'll look at some examples of how you enable gasoline reactions we believe that the future of webtree apps should rival the current web 2 Technologies so users should be able to onboard your app without knowing that it's web tree and to enable that the first step is to solve a ux experience for your user so how do you enable the initial guest payments to be guest list so this is a typical example of a user trying to transfer usdc to a to a recipient so you want to transfer one usdc to LS in this in this example but what if Bob doesn't have any if on his wallet right so to answer this you need to look at what is a typical transaction on chain so this is a raw eip1559 transaction on chain so you can see here like there's guest limits there's uh the fee that you pay and the first field here is Bob eoa wallet so the address of Bob is specified here and the two the two field is actually the usdc contract and the data here specifies the functioning around the call so in this case it's transfer the recipient and the amount you want to transfer and the last part here is the signature that verifies that TX is actually from Bob so if you want to pay gaslessly we can't bypass the gas limit here and the guest fees here on the on on the validators so to achieve this this is a meta connection The Front Field change here to a relayer third-party relayer wallet the two two field here is actually a T8 meta TX compliant contract and the data here actually is a wrapped um function where Bob signature is actually specified inside the cloud data and lastly the signature here is just the relay signature it could be any wallet that has ability to send transaction on chain so this is a example of the meta TX that I showed us now so Bob will actually sign a manual transaction and relay it to a third-party user you can send this meta TX via API call or send it a via QR code for example then Charlie here would send this on chain and pay for gas on behalf of Bob and once usdc contract receives this and you will transfer the funds to Alice so in summary Mina txr off chain sign wrap transactions that is submitted to the network by a third party layer the signature of verification is now handled by the smart contract itself and fee payments and sponsorship logic is in the off chain or by the contract itself and the traditional color identification is not changed instead of message that are sender the contract has to determine who is the original sender so there are three main General approaches to enabling this first is a standard eip2771 it's a way of identifying who's the actual sender and verifying the signature on chain and there are various uh second one is custom implementations these are non-standard ways of enabling this system so some examples are our protocol and like uscc contract they enable this and lastly we have contract wallets so contract wallets enable additional logic to be embedded inside the wallet itself so we can we can code in some logic to verify signatures and so on okay so our first example is actually eip2001 so it specifies a way of white listing a trusted forwarder this forwarder verifies the signature that is being sent to the contract check that the non-articipating is not being used before this is to prevent replay attacks and lastly it appends the original color address to the end of your call data right then on the Target contract there's some modification to be made it has to trust a single forwarder so he has to whitelist a particular address that it trusts as a as a verification contract lastly it has to decode the caller if it's sent from this particular folder to decode the actual original sender so examples of this is like gns here's your guest Network station and the economy relay and relato so this the advantage of this approach is that there's minimal modification on the Target contract and but it relies on a single folder implementation so you can easily switch different implementations out next I'll go through some examples of a custom implementation so this is why we use uh behind the scene at subera so we follow like the economy Marathi extended what it does essentially is move the forwarder contract into the same contract as a Target contract so the Target contract now verifies the signature and make sure that replay attacks are mitigated and it appends the core data the caller address into the call itself and at the same time we also call decode a caller if it's sent by itself right so this approach is flexible it's pretty use case specific but there's lots of modification on the contract itself so some examples um like we have our own EIP implementation that uses this usdc on polygon uses this as well gelato relayer some implementations does it as well next uh is a second custom implementation this is used by like one inch Fusion they have a mix of off chain and on-chain verification so you send yours like limit order to the centralized system which verifies signature then the network of resolvers actually resolve your limit orders and send it to the Target contract so the white list a set of trusted workers that can can call this function then um at the same time they decoded uh the custom parameters like gas limits uh in their own ways so this is pretty much broad based you can use this for any use case but sometimes it depends on like a centralized uh security of change security lastly we have contract wallets one major popular use case right now is AA wallets so a wallets sense essentially meta connection as user operations so your user operations are actually mineral transactions itself so uh Bob in this case it signs its own user operations then submitted to the AAA mempool then your bundlers will actually validate this and submit a bundle of operations to the 437 entry point and this entry point here were validated with the paymaster to check whether there's any sponsorship of your guest payments if so you will you will pay for the guests on behalf of the user then call the execute function on your a wallet then in this case transfer event will be sent to the usdt contract which doesn't support meta transaction in this case but it's still be able to transfer gaslessly because the major advantage of contract wallets is that the Target contract needs no modification so you can interact with existing contracts that never Implement any Manatee code before but the downside of this is the user has to migrate over from an eoi wallet to a contract wallet right so in summary the key changes are firstly is you have to implement some management controls you do not want to sponsor everyone's guests um you have to specify like white listing of users or contracts you have some sponsorship control and logic behind it this can be off chain or on chain next is if you choose the first two approaches which is the custom approach or the EIP 2771 approach you have to change your Target contract to recognize the original sender and this is typically possible by replacing your message data sender with a custom function called message underscore message sender right then thirdly is guest payments there's various logic behind guest payments one of them is whether it's synchronous or async so synchronous means that every transaction is paid on the spot in the same transaction or async is like a post-paid mechanism where every few months every month you pay at the end of the of the billing cycle lastly the smart contract has to verify the signature handled by a smart contracts so a popular option is to use the eip712 where the user can actually read on your metamask while actually you're assigning so lastly if you want to enable gasless connection these are some Services you can actually use so the economy is one of the popular ones where they have a simplified SDK for user to onboard either via a wallet or like eip2771 gelato here is a second option where you can automate various contract calls and they have a unified guest payment where you can pay for gas on one network for alternation on other network and gns is actually a decentralized version of a really a network where different relayers fight to sponsor your guest reaction and this enables a completely decent utilized solution if your application requires it lastly this is what we use at subera open Zeppelin it's pretty it's just a managed relayer wallet that is controlled via API so we can actually just trigger a transaction on Chain by the API so how do we use this in Superior right this is our checkout page we first require the user to sign a erc20 permit this is to enable spending on of usdc allowance next one is the user sign a permit we actually batch a multi-call operation where we send the permit and then a meta TX approval on our EIP 5827 so approved renewable allowance and pay for the product lastly we send this over to open sapling Defender which relay our connection on chain and pay for gas at the same time we as subera aims to enable crypto payments anywhere for anything we actually introducing our Superior accounts which is a non-custodial AA wallet that enables or gasless payments anywhere for any contracts down the line first start we are actually launching our super air card which enables uh you to spend directly from your EA wallet for anything anywhere so this is a non-cut studio account uh similar to a debit card model where you find your EA wallet and you can spend it through a credit card Network and that's all for my presentation and this is our wait list for the card so do sign up we are launching in Q3 we are very excited for this it's one of the first non-card Studio crypto card you can have and this is my contact information if you have any questions about Metatron actions or payments do find me and thank you [Applause] so this will be of the talks in the morning uh we will take a break and come back around like 1pm more talks coming thank you [Music]