Hi everyone, I’ve been spending a lot of time testing various dApps on the Arbitrum One and Nova networks lately, and I’m running into a consistent issue with RPC responsiveness when my mobile device is under heavy load. While Arbitrum is significantly faster than L1, I’ve noticed that the finality in the wallet UI seems to hang if there is any other major background activity on the phone.
I’ve been experimenting with some blox scripts to see how high-frequency script execution impacts the ability of the browser-based wallet to maintain a stable WebSocket connection to the sequencer. It seems that once the background execution ramps up, the gas estimation fails or the transaction “gas price” doesn’t update, leading to stuck nonces.
Has anyone else noticed their mobile wallet struggling to resolve RPC requests when the CPU is taxed by other background executors? I’m trying to figure out if this is an issue with the wallet’s provider priority or if I should be using a more aggressive polling interval for Arbitrum-based transactions when multitasking. I’d love to know if there are specific RPC endpoints that are more resilient to client-side resource contention so that our dApp users don’t face constant “transaction failed” errors while running other tools.
Thanks for any insights into how we can make the mobile L2 experience more robust during high-resource usage!