SIP-042: Removal of at-block

[francesco-stacks]

This SIP proposes the removal of at-block starting from epoch 3.4

[Bongulielmi]

This SIP is well-motivated and clearly structured. The removal of at-block starting in Epoch 3.4 is a sound decision — the unbounded historical lookback it requires is the primary blocker for MARF pruning, and with chainstate already approaching 1 TB (growing ~2.73 GB/day), addressing this is increasingly urgent for node operator sustainability.

A few things I particularly appreciate about this proposal:

• Clear enforcement strategy across Clarity versions: The distinction between static analysis rejection for new deployments and RuntimeCheckError / AtBlockUnavailable for existing Clarity 1–4 contracts is well thought out. It ensures no ambiguity in how the transition is handled.
• • Minimal on-chain impact: The observation that at-block usage on mainnet is limited provides good confidence that this is a low-disruption change relative to the significant infrastructure benefits it enables.
• • Epoch gating is clean: Enforcing AtBlockUnavailable exclusively in Epoch 3.4+ while preserving the validity of pre-activation blocks is the right approach — no retroactive invalidation of previously valid state.
    The SIP is well-scoped, the design goals are clearly articulated, and the backwards compatibility trade-off is justified. Looking forward to seeing this move through the process alongside the reference implementation in stacks-core#6937.

LGTM overall — nice work on this one.

[hugo-stacks]

"deprecation" sounds like it will still work but will be removed in a future versions and is discouraged, while I think the intent is the "removal of at-block"

[francesco-stacks]

@hugo-stacks good point! I changed the wording in the SIP!

[PerrinoProperties]

What is the incentive for miners, stacking pools, core entities to maintain a full archival node?

[Hero-Gamer]

"Any deployed contract that calls at-block will begin receiving runtime errors after Epoch 3.4 activates"
Looking at this SIP alone, throughout the SIP text it mentioned multiple times "Epoch 3.4" - however it does not mention approximate date or block. I think it would be helpful for the reader to know the estimate, so builders can understand when they must migrate by?

[314159265359879]

The SIP is structurally strong and near publication quality. The edits are primarily stylistic and format-compliance improvements. I have added comments and suggestions in line.

Strengths

• Clear motivation
• Precise specification
• Well-structured sections
• Good linkage to implementation

Primary improvements needed

• Preamble formatting consistency
• Clarify MARF explanation
• Replace conversational phrases
• Improve normative wording in the specification

[francesco-stacks]

"Any deployed contract that calls at-block will begin receiving runtime errors after Epoch 3.4 activates" Looking at this SIP alone, throughout the SIP text it mentioned multiple times "Epoch 3.4" - however it does not mention approximate date or block. I think it would be helpful for the reader to know the estimate, so builders can understand when they must migrate by?

@PerrinoProperties this SIP does not address archival node implementation or details, its scope is limited to removing at-block as a prerequisite for future chainstate pruning. That said, take this with a grain of salt as this hasn't been formally discussed, but I don't expect any specific incentives for running an archival node. I expect Stacks Labs to likely continue to maintain archival nodes, similar to the current bootstrapping nodes, but it will be at the discretion of each operator. If an operator needs their node to answer historical queries, they will still be able to run a full archival node. the difference is that retaining the full history will no longer be a consensus requirement (as it currently is because of at-block).

[francesco-stacks]

"Any deployed contract that calls at-block will begin receiving runtime errors after Epoch 3.4 activates" Looking at this SIP alone, throughout the SIP text it mentioned multiple times "Epoch 3.4" - however it does not mention approximate date or block. I think it would be helpful for the reader to know the estimate, so builders can understand when they must migrate by?

@Hero-Gamer Good point! The activation block height is 943,000, targeting March 30, 2026. These are specified in SIP-039 (PR #256), which this SIP rides on. Since SIP-042 activates if and only if SIP-039 activates, I think it's best to keep the activation details in one place rather than duplicating them here. We follow the same approach with SIP-040 (PR #257), which is also a rider on SIP-039.

[314159265359879]

I see the comments I made addressed, looks good for editor sign off to me.

[Rapha-btc]

1. With ~1 TB chainstate and 95% being historical MARF data, what's the projected node
   storage footprint after pruning is implemented?
2. Does a pruned MARF also improve contract read/write performance, or is the benefit
   purely storage?

[wileyj]

1. With ~1 TB chainstate and 95% being historical MARF data, what's the projected node
   storage footprint after pruning is implemented?
2. Does a pruned MARF also improve contract read/write performance, or is the benefit
   purely storage?

good questions! but i think it's out of scope for this sip. i would refer to the linked issue and raise the questions there for clarity.

the removal of this function is a small part of the storage improvement work, but is a blocker to any meaningful change. i also suspect the performance wouldnt have any meaningful impact, outside of lower system io.