Clarity's type checker is meant to ensure that a value's type at analysis matches its type at runtime. The SIP identifies edge cases where that did not hold and proposes fixes in four areas.

Type-checking soundness. According to the SIP, the checker accepted some code whose runtime values didn't match their declared types. Examples:

• Two tuples with different fields could merge into a narrower type, letting a hidden field travel through merge, is-eq and lists.
• fold over an empty sequence could return a value of a type the checker never accounted for.
• Extra arguments passed to a function were never type-checked but were still evaluated, which could trigger an early return. Under the proposal, extra arguments would fail analysis for user-defined and native functions alike.

Analysis and runtime agreement. The analyzer and the runtime sometimes read the same code differently. The proposal would align them:

• let names would be checked against every global name, not only function names.
• A contract could call its own traits during deployment, which currently fails with NoSuchContract.

Consistent value limits. Rules that apply to values built in Clarity would apply to values from any source:

• from-consensus-buff? would return none for tuples with missing, extra or duplicate fields.
• Contract names over 40 bytes would be rejected everywhere, including transaction arguments and NFT post-conditions.

Errors and costs. Some failures cause a transaction to be rejected outright when, per the SIP, it should be included in a block as a failed, fee-paying transaction. The proposal would continue the conversion started in SIP-039. It would also charge costs for all work performed, including type checking of contracts that fail analysis and the identifiers carried by trait and contract principal values.

Under the proposal, analysis changes would apply only to contracts deployed after activation. Runtime changes, such as the new cost charges, would apply to all contracts.

Today, a developer can choose which Clarity version a new contract uses. The SIP proposes removing that choice: after activation, every new contract would deploy with the latest version, starting with Clarity 7.

The SIP's stated rationale is more consistent type checking and runtime behavior across new contracts. Existing contracts would keep the version they were deployed with.

Since epoch 4.0, miners send BTC to the pox-5 contract through an sBTC deposit address built from the sBTC signers' aggregate key. The SIP proposes a new address that requires a set number of sBTC signers to approve, built from each signer’s own key instead of one shared key.

If adopted, the switch would happen in the first reward cycle that starts after epoch 4.1 activates. Technical details are in sbtc#2142.

The SIP is in draft. Before it can activate, it goes through Community Advisory Board review and a community vote. The reference implementation is in progress in the main branch of stacks-core.

Voting dates and the discussion link are not yet set. Questions and feedback are highly encouraged via the SIP's pull request.