EVM RPC (Arbitrum): NonceTooLow on successful transaction

Developers
1

I am getting an error when making transactions on Arbitrum through the EVM RPC:

MultiSendRawTransaction: Consistent(Ok(NonceTooLow))

The error would have made sense … if it was correct. But, in my case, when I head over to arbiscan, the transaction is there and successful.

Example:

  1. Get nonce by querying eth_getTransactionCount that in this case returns a 4.
  2. Create the transactions with that nonce, here is what I log:
  contract_address: 0xbD75f629A22Dc1ceD33dDA0b68c546A1c035c458, 
  function_name: attest, 
  args: ..., 
  gas: 273_911, 
  max_fee_per_gas: 10_000_000, 
  max_priority_fee_per_gas: Some(Nat(1000000)), 
  nonce: 4
  1. Call fails with the above message
  2. Checking arbiscan, transaction is there: Arbitrum One Transaction Hash (Txhash) Details | Arbitrum One

Any ideas @rvanasa?

I am only having issues on Arbitrum, same code runs without problems on Optimism, Sepolia and Base. Tried both Ankr and BlockPi.

2

Hi @kristofer, thanks for reaching out about this. Returning the expected transaction status is not always possible depending on the implementation of the third-party API. With 28 requests happening in parallel, it’s possible that only one response will contain the successful transaction while the rest will indicate that the transaction has already been submitted (NonceTooLow). In other cases, all of the responses can indicate a successful transaction. Whether this happens depends on the implementation of the JSON-RPC API, so we relay whatever is returned from the HTTP outcall consensus.

It’s possible to design around this, e.g. calling eth_getTransactionReceipt to verify a transaction with a NonceTooLow response if necessary.

Have you tried using your deduplicating proxy server as a workaround (link for other readers)? It should fix the issue described above, at least in principle.

3

Yeah, what you describe is most likely the scenario, thanks.

I will bring the proxy back to life. :+1:

1 Like
4

@rvanasa

Can confirm that solved the issues I was having. With the added benefit of now being able to add any EVM chain supported by Alchemy. :boom:

Updated the RPC Proxy slightly to be more generic.

For reference if someone stumbles upon similar issues, this is how you configure the EVM RPC canister with the proxy as a custom provider.

let base_url = "https://<proxy-url-on-cludflare>.workers.dev";

// For ETH Sepolia
let rpc_services = RpcServices::Custom {
  chainId: 11155111,
  services: vec![RpcApi {
    url: format!("{}/{}", base_url, "eth-sepolia"),
    headers: None,
  }],
},
1 Like
5

That is great to hear! I opened a PR which updates the documentation and includes a link to the C-ATTS proxy server for better discoverability. Let me know if you’re ok with this being included in the docs. Cheers!