Ethereum engineering puzzle 🧩 You're writing a backend service that has to submit transactions to the chain using an in-memory private key. You might need to submit multiple transactions on the same block, and retry them if they don't land. Pause here — do you already see an issue? Do you know how your tx management library of choice handles nonces? Out of 6 people I interviewed for a position where we'll have do to this kind of tx management, not one knew the answer. I don't blame them, because I didn't know either. So I tried to find out the answer for Viem from @wevm_dev (because it's the tool I know best / have used — alternatives for such a task are Ethers.js, Ethers-rs, Alloy and the geth libraries, as well as Thirdweb engine). It's surprisingly difficult — the codebase has many indirections which stem from the need to support many different chains as well as multiple types of transport. There are also two ways to send transaction (prepareTransactionRequest + signTransaction + sendRawTransaction VS sendTransaction). I tried to find the default logic, assuming there is no chain-specific coding. Surprisingly it seems that by default, you HAVE to specify a nonce if using sendTransaction (caveat 1: there's a special case for local chains where it will use the prepareTransactionRequest path instead, caveat 2: I might have been lost in the sauce and missed something). If using prepareTransactionRequest, the nonce is obtained by calling the RPC method eth_getTransactionCount with the block tag set to "pending". What this does is not very well documented, but I found a merged geth PR that shows that on geth at least it will give you the nonce after accounting for the transactions currently in the mempool. (Btw, do you know your "EVM-equivalent chain" works the same way? Try asking your devrel 🙃 Most likely if they use a fork of geth to manage the mempool it works the same, otherwise ... 🤷‍♂️This is why equivalence is hard, the devil is always in the details. I suspect a ton of work that the good Viem devs do is papering over tricky differences like this for different chains.) So back to our issue. If I'm sending 2 transactions in rapid succession, they're liable to be fired with the same nonce, and only one of those will succeed (anyone's best guess which that is — since they will most likely specify the same basefee). So you *must* manage nonces explicitly. If I'm sending two transaction with a little bit more spacing (say one block is produced in between), you can run into another issue: the first transaction might not be included because its basefee is too low (or because the block is full). If the basefee increases past the one it specifies, it could stay stuck in the mempool for a long time. In Viem, this will cause waitForTransactionReceipt to timeout (this is configurable). You either need to resubmit the transaction with a higher fee or modify the second transaction so it can execute. Of course, nothing is so simple: because all the transactions are still in the mempool, eth_getTransactionCount({ blocktag: "pending" }) will return a much higher number. Once again, explicit nonce management is necessary. Even worse: if you wanted to drop the timed out transaction (tx 1) altogether, you will need to make sure to cancel the previous version of tx 2. Otherwise it will execute twice in a row, since the previous version (with the next nonce) is still in the mempool. This leads us to another excellent interview question: how do you cancel a pending transaction in Ethereum? Short answer is you can't. You must replace it with another transaction with the same nonce but a higher basefee. If you don't have anything meaningful you want to do, replace it with a no-op (e.g. 0 ETH self-transfer). This is still a proper transaction that will execute — which is why it costs gas when you try to cancel a transaction in metamask. So tl;dr — if you're sending transactions from the backend, you need explicit nonce management. Also probably you should use @thirdweb engine (github.com/thirdweb-dev/engi…) which is actually designed to solve exactly these problems. Are there any other tools or libraries like this?

@⁠wagmi/svelte after 🤝