Devnet serves account state for only ~50 blocks; anchored multisig transactions die within minutes

[haseebrabbani]

Observation

GetAccount at AccountStateAt::Block(n) against rpc.devnet.miden.io (2026-09-08) succeeds for n = tip - 50 and fails for n = tip - 52 and older with Client specified an invalid argument: block N has been pruned. At roughly 3 s per block that is about 2.5 minutes of account history.

Why it matters

Since protocol 0.16 a signed transaction summary binds its reference block, so multi-party flows execute at a captured ChainAnchor rather than the tip. Every fee-paying transaction loads the fee faucet as a foreign account (the kernel's asset callbacks), and miden-client fetches foreign accounts at the reference block. So any transaction that has to be signed by several parties, verified, and then executed must complete within the retention window, or it can never be executed and its signed summary can no longer be reproduced by anyone. For OpenZeppelin Guardian multisig proposals that is the normal case: OpenZeppelin/guardian#462.

The client-side fix, shipping the foreign-account inputs with the anchor, is requested in 0xMiden/rust-sdk#2524. Independently of that, a retention window measured in minutes makes the public devnet unusable for any offline or multi-party signing flow.

Request

• Document the retention policy for devnet and testnet (blocks or time), and expose it, e.g. via the status endpoint, so clients can warn before an anchor ages out.
• Raise the public networks' retention to hours rather than minutes, or make it configurable per deployment with a documented default.

[partylikeits1983]

Protocol 0.17 supports separate signing and execution blocks, but fee paying multisigs still depend on the execution block through the fee note. I opened protocol #3836 to address this.

Once fixed and integrated into Guardian, this should allow execution against newer state without requiring the node to retain historical account state throughout signature collection. Increasing retention would still help the current flow as a temporary mitigation.

[Mirko-von-Leipzig]

Pragmatically speaking, we can't retain that state for that many blocks (i.e. thousands) without a severe performance penalty.

[bobbinth]

This won't be an issue in v0.17 release (we don't need to execute multisig transactions against an old block) and @igamigo is looking into a potential simple fix that can be done on the client side.

[igamigo]

Documenting the limits somewhere is probably a good idea.

This won't be an issue in v0.17 release (we don't need to execute multisig transactions against an old block) and @igamigo is looking into a potential simple fix that can be done on the client side.

I added a way to pass pre-fetched AccountInputs to a TransactionRequest (0xMiden/rust-sdk#2527). I think this may be useful in any case. The main problem is that it's hard to capture AccountInputs after having errored out with Unauthorized (which is what the guardian does), so for now the responsibility is fully on the user to load the correct inputs, with any potential map and vault keys that could be used. I think this would be fine for most usecases (Guardian included), but it's something to keep in mind.
If we wanted something more "automatic", we'd ideally instrument the executor to return these inputs after having executed and errored out with Unauthorized.