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]

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

[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.

[314159265359879]

Looks good to me

[314159265359879]

this sip is Ratified, change this line before merging?

[brice-stacks]

👍 9dfcd34