There are several new Clarity features in demand by some vital ecosystem projects, including bridges and marketplaces. This proposal, for Clarity 4, adds three new features that will help enable these applications to be simpler and more secure. I’ve opened a draft SIP with all of the details, but the summary is below.
A new Clarity function to fetch the hash of a contract’s code body. This
enables on-chain contract code validation, for example allowing contract A to
validate that contract B follows a specific template and is therefore safe to
interact with. This is especially useful for enabling bridges and
marketplaces to safely and trustlessly support a dynamic set of assets.
A new set of Clarity functions to allow a contract to set post-conditions
to protect its assets. These allow a contract to safely call arbitrary
external contracts (e.g. passed in as traits) while ensuring that if the
executed code moves assets beyond those specified, the changes will be rolled
back.
A new Clarity function to convert simple values into string-ascii
values. This function will enable developers to easily convert values like bools and principals into their ASCII string representations,
facilitating the generation of string-based messages for interacting with
cross-chain protocols.
A new Clarity keyword to get the timestamp of the current block. This
keyword will allow developers to easily access the timestamp of the block
currently being processed, enabling time-based logic and features in their
smart contracts. This is especially important for DeFi applications.
How will these new Clarity functions (like post-conditions and contract code hashing) impact contract execution costs should developers expect higher gas fees, or will they be optimized to stay lightweight?
Great questions @Farhan. These functions will definitely be optimized to be as lightweight as possible. There will be a new costs contract (costs-4) to define the costs for these new functions. The new post-conditions will be charged costs linearly with respect to the number of conditions that need to be checked. The to-ascii? will be charged with runtime costs linearly with the size of the value being printed. contract-hash? will be very cheap, since the contract hash is already stored, so it is just a single read of 32 bytes, along with a small runtime cost.
Blessed to have SIP author Brice on today’s SIP Call streamed on DeOrganized Media morning show, educating us & taking questions about Clarity 4 SIP
It was a well rounded discussion from many different perspectives.
You can watch the replay via this link: 
CABs review should be starting soon. Public voting TBC.
You can contribute by jumping into the Github PR reviewing the SIP too: 