# Decouple peerDAS Activation from Fusaka Increasing blob capacity is undeniably Ethereum's top priority. While Pectra introduces a 2x capacity increase, many rollups are projecting a 20x increase in blobspace demand by 2025. To support the growth of L2 ecosystems without stifling their momentum, we must proactively scale capacity as demand increases. One critical step toward this is the adoption of [blob parameter-only forks (BPO forks)](https://ethereum-magicians.org/t/blob-parameter-only-bpo-forks/22623), which I believe are essential. In addition to BPO forks, I propose decoupling PeerDAS activation from Fusaka. This would allow us to adjust the hard fork schedule to meet evolving demands. Instead of following a rigid schedule like this (example, not an actual timeline): ``` March (pectra) -> 6 blob target October (fusaka) -> 48 blob target + EOF ``` We could adopt a more incremental approach (again, illustrative timeline): ``` March (pectra) -> 6 blob target June (peerDAS) -> 12 blob target August -> 24 blob target October (fusaka) -> 48 blob target + EOF ``` ## Trade-Offs and Benefits While this approach requires more frequent testing cycles—a clear trade-off—it may ultimately be worth it to ensure Ethereum remains competitive in the evolving rollup ecosystem. An additional advantage is that it enables a more conservative target during the initial deployment of PeerDAS. Conservative targets are particularly valuable when the first deployment carries higher risks compared to subsequent increases in blob capacity. This strategy isn’t new; we’ve taken similar steps in the past (e.g., the transition to Electra and then Pectra). Starting conservatively allows client teams to: * Optimize PeerDAS implementations as we scale. * Identify and address bottlenecks incrementally. * Gather valuable mainnet data to better understand PeerDAS behavior and inform decisions about future blob capacity expansions.