SIP-039: Clarity 5 and Epoch 3.4

[brice-stacks]

This specifies a smaller hard-fork needed to solve some incorrect behavior in Clarity. These changes are consensus-breaking but they do not change the intended behavior described in previous SIPs. They only fix bad behavior or under-specified behavior that makes the network worse the way it is currently implemented. For those reasons, I think this should not require a community vote, but just Technical CAB and Steering Committee approvals.

[brice-stacks]

There are a few more changes that we are considering adding into this epoch, so I'm not requesting the Technical CAB review quite yet. Will update here when it is final. 🙏

[jcnelson]

Can you state what is wrong today?

[jcnelson]

This looks great to me! Will approve once the (very minor) comments are addressed

[wileyj]

@brice-stacks can you move the files into the expected structure?
./sips/sip-clarity5/sip-clarity5.md -> ./sips/sip-039/sip-clarity5.md

[Hero-Gamer]

This specifies a smaller hard-fork needed to solve some incorrect behavior in Clarity. These changes are consensus-breaking but they do not change the intended behavior described in previous SIPs. They only fix bad behavior or under-specified behavior that makes the network worse the way it is currently implemented. For those reasons, I think this should not require a community vote, but just Technical CAB and Steering Committee approvals.

Thanks @brice-stacks for putting this together — I agree that most (if not all) of these changes appear to address incorrect or underspecified behavior rather than introducing new features.

That said, I’d like to raise a governance clarification point.

This SIP is explicitly marked as:

• Type: Consensus
• Layer: Consensus (hard fork)

Even if the intent is purely corrective, these changes are still consensus-breaking and alter execution semantics (e.g., secp256r1-verify, rejectable transaction handling, stack depth limits). In some cases, they may also affect miner behavior or economic dynamics.

My question is less about whether these changes are reasonable (they likely are), and more about precedent:

Should all consensus-breaking hard forks require broader community ratification, even if they are framed as bug fixes or specification clarifications?

If we establish that certain classes of consensus changes do not require community vote, it would be helpful to explicitly define that boundary:

• What qualifies as a “bug fix” exempt from vote?
• Are parameter changes (like stack depth increases) included in that category?
• How do we handle cases where real-world contract behavior may have relied on existing implementation quirks?

