This method diverges from traditional practices by mandating that softforked opcodes are executed within a subprogram that is designed to either return a null value or abort entirely. This design choice allows these opcodes considerable flexibility within the confines of the subprogram, enabling them to perform various operations as long as the overall subprogram adheres to the "verify" behavior criterion.

A specific example that illustrates this concept involves the new (coinid P H A) operation, which is capable of calculating and returning a hash value. However, the utilization of this operation prior to an official hardfork is restricted. It can only be employed within a program structured to ensure verification, such as through a specific pattern like:

(softfork COST 0 (q a (i (= (coinid P H A) X) (q q nil) (q x))) 1 ) 

Within this structure, parameters P H A X are derived from the external environment. The enclosed code within the softfork construct validates whether X has been accurately calculated, manually aborting if discrepancies are found through a designated pattern. Subsequently, code external to the softfork can safely interact with the X value, now verified to accurately match P H A, thus incorporating an element of trust into otherwise untrusted data. This methodology underscores a significant evolution in softfork management, emphasizing security and verification within blockchain operations.