Code change:
NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call

Related discussion:
text: <del> A CoMETRE Profile and Tree Algorithm for the Confidential Consortium Framework </del> <ins> COSE Receipts with CCF </ins> draft-birkholz-cose-cometre-ccf-profile-latest Abstract This document defines a new verifiable data structure type for COSE <del> Signed Merkle Tree Proofs specifically designed for implementations that rely on Trusted Execution Environments (TEEs) to provide stronger tamper-evidence guarantees. </del> <ins> Signed Merkle Tree Proofs specifically designed for transaction ledgers produced by Trusted Execution Environments (TEEs), such as the Confidential Consortium Framework (CCF) to provide stronger tamper-evidence guarantees. </ins> 1. The Concise Encoding of Signed Merkle Tree Proofs (CoMeTre) I- D.steele-cose-merkle-tree-proofs defines a common framework for defining different types of proofs, such as proof of inclusion, about <del> verifiable data structures (also abbreviated as "logs" in this document).  For instance, inclusion proofs guarantee to a verifier that a given serializable element is recorded at a given state of the log, while consistency proofs are used to establish that an inclusion proof is still consistent with the new state of the log at a later time. In this document, we define a new type of log, associated with the Confidential Consortium Framework (CCF) ledger.  Compared to RFC9162, the leaves of CCF trees carry additional opaque information that is used to verify that elements are only written by the Trusted Execution Environment, which addresses the persistence of committed transactions that happen between new signatures of the Merkle Tree root. </del> <ins> verifiable data structures (VDS).  For instance, inclusion proofs guarantee to a verifier that a given serializable element is recorded at a given state of the VDS, while consistency proofs are used to establish that an inclusion proof is still consistent with the new state of the VDS at a later time. In this document, we define a new type of VDS, associated with the Confidential Consortium Framework (CCF) ledger.  This VDS carries indexed transaction information in a binary Merkle Tree, where new transactions are appended to the right, so that the binary decomposition of the index of a transaction can be interpreted as the position in the tree if 0 represents the left branch and 1 the right branch.  Compared to RFC9162, the leaves of CCF trees carry additional internal information for the following purposes: To bind the full details of the transaction executed, which is a super-set of what is exposed in the proof and captures internal information details useful for detailed system audit, but not for application purposes. To verify that elements are only written by the Trusted Execution Environment, which addresses the persistence of committed transactions that happen between new signatures of the Merkle Tree root. </ins> 1.1.