Working with ethers.js library requires you to store your private keys on a .env file. You will need to use tricks to secure them to automate transaction signing since the goal is to avoid signing each transaction manually as you could do using Metamask.
When it comes to broadcasting transactions simultaneously, you will probably face nonce issues such as ALREADY_KNOWN or NONCE_EXPIRED. To do so, you will have to create your own nonce manager, to track which nonce is already used, which ones are available to use, and track which transaction is on-chain.
Your transaction can be underpriced, meaning that it’s not picked up by the miners because the gas price offered is not attractive in the current market (see TRANSACTION_UNDERPRICED). When implementing a transaction replacement strategy, you can also face this error: REPLACEMENT_UNDERPRICED. Since the gas price demand evolved, the rates set up for a transaction can become insufficient when in need of replacement. But that’s not all. What if there is a bottleneck on-chain? What happens when your transactions are reverted because you didn't put enough gas compared to the current demand? To manage this, you have to develop a strategy to replace stuck transactions by increasing gas prices, and of course, consider how much you are willing to spend. And of course, this has to be managed along with the nonce issue.
Another major issue you can face is the mempool. Each node has its own mempool. When load balancers route your queries to a new node, it also means to a new mempool. Each node has its own mempool size. If you broadcast too many transactions with the same signer wallet, depending on the node you hit, some of your transactions will be lost by the mempool. When you want to retrieve pending transactions you must hit that specific node. To manage this, you need an off-chain strategy and rebroadcasting strategy to resend lost transactions and get insights on which transaction is mined or which isn’t.
Sometimes, it's simply a network issue. Either the network is experiencing an overload or the RPC node times out. Sometimes the RPC node responds to a new error you haven’t accounted for in error management, and the error logs are not located consistently among RPC providers preventing your script from fitting several EVM-blockchain protocols at the same time. To tackle this, you have to manage RPC node errors properly, add a strategy if nodes are timing out, and retry your broadcast when nodes aren't responding anymore.
Sign automatically your transactions. Use our vault plugin or your Key Management to prevent storing your private keys where you hold most of your assets
Assign nonces dynamically for each transaction to benefit from asynchronous broadcasting, and return available nonces when an issue is detected with the transaction.
Replace your transactions by increasing the gas price or assigning a new nonce. Monitor transaction status, and rebroadcast when necessary or fill your nonces gaps with empty transactions.
Get a clear gas price increase strategy for rebroadcasting, where you can set the highest fee limit.
Benefit from clear error responses, with clear documentation, avoiding you to deal with different RPC nodes client implementations.
Avoid the hassle of dealing with RPC server crashes, updates, maintenance and diverse errors messages.
Have an off-chain strategy to handle the mempool limited size and pending transactions, checking on already mined transactions to ensure that all your transactions will end on-chain.
Set your transaction with the level of control you need to broadcast your transactions in a certain order and keep consistency in your code when you’re an expert.
Starton Transaction Manager returns the status for your transactions so you can debug any issues or change your broadcasting strategy using clear logs.