Sequence mismatch. Got 1 from device. Expected 0

[AmesCornish]

Component

Forge

Have you ensured that all of these are up to date?

• [X] Foundry
• [X] Foundryup

What version of Foundry are you on?

forge 0.2.0 (084ef3d 2022-09-19T00:07:01.878472846Z)

What command(s) is the bug in?

script

Operating System

Linux

Describe the bug

I'm getting this error when trying to broadcast a transaction to mainnet using a ledger. The command is:

forge script script/MyScript.s.sol --broadcast --ledger

I had one transaction with a different script work this way, but this one succeeded in the dry run just fine, I approved it in the ledger just fine, but then I get the following output with a warning:

...
Script ran successfully.

==========================

Estimated total gas used for script: 174237

Estimated amount required: 0.002697348679248762 ETH

==========================

###
Finding wallets for all the necessary addresses...
##
Sending transactions [0 - 0].

Transactions saved to: /home/.../MyScript.s.sol/1/run-latest.json

Error: 
Sequence mismatch. Got 1 from device. Expected 0

At first I thought this might be a nonce error, but the on-chain nonce is 3, so that doesn't fit.

What is this "sequence" of which it speaks? Any pointers would be appreciated!

[gakonst]

Is this error still around? Did you try replugging the ledger?

[AmesCornish]

Yes, I kept getting the error, after replugging and restarting the ledger several times. As a note, I saw a similar issue trying to connect my Ledger to Metamask, through I then connected it to the Coinbase wallet without issue. I suspect there's some protocol version incompatibility between the ledger and whatever client library you're using on linux.

[mattsse]

cc @joshieDo

[gakonst]

cc @prestwich re: Ledger, has there been any change recently?

[prestwich]

error originates here during APDU response payload header parsing: https://github.com/summa-tx/bitcoins-rs/blob/c6fdb4cc6b2c8779d1e71c7046ff3eec6dcf61e1/ledger/src/transports/hid.rs#L259-L264

no change to the lib for a couple months. The sequence mismatch (got 0 expected 1) would indicate one of

• malformed response (possibly do to malformed request)
• some channel id weirdness that we're not handling correctly
• non-exclusive access to the device (multiple futures trying to use it at the same time?)
• sequence int rolls over (very large tx, more than ~256 * 60 bytes)

Documentation of the sequence system for large blob txns https://github.com/LedgerHQ/app-ethereum/blob/develop/doc/ethapp.asc#transport-protocol

Are you running ledger live or any other ledger-using application at the same time you're running the script?

[joshieDo]

non-exclusive access to the device (multiple futures trying to use it at the same time?)

Leaning towards this.

I don't have access to a ledger anymore, but I remember seeing some recent changes to how we instantiate wallets in the beginning. May be a resurgence of this https://github.com/gakonst/ethers-rs/issues/1602 / https://github.com/foundry-rs/foundry/pull/2790 - although i remember the error being different at the time.

edit: https://github.com/foundry-rs/foundry/pull/3047 recent changes i mentioned

[AmesCornish]

malformed response (possibly do to malformed request)

maybe?

some channel id weirdness that we're not handling correctly

maybe?

non-exclusive access to the device (multiple futures trying to use it at the same time?)

I was careful to close down Ledger Live and unconnect/reconnect the ledger, and clean the forge cache. Didn't help.

sequence int rolls over (very large tx, more than ~256 * 60 bytes)

The error started with a two-transaction script. The first (small) transaction succeeded, and the second repeatedly failed after approval on the ledger. The second transaction was big-ger, but still only about 256 bytes of calldata. I also tried re-doing the script to only broadcast the second transaction, but it still failed.

I'll try to post a redacted broadcast record to help debugging...

[prestwich]

second repeatedly failed after approval on the ledger

this would seem to rule out the large payload, as the response payload from the ledger sign is small

[prestwich]

I don't have much time to work on this. but if someone wants to add tracing to the underlying ledger lib.....? :)

[AmesCornish]

Bump. This is still happening with latest foundryup.

[prestwich]

@gakonst I'm pretty sure this is related to running multiple signing processes at once

[zerosnacks]

Hi @AmesCornish,

Would be great if you could check again, we've since moved to Alloy and a bug related to the kb size of the contract suite being deployed was fixed: https://github.com/foundry-rs/foundry/issues/6516#issuecomment-2049201534

[zerosnacks]

Tentatively marking as resolved

Feel free to re-open if you are still facing issues around this @AmesCornish