0xMiden / 0xMiden/node

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

Open
#2,597 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
104
Forks
138
Avg merge
1d 13h
Merged PRs (30d)
56

Description

### 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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.