Clarifying this now would strengthen governance norms long term and avoid ambiguity in future upgrades.
(At the moment, the process is clearer for catastrophic chain failure or critical bug fixes (see #10), where a community vote may not be required — as was the case with SIP-22, SIP-23, and SIP-24.
However, we are less clear when it comes to non-urgent, consensus-breaking bug fixes. It would be helpful to clarify whether these types of changes require a community vote, and if not, under what criteria they are exempt.)

Happy to hear thoughts from others as well - I think this is a valuable discussion for Stacks governance overall.

[Hero-Gamer]

A couple of things chatting with GPT I picked up, that say not really bug fix, and might not be absolutely "do not change the intended behavior" - or maybe they are, maybe just help me to understand more?

3️⃣ Rejectable transactions → includable errors

This one is more governance-sensitive.
This changes how the network handles invalid txs:
Previously: rejected at mempool/block inclusion level
Now: includable, but error at execution
That changes miner behavior, mempool dynamics, and possibly fee capture.
**That’s not just a VM bug fix — it changes economic behavior.**
Even if it’s better design, it is a consensus-level policy shift.

4️⃣ Increased stack depth (64 → 128)
This one is clearly **not fixing a bug.**
It’s:
**A parameter change**
Not specified in prior SIPs
Previously chosen for resource limits
That’s a consensus parameter adjustment.
It may be safe and reasonable — but it’s not strictly a bug fix.

[behaddy]

This specifies a smaller hard-fork needed to solve some incorrect behavior in Clarity. These changes are consensus-breaking but they do not change the intended behavior described in previous SIPs. They only fix bad behavior or under-specified behavior that makes the network worse the way it is currently implemented. For those reasons, I think this should not require a community vote, but just Technical CAB and Steering Committee approvals.

Thanks @brice-stacks for putting this together — I agree that most (if not all) of these changes appear to address incorrect or underspecified behavior rather than introducing new features.

That said, I’d like to raise a governance clarification point.

This SIP is explicitly marked as:

• Type: Consensus

• Layer: Consensus (hard fork)

Even if the intent is purely corrective, these changes are still consensus-breaking and alter execution semantics (e.g., secp256r1-verify, rejectable transaction handling, stack depth limits). In some cases, they may also affect miner behavior or economic dynamics.

My question is less about whether these changes are reasonable (they likely are), and more about precedent:

Should all consensus-breaking hard forks require broader community ratification, even if they are framed as bug fixes or specification clarifications?

If we establish that certain classes of consensus changes do not require community vote, it would be helpful to explicitly define that boundary:

• What qualifies as a “bug fix” exempt from vote?

• Are parameter changes (like stack depth increases) included in that category?

• How do we handle cases where real-world contract behavior may have relied on existing implementation quirks?

Clarifying this now would strengthen governance norms long term and avoid ambiguity in future upgrades.

(At the moment, the process is clearer for catastrophic chain failure or critical bug fixes (see #10), where a community vote may not be required — as was the case with SIP-22, SIP-23, and SIP-24.

However, we are less clear when it comes to non-urgent, consensus-breaking bug fixes. It would be helpful to clarify whether these types of changes require a community vote, and if not, under what criteria they are exempt.)

Happy to hear thoughts from others as well - I think this is a valuable discussion for Stacks governance overall.

I would also like to have some explicit clarity on when a consensus breaking / hard fork SIP does or doesn't have to be ratified via community vote.

Purely to avoid vectors of attack.

On the other side, do we have a 'closed' / non viewable SIP process for vulnerabilities/exploits, that require urgent action?

[brice-stacks]

Yeah, I agree. We definitely don't want SIP authors like myself to just declare that their SIP doesn't require a vote, but we also don't want to have to force a vote for every small change. I'm not sure exactly how to define the rules there, but there certainly needs to be clear rules.

[brice-stacks]

It may be safe and reasonable — but it’s not strictly a bug fix.

Right, that's why I say "The implementation for this SIP should only resolve problems in the current Clarity implementation or make beneficial changes to under-specified aspects of the Clarity language and virtual machine (VM)." That limit is not specified anywhere, so the current choice was not defined anywhere, it was just an early implementation choice.

[wileyj]

This specifies a smaller hard-fork needed to solve some incorrect behavior in Clarity. These changes are consensus-breaking but they do not change the intended behavior described in previous SIPs. They only fix bad behavior or under-specified behavior that makes the network worse the way it is currently implemented. For those reasons, I think this should not require a community vote, but just Technical CAB and Steering Committee approvals.

Thanks @brice-stacks for putting this together — I agree that most (if not all) of these changes appear to address incorrect or underspecified behavior rather than introducing new features.

That said, I’d like to raise a governance clarification point.

This SIP is explicitly marked as:

• Type: Consensus
• Layer: Consensus (hard fork)

Even if the intent is purely corrective, these changes are still consensus-breaking and alter execution semantics (e.g., secp256r1-verify, rejectable transaction handling, stack depth limits). In some cases, they may also affect miner behavior or economic dynamics.

My question is less about whether these changes are reasonable (they likely are), and more about precedent:

Should all consensus-breaking hard forks require broader community ratification, even if they are framed as bug fixes or specification clarifications?

If we establish that certain classes of consensus changes do not require community vote, it would be helpful to explicitly define that boundary:

• What qualifies as a “bug fix” exempt from vote?
• Are parameter changes (like stack depth increases) included in that category?
• How do we handle cases where real-world contract behavior may have relied on existing implementation quirks?

Clarifying this now would strengthen governance norms long term and avoid ambiguity in future upgrades. (At the moment, the process is clearer for catastrophic chain failure or critical bug fixes (see #10), where a community vote may not be required — as was the case with SIP-22, SIP-23, and SIP-24. However, we are less clear when it comes to non-urgent, consensus-breaking bug fixes. It would be helpful to clarify whether these types of changes require a community vote, and if not, under what criteria they are exempt.)

Happy to hear thoughts from others as well - I think this is a valuable discussion for Stacks governance overall.

Indeed this is something that needs to be clarified. however, since the current text of sip-000 is already ratified and any changes made there will likely not impact this SIP - we're left with applying the standards that are set currently.

@behaddy @Hero-Gamer - This is something i have been working to codify in an update to sip-000, but i think it's out of scope for this PR (but i have indeed been thinking about it - there are definitely cases where a hard fork is needed to change/fix something that may not require a public vote).

The reasoning for the activation section in this PR, which i shared with @brice-stacks was from the text here: https://github.com/stacksgov/sips/blob/main/sips/sip-000/sip-000-stacks-improvement-proposal-process.md#voting-on-technical-sips

Even though we have usually held a public vote for hard forks, I felt in this case based on the above language and there being no breaking changes or backward compatibility issues - a CAB vote is sufficient. I would also address precedent here - there have been hard forks in the past where a public vote was not held, only a CAB vote.

Typically, we have left these decisions up to SIP authors (for better or worse), and anyone may argue that this does require a public vote (and even suggest that change to this SIP). But, based on the current sip-00 requirements, I don't think it's a hard requirement.

In my opinion, because the changes here are backwards compatible, are meant to resolve open issues in Clarity, and ultimately are "opt-in", I would argue that a public vote here should not be a hard requirement. But again, each proposal should be scrutinized for when a public vote should be held (i.e. a hard fork to change POX, i would argue that a public vote should be held since it would directly impact any POX users), but there really isn't something we can point to that tells us when a public vote is required vs when it's suggested vs when it's not needed.