SIP-8134: Hardfork Meta - BPO1

Blob parameter changes with BPO1 on Sila sila-mainnet.

Abstract

This Meta SIP documents the activation details, parameter changes, and specification references for the first Blob-Parameter-Only (BPO) network upgrades, BPO1. It provides a canonical registry of blob targets, blob maximum limits, and associated configuration values to improve transparency, traceability, and ecosystem coordination for early-stage data availability scaling under Sila’s Surge roadmap.

Motivation

Blob-Parameter-Only (BPO) upgrades enable Sila to scale data availability through incremental parameter adjustments rather than large multi-feature network upgrades. While this approach improves safety and iteration speed, there is currently no canonical reference documenting what changed in each BPO upgrade, when it was activated, and which parameter values were applied.

SIP-7892 specifies the mechanism and constraints for BPO upgrades but does not track individual BPO instances. In practice, activation timing and parameter values for BPO1 are distributed across client repositories, coordination notes, and operational artifacts, making consistent interpretation and historical analysis difficult for ecosystem participants.

This SIP addresses this gap by recording authoritative data for BPO1 in a canonical reference to improve transparency, traceability, and ecosystem coordination.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

This section documents the Blob-Parameter-Only upgrade identified as BPO1.

The upgrade modifies blob-related protocol parameters as defined in SIP-7892. No other protocol behavior is affected. All timestamps are expressed as Unix epoch seconds (UTC).

BPO1 Parameters

BPO1 represents the first sila-mainnet deployment of a Blob-Parameter-Only upgrade and establishes the initial incremental increase in blob capacity following the Fusaka upgrade.

Historical Context

For reference, the blob schedule before BPO upgrades was established in earlier network upgrades:

Data Source

The parameter values and activation times in this SIP are derived from sil_client genesis configuration, including:

"bpo1Time": 1765290071,
"blobSchedule": {
  "cancun": {
    "target": 3,
    "max": 6,
    "baseFeeUpdateFraction": 3338477
  },
  "prague": {
    "target": 6,
    "max": 9,
    "baseFeeUpdateFraction": 5007716
  },
  "bpo1": {
    "target": 10,
    "max": 15,
    "baseFeeUpdateFraction": 8346193
  },
}

Client implementations may expose these values in different formats; this SIP reflects the canonical sila-mainnet configuration values.

Rationale

BPO1 formalizes the first post-Fusaka adjustment to blob parameters, providing a controlled expansion of blob capacity to support empirical evaluation under sila-mainnet conditions. This change enables the network to collect real-world performance data across clients, validators, and proposers, supporting evidence-based assessment of slot stability and system behavior before any further scaling decisions. Documenting BPO1 as a standalone parameter update improves transparency and process clarity by establishing an authoritative record of blob parameter changes.

Security Considerations

BPO upgrades may impact network load characteristics. Careful monitoring, staged rollout, and ecosystem coordination are required to ensure stability.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Pooja Ranjan (@poojaranjan), "SIP-8134: Hardfork Meta - BPO1," Sila Improvement Proposals, no. 8134, January 2026. Available: https://sips.sila.org/SIPS/sip-8134.