# Abstract
The goal of this version of Clarity is not to add any new features, but to resolve known issues with existing functionality, specifically those that require a hard-fork to change. 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).
# Introduction
This SIP intends to solve the known issues in the implementation of the Clarity VM, without making any changes to its intended behavior.
# Specification
## Resolve the discrepancy in `secp256r1-verify` described in SIP-035
In Clarity 5 and above, `secp256r1-verify` will no longer double-hash its input.
See [SIP-035]( sips/sips/sip-035/sip-secp256r1-verify.md at main · stacksgov/sips · GitHub ) for details.
## Runtime error when passing an empty buffer to `from-consensus-buff?` (see issue [#6683](Runtime error when doing `from-consensus-buff?` with an empty buffer · Issue #6683 · stacks-network/stacks-core · GitHub))
Beginning in Clarity 5, computing the cost of passing an empty buffer to `from-consensus-buff?` will no longer trigger a runtime error. Instead, the cost will be charged appropriately, and the expression will return `none`, as originally intended.
## Bug with `burn-block-height` inside an `at-block` expression (see issue [#6123](Fix bug with `burn-block-height` inside an `at-block` expression · Issue #6123 · stacks-network/stacks-core · GitHub))
In Clarity 5 and above, `burn-block-height` will return the correct value when used inside of an `at-block` expression.
## Increased stack depth
Currently, the Clarity VM limits the call stack of a transaction execution to a depth of 64 and several user applications have been hitting this limit recently.
This value was not specified in any previous SIPs, but was chosen to constrain memory usage by the VM. Upon further testing, it has been determined that this value can safely be increased to 128 without imposing unreasonable requirements on Stacks node runners. Effective in epoch 3.4, the stack depth will be set to 128.
## Rejectable transactions
Several kinds of errors have been avoided in the Clarity VM via a soft-fork mechanism, causing transactions that trigger these problematic situations to be rejected, not allowed to be included in a block. This strategy is useful for quickly patching issues without requiring a hard-fork. However, once the soft-fork is in place, the next time a hard-fork is executed, these errors can all be transitioned to errors that can be included in a block. This is much better for the network, since not including a transaction in a block has several downsides:
- Miners cannot charge a fee for processing the transaction
- Users may be confused as to why their transaction is not being included, causing that transaction and all later transactions (with higher nonces) to stall
- These unmineable transactions remain in the mempool, unprocessed, until they age out
With the upgrade to epoch 3.4, all known reachable “rejectable” errors, will become includable errors.