These changes included revisions based on developer feedback, such as adjustments in terminology and the introduction of a new category, LNHANCE, for a combination of opcodes. Additionally, improvements were made by adding links to Bitcoin Improvement Proposal (BIP) drafts and including a rationale column, alongside creating a separate table for evaluations lacking rationale. The enhancements aimed at refining the resource's accuracy and comprehensiveness.

Feedback from Murch and Gloria was highlighted in the bitcoin optech podcast episode 333, which contributed to the ongoing development of a dedicated page listing use cases, prototype links, and primitives utilized. This initiative is open for the addition of more use cases, although it explicitly excludes those enabled solely by OP_CHECKSIGFROMSTACK or in conjunction with other opcodes like LN SYMMETRY. Efforts to verify each entry against spam and fake evaluations were noted, with Rearden receiving moderator permissions on December 8, 2024, to assist in moderation tasks, ensuring the integrity of the information presented.

The discourse also touched upon the diverse viewpoints within the developer community regarding various opcodes and their applicability to covenant proposals. For instance, despite initial belief, SIGHASH_APO garnered limited interest among developers, underlining a preference for opcodes over sighash flags due to the latter's perceived rigidity and lack of flexibility. OP_CHECKSIGFROMSTACK received unanimous support, illustrating its critical role in multiple covenant proposals. However, opcodes such as OP_PAIRCOMMIT, OP_INTERNALKEY, and OP_CHECKCONTRACTVERIFY have not been extensively reviewed, highlighting areas of controversy and potential for further exploration.

Critiques of specific opcodes were shared, shedding light on their limitations and the community's reservations. For example, OP_TXHASH was criticized for its complexity and potential security vulnerabilities, while OP_VAULT faced skepticism over its demand and customized nature for particular use cases. OP_CAT, though capable of enabling complex scripts, raised concerns about inefficient chain utilization and was suggested to be paired with more ergonomic opcodes for broader acceptance.

A call to action for achieving technical consensus was emphasized, with suggestions for adding more rationales to the table, engaging in discussions on the mailing list, organizing workshops, and considering the perspectives of economic nodes. The collaborative effort among developers to refine and enhance the understanding of covenants within the Bitcoin ecosystem was acknowledged, along with an invitation for continued contribution towards establishing a comprehensive, consensus-driven framework for covenant implementation.