Storage Hub v0.3.4

StorageHub v0.3.4

Summary

StorageHub v0.3.4 is a patch release focused on SDK gas handling, backend session cleanup, and client slashing optimisation. It introduces automatic EIP-1559 gas limit computation in the SDK (adapting to network congestion while still allowing manual overrides), improves download session robustness in the backend by using RAII-style guards for automatic cleanup on failure or disconnection, and prevents the client from repeatedly submitting no-op slash extrinsics for providers that have zero capacity/stake.

Components

• Client code: v0.3.4
• Pallets code: v0.3.4
• Runtime code: v0.3.4 (spec_name/spec_version: parachain sh-parachain-runtime/1, solochain-evm sh-solochain-evm/1)
• SH Backend Docker image: v0.3.4 (image: ghcr.io//storage-hub-msp-backend:v0.3.4)
• SH SDK (npm): v0.4.4 (@storagehub-sdk/core, @storagehub-sdk/msp-client)
• types-bundle/api-augment (npm): @storagehub/types-bundle v0.3.2, @storagehub/api-augment v0.3.2

Changes since last tag

Base: 57d2a19

• Highlights:

  • SDK adaptive gas limit: SDK now automatically computes EIP-1559 gas limits by querying the base fee from the latest block and setting a higher limit to handle periods of high network traffic; users can still override these values by providing an EvmWriteOptions object when calling precompile methods (PR #655).
  • Backend download session robustness: download sessions now use a guard that automatically removes the session from active downloads when dropped, ensuring cleanup on failure, disconnection, or RPC response errors—matching the existing pattern for upload sessions (PR #656).
  • Skip slashing zero-capacity providers: the client now queries a provider's capacity before attempting to slash them, preventing repeated submission of no-op slash extrinsics for providers with 0 capacity/stake (PR #661).

• Full diff: 57d2a19...92747d5

• PRs included:

  • #661 fix: 🩹 Skip slashing storage provider with zero capacity
  • #656 fix(backend): 🐛 drop download sessions when failing or disconnecting
  • #655 feat: ✨ SDK adaptative gas limit

Migrations

RocksDB (File Storage)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

RocksDB (Forest Storage)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

RocksDB (State store)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

Indexer DB (Postgres)

• Migrations:
  • No new Postgres migrations in this release.
• How to apply: The indexer service runs migrations automatically on startup. Alternatively run diesel migration run.

⚠️ Breaking Changes ⚠️

None. All PRs included in this release are labelled not-breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

Runtime

• Upgrades (spec_version): parachain and solochain-evm remain at spec_version 1.
• Behaviour changes:
  • None in this release range.
• Migrations: None (runtime storage layout unchanged in this release range).
• Constants changed: None requiring operator action.
• Scripts to run: None.

Client

• Behaviour changes:
  • Skip slashing zero-capacity providers: before attempting to slash a storage provider, the client now queries the provider's capacity; providers with 0 capacity/stake are skipped, preventing repeated submission of no-op slash extrinsics (PR #661).
• Initialisation / configuration changes:
  • None.

Backend

• Behaviour changes:
  • Download session cleanup robustness: each download session now has a guard that automatically removes the session from the active downloads map when dropped; this ensures proper cleanup regardless of how the download task exits (success, failure, RPC errors, or disconnection), matching the existing pattern used for upload sessions (PR #656).
• Initialisation / configuration changes:
  • None.

SDK

• Behaviour changes:
  • Automatic EIP-1559 gas limit computation: the SDK now retrieves the base fee from the latest block and sets a higher gas limit to handle periods of high network traffic automatically; users can still override these values by providing an EvmWriteOptions object when calling any method from the precompiles (PR #655).
• Initialisation changes:
  • None (SDK is now at v0.4.4).

Versions

• Polkadot SDK: polkadot-stable2412-6
• Rust: 1.91 (from rust-toolchain.toml)

Compatibility

• SH Backend v0.3.4 → compatible with pallets/runtime v0.3.4 and client v0.3.4 (all built from this release range).
• SDK v0.4.4 → compatible with backend v0.3.4, client v0.3.4, and pallets/runtime v0.3.4.
• types-bundle v0.3.2 + api-augment v0.3.2 → compatible with this runtime release's metadata; regenerate if you run custom runtimes.

Upgrade Guide

General upgrade notes

• No database migrations are required in this release; upgrading from v0.3.3 should be seamless.
• The SDK gas limit changes are automatic and require no code changes; if you were manually setting gas limits, your existing EvmWriteOptions overrides will continue to work.

Breaking PRs

None. Upgrading from the previous release should be seamless. All PRs included in this release are labelled not-breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

StorageHub v0.3.3

Summary

StorageHub v0.3.3 is a patch release focused on BSP confirmation robustness and client block-processing correctness. It introduces a new File System runtime API to let BSPs pre-filter confirm-storing requests (and adds retry logic for transient proof failures caused by concurrent forest modifications), fixes a race where finality notifications could be processed before their corresponding block import (by queueing finality until import processing completes), and removes an unnecessary restriction that prevented users/fishermen from updating payment streams when a provider is marked insolvent.

Components

• Client code: v0.3.3
• Pallets code: v0.3.3
• Runtime code: v0.3.3 (spec_name/spec_version: parachain sh-parachain-runtime/1, solochain-evm sh-solochain-evm/1)
• SH Backend Docker image: v0.3.3 (image: ghcr.io//storage-hub-msp-backend:v0.3.3)
• SH SDK (npm): v0.4.3 (@storagehub-sdk/core, @storagehub-sdk/msp-client)
• types-bundle/api-augment (npm): @storagehub/types-bundle v0.3.1, @storagehub/api-augment v0.3.2

Changes since last tag

Base: d27e41f

• Highlights:

  • BSP confirm storing retries + pre-filtering via runtime API: BSP upload now pre-filters “file keys to confirm” using a new runtime API (query_pending_bsp_confirm_storage_requests) before generating proofs, and retries confirmation when proof verification fails due to concurrent forest changes (handling ForestProofVerificationFailed / FailedToApplyDelta by re-queuing) (PR #624).
  • Finality/import ordering fix (no more undefined behaviour): finality notifications are queued if they arrive before their corresponding block import has been fully processed, and drained after import processing catches up; this avoids processing finality for blocks that have not yet completed import-side effects (PR #640).
  • Payment streams update allowed for insolvent providers: removing the “provider must be solvent” pre-check for updates lets users/fishermen update payment streams even if a BSP/MSP is marked insolvent (unblocking file deletion flows) (PR #657).

• Full diff: d27e41f...c1c3268

• PRs included:

  • #657 fix: 🐛 Allow updating payment stream for insolvent provider
  • #640 fix: 🐛 Process finality notifications only after processing the corresponding block import
  • #624 feat(bsp): ✨ Add retry logic for confirm storing proof errors

Migrations

RocksDB (File Storage)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

RocksDB (Forest Storage)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

RocksDB (State store)

• Changes:
  • Blockchain service state store now persists full “last processed block” info (number + hash) via a new RocksDB column family last_processed_block (keeping the old last_processed_block_number CF for backward compatibility).
  • Finality processing state is persisted via last_finalised_block to avoid redundant finality re-processing after restart (PR #640).
• Action required:
  • None. The blockchain service state store creates missing column families automatically on startup.

Indexer DB (Postgres)

• Migrations:
  • No new Postgres migrations in this release.
• How to apply: The indexer service runs migrations automatically on startup. Alternatively run diesel migration run.

⚠️ Breaking Changes ⚠️

• PR #624: Adds a new File System runtime API method query_pending_bsp_confirm_storage_requests under FileSystemApi; downstream/custom runtimes integrating StorageHub must implement this API.

Runtime

• Upgrades (spec_version): parachain and solochain-evm remain at spec_version 1.
• Behaviour changes:
  • File System runtime API for BSP confirmations: adds query_pending_bsp_confirm_storage_requests to pallet_file_system_runtime_api::FileSystemApi, allowing BSPs to filter a list of file keys to only those that still require confirm-storing (excluding already-confirmed, non-volunteer, or non-existent storage requests) (PR #624).
  • Payment Streams: allow updates even if provider is insolvent: removes the “provider must be solvent” pre-check from update_fixed_rate_payment_stream and update_dynamic_rate_payment_stream, so user-driven updates are not blocked purely because the provider is marked insolvent (PR #657).
• Migrations: None (runtime storage layout unchanged in this release range).
• Constants changed: None requiring operator action.
• Scripts to run: None.

Client

• Behaviour changes:
  • BSP confirm storing robustness:
    • Pre-filters storage requests using the new runtime API before proof generation (query_pending_bsp_confirm_storage_requests).
    • Retries confirm-storing when proof verification fails due to concurrent forest modifications, re-queuing on ForestProofVerificationFailed and FailedToApplyDelta.
    • Tracks pending volunteer transactions so confirm-storing requests are not incorrectly filtered out if the volunteer tx is not yet finalised on-chain; such requests are re-queued instead of discarded (fixes flaky integration tests) (PR #624).
  • Block processing correctness: queues finality notifications that arrive “too early” (before import processing has completed for that block) and drains them after each block import, ensuring finality is only processed once the corresponding block import side-effects have been fully applied (PR #640).
• Initialisation / configuration changes:
  • None.

Backend

• Behaviour changes: None in this release range.
• Initialisation / configuration changes: None.

SDK

• Behaviour changes: None in this release range.
• Initialisation changes: None (SDK remains at v0.4.3).

Versions

• Polkadot SDK: polkadot-stable2412-6
• Rust: 1.91 (from rust-toolchain.toml)

Compatibility

• SH Backend v0.3.3 → compatible with pallets/runtime v0.3.3 and client v0.3.3 (all built from this release range).
• SDK v0.4.3 → compatible with backend v0.3.3, client v0.3.3, and pallets/runtime v0.3.3.
• types-bundle v0.3.1 + api-augment v0.3.2 → compatible with this runtime release’s metadata; regenerate if you run custom runtimes.

Upgrade Guide

General upgrade notes

• The blockchain service state store has a small on-disk schema extension (new RocksDB column families) but it is applied automatically on startup; no manual operator action is required (PR #640).
• If you are integrating StorageHub into a downstream runtime, ensure you update runtime APIs and regenerate bindings as needed before rolling out clients/backends.

Breaking PRs

• PR #624 – New File System runtime API for BSP confirm-storing pre-filtering

  • Short description:

    Added a new runtime API query_pending_bsp_confirm_storage_requests to the FileSystemApi. This API allows BSPs to filter a list of file keys to only those that still require confirmation (i.e., where the BSP has volunteered but not yet confirmed storing).

  • Who is affected:

    • Custom runtimes using StorageHub pallets: Must implement the new runtime API method in their FileSystemApi implementation.

  • Suggested code changes:

    • No changes are required for nodes running with the pre-configured Parachain and Solochain runtimes.

    • Implement the runtime API for custom runtime:

      impl pallet_file_system_runtime_api::FileSystemApi<Block, ...> for Runtime {
          // ... existing methods ...
      
          fn query_pending_bsp_confirm_storage_requests(
              bsp_id: BackupStorageProviderId,
              file_keys: Vec<FileKey>,
          ) -> Vec<FileKey> {
              FileSystem::query_pending_bsp_confirm_storage_requests(&bsp_id, file_keys)
          }
      }

StorageHub v0.3.2

Summary

StorageHub v0.3.2 is a small patch release focused on MSP/Fisherman robustness. It prevents MSPs from creating local forest instances during the post-sync sanity check when the bucket is missing locally (treating this as valid iff the on-chain root is the default/empty root), and ensures the Fisherman can always make forward progress by truncating batch deletions to the on-chain MaxFileDeletionsPerExtrinsic limit (using BoundedVec end-to-end).

Components

• Client code: v0.3.2
• Pallets code: v0.3.2
• Runtime code: v0.3.2 (spec_name/spec_version: parachain sh-parachain-runtime/1, solochain-evm sh-solochain-evm/1)
• SH Backend Docker image: v0.3.2 (image: ghcr.io//storage-hub-msp-backend:v0.3.2)
• SH SDK (npm): v0.4.3 (@storagehub-sdk/core, @storagehub-sdk/msp-client)
• types-bundle/api-augment (npm): @storagehub/types-bundle v0.3.0, @storagehub/api-augment v0.3.1

Changes since last tag

Base: ea8181c

• Highlights:

  • MSP post-sync sanity check no longer creates forests for missing buckets: when a bucket forest is missing locally after initial sync, MSPs now treat it as valid only if the on-chain bucket root is the default/empty root (DefaultMerkleRoot::<Runtime>::get()); otherwise it is reported as CRITICAL (bucket is not empty but local forest is missing) (PR #652).
  • Fisherman batch deletions always make progress: the Fisherman now truncates “files to delete” batches to the on-chain MaxFileDeletionsPerExtrinsic constant before building extrinsics, avoiding a stuck loop where oversized batches repeatedly fail. The processing pipeline now uses BoundedVec::truncate_from(...) (and defensive warnings if later stages still truncate) (PR #654).

• Full diff: ea8181c...1ec90c1

• PRs included:

  • #654 fix: Fisherman truncate files to delete based on MaxFileDeletionsPerExtrinsic runtime constant
  • #652 fix: 🩹 Avoid creating forests locally when not found in initial check after sync

Migrations

RocksDB (File Storage)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

RocksDB (Forest Storage)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

RocksDB (State store)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

Indexer DB (Postgres)

• Migrations:
  • No new Postgres migrations in this release.
• How to apply: The indexer service runs migrations automatically on startup. Alternatively run diesel migration run.

⚠️ Breaking Changes ⚠️

None. Upgrading from the previous release should be seamless. All PRs included in this release are labelled not-breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

Runtime

• Upgrades (spec_version): parachain and solochain-evm remain at spec_version 1.
• Behaviour changes: None in this release range.
• Migrations: None.
• Constants changed: None requiring operator action.
• Scripts to run: None.

Client

• Behaviour changes:
  • MSP post-sync root verification:
    • If a local bucket forest exists after sync, its local root must match the on-chain root; mismatches are reported as CRITICAL.
    • If a local bucket forest does not exist, the on-chain root must be the default/empty root (DefaultMerkleRoot::<Runtime>::get()); otherwise it is reported as CRITICAL (bucket is not empty but local forest is missing) (PR #652).
  • Fisherman batch deletions:
    • The Fisherman truncates the number of files processed for deletion per cycle to the on-chain MaxFileDeletionsPerExtrinsic limit, ensuring extrinsic submission never fails purely due to an oversized batch and that remaining deletions are processed in subsequent cycles.
    • The extrinsics delete_files and delete_files_for_incomplete_storage_request now receive BoundedVec inputs constructed via BoundedVec::truncate_from(...) to avoid conversion errors (PR #654).
• Initialisation / configuration changes:
  • None.

Backend

• Behaviour changes: None in this release range.
• Initialisation / configuration changes: None.

SDK

• Behaviour changes: None in this release range.
• Initialisation changes: None (SDK remains at v0.4.3).

Versions

• Polkadot SDK: polkadot-stable2412-6
• Rust: 1.91 (from rust-toolchain.toml)

Compatibility

• SH Backend v0.3.0 → compatible with pallets/runtime v0.3.0 and client v0.3.0 (all built from this release range).
• SDK v0.4.3 → compatible with backend v0.3.0, client v0.3.0, and pallets/runtime v0.3.0.
• types-bundle v0.3.0 + api-augment v0.3.1 → compatible with this runtime release’s metadata; regenerate if you run custom runtimes.

Upgrade Guide

None. Upgrading from the previous release should be seamless. All PRs included in this release are labelled not-breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

StorageHub v0.2.11

Summary

StorageHub v0.2.11 is a patch release focused on operational correctness for the fisherman batch deletion flow. The fisherman now caps and truncates the number of files it attempts to delete per cycle based on the on-chain MaxFileDeletionsPerExtrinsic runtime constant, preventing repeated extrinsic submission failures where the fisherman would otherwise make no deletion progress.

Components

• Client code: v0.2.11
• Pallets code: v0.2.11
• Runtime code: v0.2.11 (spec_name/spec_version: parachain 1, solochain-evm 1)
• SH Backend Docker image: v0.2.11 (image: ghcr.io/<org>/storage-hub-msp-backend:v0.2.11)
• SH SDK (npm): v0.3.4 (@storagehub-sdk/core, @storagehub-sdk/msp-client)
• types-bundle/api-augment (npm): @storagehub/types-bundle v0.2.8, @storagehub/api-augment v0.2.13

Changes since last tag

Base: 5c3813a

• Highlights:
  • Fisherman batch deletion respects on-chain MaxFileDeletionsPerExtrinsic: the fisherman task event handler now truncates the per-cycle deletion set to the chain-configured maximum and uses BoundedVec::truncate_from end-to-end when building extrinsics, preventing the recurring failure Batch size exceeds MaxFileDeletionsPerExtrinsic limit and allowing remaining deletions to be processed in subsequent cycles. (#654)
• Full diff: 5c3813a...15650c2
• PRs included:
  • #654 fix: Fisherman truncate files to delete based on MaxFileDeletionsPerExtrinsic runtime constant

Migrations

RocksDB (File Storage)

• Changes:
  • No new schema changes.
• Action required:
  • None.

RocksDB (Forest Storage)

• Changes:
  • No new schema changes.
• Action required:
  • None.

RocksDB (State store)

• Changes:
  • No schema changes that require migration.
• Action required:
  • None.

Indexer DB (Postgres)

• Migrations:
  • No new indexer migrations were introduced in this release; the migration set is unchanged from v0.2.0.
• How to apply: The indexer service runs migrations automatically on startup. Alternatively run diesel migration run.

Pending extrinsics DB (Postgres)

• Migrations:
  • No new migrations; the pending-extrinsics schema remains unchanged.
• How to apply: The Blockchain Service runs migrations automatically on startup. Alternatively run diesel migration run.

⚠️ Breaking Changes ⚠️

• None.

Runtime

• Upgrades (spec_version): parachain and solochain-evm remain at spec_version 1; no runtime upgrades were made in this release.
• Migrations: No new runtime storage migrations were added.
• Constants changed: None that require operator action.
• Scripts to run: None specific to this release.

Client

• Behaviour changes:
  • Fisherman batch deletion is now capped by MaxFileDeletionsPerExtrinsic: when processing a target’s pending deletions, the fisherman truncates the per-cycle deletion set to the on-chain maximum (MaxFileDeletionsPerExtrinsic) and logs when truncation occurs (remaining files are processed in subsequent cycles).
  • Extrinsic construction uses bounded vectors throughout: the fisherman now uses BoundedVec (via BoundedVec::truncate_from) for:
    • The initial deletion batch selection, and
    • The runtime call inputs (delete_files and delete_files_for_incomplete_storage_request),
      preventing submission-time errors due to oversized batches.
• Initialisation changes:
  • None.

Backend

• Behaviour changes:
  • None in this release. Backend behaviour, HTTP APIs, and configuration remain unchanged.
• Initialisation changes:
  • None.

SDK

• Behaviour changes:
  • None in this release. The SDK packages remain at v0.3.4, with no API or typing changes in this release range.
• Initialisation changes:
  • None.

Versions

• Polkadot SDK: polkadot-stable2412-6
• Rust: 1.90 (from rust-toolchain.toml)

Compatibility

• SH Backend v0.2.11 → compatible with pallets/runtime v0.2.11 and client v0.2.11 (all built from this release series).
• SDK v0.3.4 → compatible with backend v0.2.11, client v0.2.11, and pallets/runtime v0.2.11.

Upgrade Guide

None. Upgrading from the previous release should be seamless. All PRs included in this release are labelled not-breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

StorageHub v0.3.1

Summary

StorageHub v0.3.1 is a patch release focused on operability and scale: it adds first-class Prometheus/Grafana telemetry for client services, introduces a bounded LRU cache for MSP forest instances to prevent running out of memory / file descriptors on large bucket counts, and hardens MSP backend endpoints by reducing RPC load and caching /stats. It also includes a small SDK compatibility fix for Reown social login and updates the toolchain to Rust 1.91.

Components

• Client code: v0.3.0
• Pallets code: v0.3.0
• Runtime code: v0.3.0 (spec_name/spec_version: parachain sh-parachain-runtime/1, solochain-evm sh-solochain-evm/1)
• SH Backend Docker image: v0.3.0 (image: ghcr.io//storage-hub-msp-backend:v0.3.0)
• SH SDK (npm): v0.4.3 (@storagehub-sdk/core, @storagehub-sdk/msp-client)
• types-bundle/api-augment (npm): @storagehub/types-bundle v0.3.0, @storagehub/api-augment v0.3.1

Changes since last tag

Base: 017118e

• Highlights:

  • Prometheus metrics for client services (MSP/BSP/Fisherman): adds shc-telemetry and a comprehensive metrics catalogue for command processing, event handlers, block processing, file transfer, and system resources. Includes Docker Prometheus + Grafana scaffolding and dashboards for provider roles (PR #594).
  • MSP scale fix: bound open forest instances via LRU: MSP forests are now lazy-loaded and retained through a bounded cache, preventing runaway memory/FD usage on large bucket counts. Adds a new max_open_forests configuration surface (default 512) (PR #645).
  • Cheaper and safer /stats: backend /stats is cached to avoid being spammed, and the runtime API it depends on is simplified via a new Payment Streams runtime API get_number_of_active_users_of_provider (PR #650).
  • Backend load reduction: backend health checks no longer query provider ID, reducing RPC churn and log noise (PR #648).

• Full diff: 017118e...e135f65

• PRs included:

  • #650 feat: ✨ Add caching to /stats endpoint
  • #648 refactor(backend): ⚡ make it so the health endpoint of the backend does not query the provider ID
  • #647 perf: ⚡️ Optimize fisherman batch deletion queries
  • #645 fix: 🐛 make it so we don't open all forests and instead cache a subset of them
  • #644 build: ⬆ Upgrade to Rust 1.91
  • #641 monitor: update fisherman service logs
  • #639 fix: 🐛 make chain null for compatibility with reown's social login
  • #620 test: 🧪 Add integration tests for is_in_bucket consistency and deletion
  • #594 feat: 📺 Add telemetry metrics instrumentation

Migrations

RocksDB (File Storage)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

RocksDB (Forest Storage)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

RocksDB (State store)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

Indexer DB (Postgres)

• Migrations:
  • No new Postgres migrations in this release.
• How to apply: The indexer service runs migrations automatically on startup. Alternatively run diesel migration run.

⚠️ Breaking Changes ⚠️

• PR #594: StorageHubBuilder::new() now requires an Option<&Registry> (from substrate_prometheus_endpoint) to configure Prometheus metrics; node implementations using StorageHubBuilder must update the builder call site.
• PR #645: MSP forest storage is now lazy-loaded and bounded by an LRU cache; operators and integrators may need to tune the new max_open_forests setting (and ensure OS FD limits match the chosen cap).
• PR #650: Payment Streams introduces a new runtime API get_number_of_active_users_of_provider; downstream runtimes integrating StorageHub must implement the new API.

Runtime

• Upgrades (spec_version): parachain and solochain-evm remain at spec_version 1.
• Behaviour changes:
  • Payment Streams runtime API change for /stats: adds get_number_of_active_users_of_provider and simplifies stats collection by iterating payment streams by provider prefix and returning a count (rather than materialising full user lists) (PR #650).
• Migrations: None.
• Constants changed: None requiring operator action.
• Scripts to run: None.

Client

• Behaviour changes:
  • Telemetry metrics instrumentation: Prometheus counters/histograms/gauges for command processing and event handler lifecycle (including automatic labelling via actor macros), plus block-processing, file-transfer, and resource-usage metrics via a periodic sysinfo collector (PR #594).
  • Forest storage scalability: forests are no longer all opened eagerly; forest instances are lazy-loaded and retained via a bounded LRU cache to cap FD/memory usage on large bucket counts (PR #645).
  • Fisherman batch deletions performance: removes an N+1 pattern when building ephemeral tries for batch deletions by fetching required metadata in a single batch query (important for large file counts) (PR #647).
  • Operational logging: fisherman logs improve hex visibility for file keys and clarify deletion targets/remaining time for batch intervals (PR #641).
• Initialisation / configuration changes:
  • New provider config key: max_open_forests (default: 512) controls the maximum number of simultaneously open forest storage instances (primarily relevant for MSPs) (PR #645).
  • Monitoring stack: Prometheus/Grafana deployment templates and dashboards are provided under docker/ for observing the new metrics (PR #594).

Backend

• Behaviour changes:
  • /stats caching: adds a simple cache layer to reduce RPC/runtime API load and mitigate endpoint spamming (PR #650).
  • Health endpoint RPC reduction: backend health checks no longer query provider ID, reducing unnecessary RPC calls and log noise (PR #648).
• Initialisation / configuration changes:
  • None required for existing deployments (cache behaviour is internal), but operators should monitor /stats freshness expectations after upgrade.

SDK

• Behaviour changes:
  • EVM write compatibility: sets chain ID to null during write-contract transactions to improve compatibility with Reown’s social login flows (PR #639).
• Initialisation changes:
  • Upgrade to @storagehub-sdk/core and @storagehub-sdk/msp-client v0.4.3.

Versions

• Polkadot SDK: polkadot-stable2412-6
• Rust: 1.91 (from rust-toolchain.toml)

Compatibility

• SH Backend v0.3.0 → compatible with pallets/runtime v0.3.0 and client v0.3.0 (all built from this release range).
• SDK v0.4.3 → compatible with backend v0.3.0, client v0.3.0, and pallets/runtime v0.3.0.
• types-bundle v0.3.0 + api-augment v0.3.1 → compatible with this runtime release’s metadata; regenerate if you run custom runtimes.

Upgrade Guide

General upgrade notes

• No DB migrations are introduced in this release range; apply migrations as usual if your deployment pipeline expects them (indexer runs them on startup, or run diesel migration run).
• If you are integrating StorageHub into a downstream runtime, ensure you update runtime APIs and regenerate bindings as needed before rolling out clients/backends.

Breaking PRs

• PR #594 – Telemetry metrics instrumentation (builder API change)

  • Short description:
    • The StorageHubBuilder::new() constructor now takes an additional Option<&Registry> parameter (Registry from substrate_prometheus_endpoint) to configure Prometheus metrics. If Some(registry) is provided, metrics will be enabled for all services. If None, metrics will be disabled (no-op).
  • Who is affected:
    • Node implementations using StorageHubBuilder: you must update the new() call to include the prometheus registry parameter.
  • Suggested code changes:
    • Update the StorageHubBuilder::new() call site and wiring as per PR #594. The PR includes a full monitoring setup guide and the exact diff for the builder/registry plumbing.

• PR #645 – Bounded forest LRU cache (max_open_forests)

  • Short description:
    • Forest storage instances are now lazy-loaded and kept open via a bounded LRU cache to prevent running out of memory / file descriptors when an MSP manages many buckets. A new max_open_forests setting controls the maximum number of simultaneously open forests (default: 512).
  • Who is affected:
    • Projects using the StorageHub Client: this change directly impacts runtime behaviour and file descriptor usage.
    • Operators running via config.toml: a ne...

StorageHub v0.2.10

Summary

StorageHub v0.2.10 is a patch release focused on operational stability and performance for provider workloads that manage many buckets and/or large numbers of files. The headline change is a bounded LRU cache for forest storage instances so MSP nodes no longer attempt to keep every bucket’s forest open concurrently (which could exhaust memory and file descriptors). This release also improves performance in the fisherman batch deletion flow by replacing an expensive N+1 metadata query pattern with a single batch query when building the ephemeral trie.

Components

• Client code: v0.2.10
• Pallets code: v0.2.10
• Runtime code: v0.2.10 (spec_name/spec_version: parachain 1, solochain-evm 1)
• SH Backend Docker image: v0.2.10 (image: ghcr.io/<org>/storage-hub-msp-backend:v0.2.10)
• SH SDK (npm): v0.3.4 (@storagehub-sdk/core, @storagehub-sdk/msp-client)
• types-bundle/api-augment (npm): @storagehub/types-bundle v0.2.8, @storagehub/api-augment v0.2.13

Changes since last tag

Base: a2c15c6

• Highlights:
  • Bounded forest LRU cache (breaking): forest storage instances are now lazy-loaded and managed via a bounded LRU cache, preventing MSP nodes from running out of memory / file descriptors when managing many buckets. A new max_open_forests setting (default: 512) controls the maximum number of simultaneously open forests. (#649)
  • Fisherman batch deletion query optimisation: replaces an N+1 metadata query pattern when building the ephemeral trie for batch deletions by fetching the required file metadata columns in a single query (instead of get_all_file_keys_* + per-file get_by_file_key). This avoids pathological slowdowns for large BSP datasets (e.g. ~100K files). (#647)
• Full diff: a2c15c6...5c3813a
• PRs included:
  • #649 fix: 🐛 make it so we don't open all forests and instead cache a subset of them
  • #647 perf: ⚡️ Optimize fisherman batch deletion queries
  • #646 feat: add timing logs to fisherman batch deletion flow (labelled B0-silent)
  • #641 monitor: update fisherman service logs (labelled B0-silent)

Migrations

RocksDB (File Storage)

• Changes:
  • No new schema changes.
• Action required:
  • None.

RocksDB (Forest Storage)

• Changes:
  • No new schema changes. This release changes how forest instances are opened/kept alive, but does not introduce a new on-disk format.
• Action required:
  • None.

RocksDB (State store)

• Changes:
  • No schema changes that require migration.
• Action required:
  • None.

Indexer DB (Postgres)

• Migrations:
  • No new indexer migrations were introduced in this release; the migration set is unchanged from v0.2.0.
• How to apply: The indexer service runs migrations automatically on startup. Alternatively run diesel migration run.

Pending extrinsics DB (Postgres)

• Migrations:
  • No new migrations; the pending-extrinsics schema remains unchanged.
• How to apply: The Blockchain Service runs migrations automatically on startup. Alternatively run diesel migration run.

⚠️ Breaking Changes ⚠️

• #649 Forest storage is now lazy-loaded and bounded by an LRU cache. Operators can configure the maximum number of open forests via max_open_forests (default: 512). This changes runtime behaviour for MSP nodes that manage many buckets and may require tuning max_open_forests (and OS file descriptor limits) for very large deployments.

Runtime

• Upgrades (spec_version): parachain and solochain-evm remain at spec_version 1; no runtime upgrades were made in this release.
• Migrations: No new runtime storage migrations were added.
• Constants changed: None that require operator action.
• Scripts to run: None specific to this release.

Client

• Behaviour changes:
  • Bounded, lazy-loaded forest storage (breaking): instead of keeping all forests open indefinitely, forest storage instances are now opened on demand and kept open via a bounded LRU cache. This prevents running out of memory and file descriptors when an MSP manages many buckets. The new provider setting max_open_forests controls the cache size (default: 512). For BSPs (which typically use a single forest), this setting is effectively ignored.
  • Fisherman batch deletion query optimisation: when building the ephemeral trie for batch deletions, the fisherman flow now fetches the required file metadata columns in a single query, avoiding per-file metadata lookups after listing file keys (i.e. avoiding an N+1 query pattern). This significantly reduces build time for large datasets.
• Initialisation changes:
  • A new provider configuration key is available: max_open_forests (safe default exists). Operators may wish to tune this alongside OS file descriptor limits for very large MSP deployments.

Backend

• Behaviour changes:
  • None in this release. Backend behaviour, HTTP APIs, and configuration remain unchanged.
• Initialisation changes:
  • None.

SDK

• Behaviour changes:
  • None in this release. The SDK packages remain at v0.3.4, with no API or typing changes in this release range.
• Initialisation changes:
  • None.

Versions

• Polkadot SDK: polkadot-stable2412-6
• Rust: 1.90 (from rust-toolchain.toml)

Compatibility

• SH Backend v0.2.10 → compatible with pallets/runtime v0.2.10 and client v0.2.10 (all built from this release series).
• SDK v0.3.4 → compatible with backend v0.2.10, client v0.2.10, and pallets/runtime v0.2.10.

Upgrade Guide

• PR #649 – forest storage LRU cache and max_open_forests
  • Short description:
    Forest storage instances are now lazy-loaded and kept open via a bounded LRU cache to prevent running out of memory / file descriptors when an MSP manages many buckets. A new max_open_forests setting controls the maximum number of simultaneously open forests (default: 512).
  • Who is affected:
    • Projects using the StorageHub Client: this change directly impacts runtime behaviour and file descriptor usage.
    • Operators running via config.toml: a new provider config key is available (max_open_forests) (safe default exists).
  • Suggested code changes:
    • Ensure your node/client wiring supports configuring max_open_forests via:
      • The --max-open-forests CLI flag, and/or
      • The max_open_forests provider option in config.toml,
        and that this value is passed into the storage layer setup (default: 512).
    • If you maintain a downstream node fork or custom deployment tooling, see the “Suggested code changes” section in PR #649 for the full code snippets (CLI/config field additions and wiring in the service builder).

StorageHub v0.3.0

Summary

StorageHub v0.3.0 focuses on making MSP operations more robust at scale, hardening the indexer around file deletion / redundancy edge cases, and improving operability for runtime upgrades. Highlights include a trusted file transfer server for backend uploads (moving away from RPC/proof-heavy uploads), new file lifecycle states (revoked/rejected) that propagate through backend + SDK, a governance-controlled pause switch for user-facing File System operations, and multiple fixes to prevent indexer stalls and MSP lag on large bucket counts.

Components

• Client code: v0.3.0
• Pallets code: v0.3.0
• Runtime code: v0.3.0 (spec_name/spec_version: parachain sh-parachain-runtime/1, solochain-evm sh-solochain-evm/1)
• SH Backend Docker image: v0.3.0 (image: ghcr.io//storage-hub-msp-backend:v0.3.0)
• SH SDK (npm): v0.4.2 (@storagehub-sdk/core, @storagehub-sdk/msp-client)
• types-bundle/api-augment (npm): @storagehub/types-bundle v0.3.0, @storagehub/api-augment v0.3.1

Changes since last tag

Base: d9a2832

• Highlights:

  • Trusted file transfer for backend uploads: MSP nodes can now spawn a trusted HTTP upload server, used by the backend to stream files without per-chunk proofs. This introduces new backend and node configuration fields and should be firewalled from the public internet (PR #595).
  • Indexer/runtime/backend/SDK file deletion hardening: the indexer no longer deletes file records while there are open storage requests; the runtime blocks new storage requests/deletions in inconsistent states; backend + SDK handle two new file statuses (revoked, rejected) (PR #596).
  • Runtime operability: File System user operations can now be paused granularly via a new storage bitmask and a Root-only extrinsic set_user_operation_pause_flags (and a new UserOperationPaused error) (PR #632).
  • Storage request correctness for “redundancy-only” flows: prevent fisherman from incorrectly deleting files from buckets when users add redundancy, including introducing MspStorageRequestStatus/msp_status and new cleanup/event semantics (PR #600).
  • Required runtime migration for open storage requests: adds a File System pallet migration to safely migrate StorageRequestMetadata to the new msp_status layout on upgrade (PR #628).
  • SIWX support (CAIP‑122): backend + SDK now support SIWX, with automatic domain extraction from URIs and an updated MspClient auth/session-provider story (PR #592).
  • Indexer DB consistency and repair: new migrations to normalise is_in_bucket across sibling file records and to recalculate bucket stats (file_count, total_size) from linked file records (PR #598, PR #619).
  • MSP scalability: remove an expensive “query all buckets” call from block import processing (fixing MSP lag with large bucket counts) and fix a race that could emit duplicate NewStorageRequest events (PR #636, PR #638).

• Full diff: d9a2832...017118e

• PRs included:

  • #638 fix: 🚑 MSP race condition storage request emission
  • #637 fix: 🔊 Improve some printing of hex strings in logs
  • #636 fix: 🚑 Avoid iterating through all buckets at every event in block import notification
  • #635 fix: 🐛 Configure network before requesting accounts in wallet connection
  • #634 fix: 🩹 change MaxMultiAddressSize to match DataHaven's
  • #633 feat: check SDK version in the CI
  • #632 feat: ✨ Make user operations in File System pallet pausable
  • #631 feat: 🔈 Improve logs for Blockchain Service processing of notifications
  • #630 test: 🧪 Add test used to reproduce deadlock in Blockchain Service
  • #629 refactor: 🔒 Reduce file storage locks critical zone
  • #628 feat: ✨ add migration for msp field in file system's StorageRequestMetadata
  • #627 feat: ✨ Add script to cleanup files from MSP forest based on json
  • #626 feat: ✨ Script to bump versions and CI to check in release
  • #625 ci: 💚 Fix SDK CI Next JS workspace error
  • #623 refactor: 🔒 Narrow scope of usage of read and write locks to forest and file storage
  • #621 bench: update delete_files_bucket and delete_files_bsp benchmarks for worst case scenario
  • #619 fix: migration calculating calculating bucket stats (file_count, size) using files associated to bucket
  • #617 feat: ✨ mutations initial sync handlers
  • #616 test: 🔊 Improve integration test logs
  • #615 fix: 🐛 Create bucket forest on apply Forest mutation if it doesn't exist
  • #614 feat(file-transfer): use TryConnect for peer requests
  • #613 fix: 🐛 correctly emit mutations in events
  • #612 revert: ⏮️ revert back to using metamask recommended version from dappwright
  • #610 fix: 🐛 file record deduplication on deletion
  • #609 fix(e2e): use MetaMask 12.23.1 for dappwright compatibility
  • #608 build: ⬆️ Upgrade to Rust 1.90 and fix warnings
  • #607 feat: 🔊 Add verbose failure logs to indexing
  • #604 fix: 🚑 Query bucket of storage request by onchain ID
  • #603 fix: 🐛 general indexer improvements
  • #602 feat: 🎨 BSP stop storing improvements
  • #601 feat: 🎨 move bucket flow improvements
  • #600 fix: 🐛 multiple fixes to avoid the fisherman incorrectly deleting a file from a bucket
  • #599 style: 🎨 clean up file system pallet
  • #598 fix: 🚑 make it so is_in_bucket is consistent across same file key records
  • #596 fix: 🚑 indexer handling of file deletion
  • #595 feat: ✨ Implement a trusted file transfer for backend uploads
  • #593 fix: 🚑 Handle multiple file records for same file_key
  • #592 feat: SIWX
  • #591 feat: 🔊 Add success logs to all tasks and RPCs
  • #590 ci: 📝 Enforce breaking changes doc structure
  • #589 fix: 🚑 Avoid cleaning up tx store with genesis block
  • #585 test: persist backend logs from a tests run
  • #581 feat(shc-common): feature gate parachain dependencies
  • #571 feat(msp): MSP retries responding storage requests
  • #567 feat(backend): /stats endpoint
  • #543 feat: 🪟 Windows script compatibility

Migrations

RocksDB (File Storage)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

RocksDB (Forest Storage)

• Changes:
  • No new schema changes in this release.
• Action required:
  • None.

RocksDB (State store)

• Changes:
  • No mandatory migrations. Note that the Blockchain Service now also persists a block hash alongside the last processed block number (lazy “write-on-first-run” behaviour; see PR #617).
• Action required:
  • None.

Indexer DB (Postgres)

• Migrations:
  • 2025-12-05-191030_normalize_is_in_bucket_across_file_records (PR #598)
  • 2025-12-15-153000_fix_bucket_stats (PR #619)
• How to apply: The indexer service runs migrations automatically on startup. Alternatively run diesel migration run.

⚠️ Breaking Changes ⚠️

• PR #571: Storage Enable client trait changes (StorageEnableRuntime::RuntimeError associated type; StorageEnableErrors::Other now stores a String). Downstream runtimes implementing StorageEnableRuntime must update their trait impl and error conversion.
• PR #581: ParachainClient type alias renamed to StorageHubClient, and Cumulus host functions are now behind an explicit shc-common parachain feature. Downstream consumers must rename the type and set features appropriately.
• PR #590: CI enforces a breaking-changes documentation structure for PRs. This affects contributors (not runtime operators).
• PR #592: SIWX support changes SIWE/SIWX APIs: backend extracts domain from URI (remove domain field), and SDK MspClient session provider is now optional.
• PR #595: Backend uploads now use the trusted file transfer server by default and require new backend/node configuration (trusted_file_transfer_server_url, use_legacy_upload_method, trusted_file_transfer_server{,_host,_port}).
• PR #596: File lifecycle adds new statuses (revoked, rejected) surfaced by backend (FileStatus) and SDK; direct consumers of /buckets/{bucket_id}/info/{file_key} and SDK file info must handle them.
• PR #598: New Indexer DB migration is required to repair and normalise is_in_bucket across sibling file records.
• PR #599: File System pallet event order changed; deployments must upgrade in runtime upgrade -> client upgrade order (or as close to simultaneous as possible) to avoid SCALE decoding issues.
• PR #600: StorageRequestMetadata gains msp_status (and new events), requiring runtime upgrade + metadata update. A safe upgrade path...

StorageHub v0.2.9

Summary

StorageHub v0.2.9 is a small, non‑breaking patch release focused on reducing unnecessary runtime queries during MSP block import notifications. It optimises how the client handles ProofsDealer::MutationsApplied events by extracting the affected BucketId from the event payload and validating MSP ownership per bucket, instead of repeatedly iterating through all buckets managed by an MSP.

The previous approach was causing a severe issue when the chain reached ~10k buckets on-chain. To the point that the MSP block import notification handler would take too long to process the block, and the node would start progressively lagging behind the chain.

Components

• Client code: v0.2.9
• Pallets code: v0.2.9
• Runtime code: v0.2.9 (spec_name/spec_version: parachain 1, solochain-evm 1)
• SH Backend Docker image: v0.2.9 (image: ghcr.io/<org>/storage-hub-msp-backend:v0.2.9)
• SH SDK (npm): v0.3.4 (@storagehub-sdk/core, @storagehub-sdk/msp-client)
• types-bundle/api-augment (npm): @storagehub/types-bundle v0.2.8, @storagehub/api-augment v0.2.13

Changes since last tag

Base: c7b5a8d

• Highlights:
  • More efficient MSP event handling: the MSP block import notification handler no longer queries and iterates through all buckets for the MSP on each MutationsApplied event. Instead it:
    • Decodes the BucketId from the event’s opaque event_info via the runtime API (decode_generic_apply_delta_event_info), and
    • Validates ownership by querying the MSP ID for that specific bucket (query_msp_id_of_bucket_id).
      This reduces per‑event overhead while preserving existing behaviour.
• Full diff: c7b5a8d...a2c15c6
• PRs included:
  • None. All changes in this range were committed directly to the release branch without associated GitHub pull requests. The relevant commit is:
    • a2c15c6 – avoid iterating through all buckets at every event in block import notification.

Migrations

RocksDB (File Storage)

• Changes:
  • No new schema changes.
• Action required:
  • None.

RocksDB (Forest Storage)

• Changes:
  • No new schema changes.
• Action required:
  • None.

RocksDB (State store)

• Changes:
  • No schema changes that require migration.
• Action required:
  • None.

Indexer DB (Postgres)

• Migrations:
  • No new indexer migrations were introduced in this release; the migration set is unchanged from v0.2.0.
• How to apply: The indexer service runs migrations automatically on startup. Alternatively run diesel migration run.

Pending extrinsics DB (Postgres)

• Migrations:
  • No new migrations; the pending‑extrinsics schema introduced in v0.2.0 remains unchanged.
• How to apply: The Blockchain Service runs migrations automatically on startup. Alternatively run diesel migration run.

⚠️ Breaking Changes ⚠️

None. Upgrading from the previous release should be seamless. All changes included in this release are non‑breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

Runtime

• Upgrades (spec_version): parachain and solochain-evm remain at spec_version 1; no runtime upgrades were made in this release.
• Migrations: No new runtime storage migrations were added.
• Constants changed: None that require operator action.
• Scripts to run: None specific to this release.

Client

• Behaviour changes:
  • Targeted bucket validation for mutations: for ProofsDealer::MutationsApplied processing in MSP block import notifications, the client now:
    • Extracts the mutated BucketId from the event payload and
    • Checks whether it is managed by the local MSP by querying query_msp_id_of_bucket_id,
      instead of prefetching and scanning the full bucket list. This reduces redundant runtime queries and avoids iterating through all buckets on every event.
  • More explicit error handling for event decoding: decoding the bucket ID from event_info now returns a Result, logging clear errors when event_info is missing or runtime decoding fails.
• Initialisation changes:
  • None. Existing client configuration remains valid and there are no new CLI flags or config fields introduced by this release.

Backend

• Behaviour changes:
  • None in this release. Backend behaviour, HTTP APIs, and configuration remain unchanged.
• Initialisation changes:
  • None.

SDK

• Behaviour changes:
  • None in this release. The SDK packages remain at v0.3.4, with no API or typing changes in this release range.
• Initialisation changes:
  • None.

Versions

• Polkadot SDK: polkadot-stable2412-6
• Rust: 1.90 (from rust-toolchain.toml)

Compatibility

• SH Backend v0.2.9 → compatible with pallets/runtime v0.2.9 and client v0.2.9 (all built from this release series).
• SDK v0.3.4 → compatible with backend v0.2.9, client v0.2.9, and pallets/runtime v0.2.9.

Upgrade Guide

None. Upgrading from the previous release should be seamless. All changes included in this release are non‑breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

StorageHub v0.2.8

StorageHub v0.2.8

Summary

StorageHub v0.2.8 is a small, non‑breaking patch release focused on improving observability and tightening concurrency in the client. It adds clearer logging around file and bucket operations (including consistent formatting for file keys and bucket IDs) and narrows the scope of read/write locks around forest and file storage, reducing the risk of long‑held locks during network I/O while preserving existing behaviour.

Components

• Client code: v0.2.8
• Pallets code: v0.2.8
• Runtime code: v0.2.8 (spec_name/spec_version: parachain 1, solochain-evm 1)
• SH Backend Docker image: v0.2.8 (image: ghcr.io/<org>/storage-hub-msp-backend:v0.2.8)
• SH SDK (npm): v0.3.3 (@storagehub-sdk/core, @storagehub-sdk/msp-client)
• types-bundle/api-augment (npm): @storagehub/types-bundle v0.2.8, @storagehub/api-augment v0.2.13

Changes since last tag

Base: 9dcf64a19743e48854504d9251070392f729d371

• Highlights:
  • Client observability – block and forest processing: added log statements at the end of block processing and at the start of applying forest root changes, making it easier to trace the lifecycle of block‑driven state updates in the client (client/src/tasks).
  • Consistent logging of identifiers: unified the logging style for file keys and bucket IDs across MSP/BSP and fisherman tasks, formatting them consistently as hex identifiers (for example file key [0x…] and bucket [0x…]) to simplify searching and correlating logs across services.
  • Safer lock usage in client tasks: refactored several MSP/BSP client tasks to narrow the lifetime of file‑ and forest‑storage read/write locks, ensuring that heavy work (such as proof generation and network I/O) happens outside of locked sections, which reduces contention and helps avoid deadlocks while preserving existing semantics.
• Full diff: https://github.com/Moonsong-Labs/storage-hub/compare/9dcf64a19743e48854504d9251070392f729d371...c7b5a8d53b80f2521eadc7feb5ba6cda1f76f198
• PRs included:
  • None. All changes in this range were committed directly to the release branch without associated GitHub pull requests. The relevant commits are:
    • 56b0ed48dd1bb7e901d28d9b88c29e91b5a301f3 – add logs at the end of block processing.
    • e70c0dbd0d3b065647dd440d84e98ffed9ae5d19 – unify logging style of file keys and bucket IDs.
    • 68c2a02b14a881a33e0e0fa4ffe7daeb59fd15c7 – add log at the beginning of applying forest root changes.
    • c7b5a8d53b80f2521eadc7feb5ba6cda1f76f198 – narrow the scope of read/write locks in client file/forest storage code.

Migrations

RocksDB (File Storage)

• Changes:
  • No new schema changes.
• Action required:
  • None.

RocksDB (Forest Storage)

• Changes:
  • No new schema changes.
• Action required:
  • None.

RocksDB (State store)

• Changes:
  • No schema changes that require migration.
• Action required:
  • None.

Indexer DB (Postgres)

• Migrations:
  • No new indexer migrations were introduced in this release; the migration set is unchanged from v0.2.0.
• How to apply: The indexer service runs migrations automatically on startup. Alternatively run diesel migration run.

Pending extrinsics DB (Postgres)

• Migrations:
  • No new migrations; the pending‑extrinsics schema introduced in v0.2.0 remains unchanged.
• How to apply: The Blockchain Service runs migrations automatically on startup. Alternatively run diesel migration run.

⚠️ Breaking Changes ⚠️

None. Upgrading from the previous release should be seamless. All PRs included in this release are labelled not-breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

Runtime

• Upgrades (spec_version): parachain and solochain-evm remain at spec_version 1; no runtime upgrades were made in this release.
• Migrations: No new runtime storage migrations were added.
• Constants changed: None that require operator action.
• Scripts to run: None specific to this release.

Client

• Behaviour changes:
  • Improved logging for block and forest processing: additional logs now mark the end of block processing and the start of applying forest root changes, providing clearer visibility into when client‑side state transitions driven by blocks actually complete.
  • Consistent identifier formatting: logs across MSP, BSP, and fisherman tasks now consistently format file keys and bucket IDs as hex values in brackets, which helps correlate events across components (for example NSP/BSP upload/download handling, move‑bucket flows, and batch deletions).
  • More precise lock scoping: several client tasks (including upload, download, move bucket, delete bucket/file, and batch deletion handlers) now acquire read/write locks on file and forest storage only for the minimal duration necessary, releasing them before running any network I/O or heavier computation. This reduces contention and the likelihood of deadlocks without changing external behaviour.
• Initialisation changes:
  • None. Existing client configuration (including database URLs and network settings) remains valid and there are no new CLI flags or config fields introduced by this release.

Backend

• Behaviour changes:
  • None in this release. Backend behaviour, HTTP APIs, and configuration remain as described in v0.2.0.
• Initialisation changes:
  • None. Existing backend_config.toml values and deployment scripts continue to apply unchanged.

SDK

• Behaviour changes:
  • None in this release. The SDK packages (@storagehub-sdk/core, @storagehub-sdk/msp-client) remain at v0.3.3, with no API or typing changes compared to v0.2.0.
• Initialisation changes:
  • None. Existing SDK initialisation and configuration code continues to work without modification.

Versions

• Polkadot SDK: polkadot-stable2412-6
• Rust: 1.90 (from rust-toolchain.toml)

Compatibility

• SH Backend v0.2.8 → compatible with pallets/runtime v0.2.8 and client v0.2.8 (all built from this release series).
• SDK v0.3.3 → compatible with backend v0.2.8, client v0.2.8, and pallets/runtime v0.2.8.

Upgrade Guide

None. Upgrading from the previous release should be seamless. All PRs included in this release are labelled not-breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

StorageHub v0.2.7

Summary

StorageHub v0.2.7 is a non‑breaking release that patches an incompatibility between the StorageHub MSP Backend and the DataHaven runtime, so multiaddresses can be correctly SCALE-decoded.

Components

• Client code: v0.2.7
• Pallets code: v0.2.7
• Runtime code: v0.2.7 (spec_name/spec_version: unchanged from v0.2.0)
• SH Backend Docker image: v0.2.7 (image: ghcr.io/<org>/storage-hub-msp-backend:v0.2.7)
• SH SDK (npm): v0.3.3 (@storagehub-sdk/core, @storagehub-sdk/msp-client)
• types-bundle/api-augment (npm): @storagehub/types-bundle v0.2.8, @storagehub/api-augment v0.2.13

Changes since last tag

Base: a923d5c

• Highlights:
  • Runtime update and backend rebuild: the MaxMultiAddressSize of the StorageHub Solochain EVM runtime was changed from 100 to 200 to match DataHaven's configured type. This is because the backend uses this type to SCALE-decode the multiaddresses of the MSP it's connected to, and it was failing as it was trying to decode with a different size.
• Full diff: a923d5c...9dcf64a
• PRs included:
  • #622 fix: 🩹 change MaxMultiAddressSize to match DataHaven's

Migrations

N/A

⚠️ Breaking Changes ⚠️

• None. All PRs included in v0.2.7 are labelled not-breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

Runtime

• Constants changed:
  • The constant MaxMultiAddressSize from the Config of pallet-storage-providers was changed in the solochain EVM runtime from ConstU32<100> to ConstU32<200> to match DataHaven's config.

Backend

• Compilation changes:
  • The new version of the backend was compiled with the aforementioned new runtime constant, which makes the new backend functionally identical to the previous version but with the ability to correctly encode and decode DataHaven's multiaddresses.

Versions

• Polkadot SDK: polkadot-stable2412-6
• Rust: 1.90 (from rust-toolchain.toml)

Compatibility

• SH Backend v0.2.7 → compatible with pallets/runtime v0.2.7 and client v0.2.7 (all built from this release).
• SDK v0.3.3 → compatible with backend v0.2.7, client v0.2.7, and pallets/runtime v0.2.7.

Upgrade Guide

None. Upgrading from the previous release should be seamless. All PRs included in this release are labelled not-breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.