 I work for Gloom and today I'm here discussing our Metatransaction Relayers. So what are Metatransactions? First, Metatransactions enable fundless key pairs to use smart contracts rather than spending gas. They sign their intended action at using their private key and then a relay or broadcast is on their behalf and pays the associated fees. So at Gloom in the past year we've submitted over 250,000 Metatransactions on mainnet. Sometimes it has 6,000 Metatransactions in a single day. During this time we were spending up to 1 to 3 ETH per day just to keep our Metatransaction Relayers going. This has to do with like identity credential issuance. So what we learned pretty early on is that simply broadcasting the transactions does not scale. You can't just call Web3.Send or Web3.SmaGas and hope that it's going to work. Confirmation times are long and they're inconsistent. Gas prices can be volatile and there are frequently chain reorg switch drop transactions. So the first thing that we encoded into this service which handles very high volume of transactions is nonce forecasting. So in the simple case on the left you can see that we broadcast one transaction with nonce 1001 and everything else is blocked. So they can't all be mined in the same block. Instead what you can do is use the nonce field of send transaction so that you can do 1001 through 1005 and you can have all of these happen in the same block without waiting for mining. When there is a nonce blocking the next one so if we're waiting for 1002 to mine we need to aggressively re-broadcast that transaction with a higher gas price until it goes through. So this happens in the service every 30 seconds it re-broadcasts with a .1 blame higher gas price in order to force it through so that every other transaction is no longer blocked. We found that on average each transaction needed to be broadcast twice to go through. So I set up this in Elastic Stack when I looked in the morning this looked healthy to me. There were transactions being created on the bottom and then they were being committed or re-broadcast on the top. Gas prices sometimes spike very high but it's important to set a cap and wait it out because gas prices are volatile but if we filter out everything above 100 way it's actually pretty consistent so if you were spending you know maybe somebody had some arbitrage opportunity way back in February you didn't want to be competing with them for gas just wait a little bit and then you can get your transaction through. Our actual spending ended up being far less than the average but we still had very high through but also during when the network is very congested mining will sometimes lag by many hours and you might be concerned that it'll never catch up but as soon as the network congestion goes away the backlog clears and then you're broadcasting at mining times get much closer together. One last thing that you also should look for is chain rewards so if first you think that something was mined but later your transactions are not being broadcast you should go back and look at the most recent transactions see if it was dropped and then you can either fill it with a dummy transaction is your value transaction or you can actually go back and re-broadcast that one. So finally I just open sourced this about 10 minutes ago this is service that actually handles all this logic for you and it's very bloom specific now you actually have to encode a lot of the contract logic but I would love to try to get some other companies set up with this service it does a lot of it handles a lot of things that took us a while to figure out so please take a look I'm using PG Boss for the queuing it's all tight-stripped so we use type chain for contract typings check it out and I'd really like to help you with it thanks.