Canonicalization Failures as a Recurring Vulnerability Class: Representation Divergence in Cryptographic Systems and Its Avoidance

Arslan Br\"omme

REVIEW 3 major objections 5 minor 23 references

Canonicalization Failures as a Recurring Vulnerability Class: Representation Divergence in Cryptographic Systems and Its Avoidance

T0 review · 3 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper argues that a large family of cryptographic failures are one vulnerability class with a single root: a violated uniqueness condition between semantic objects and their byte representations.

desk verdict A careful, honest systematization with a genuinely useful checklist; the two-direction taxonomy is sound, but the I-break direction has thinner real-world support than the grid suggests. read the letter →

arxiv 2608.06508 v1 pith:7DGETFWF submitted 2026-08-06 cs.CR

Arslan Brömme This is my paper · ORCID

classification cs.CR

keywords canonicalizationrepresentationdivergenceuniquenessconditionmalleabilitysentinelcollapsetransactionbyte-inputinvariancesecurityreviewchecklist

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper is a systematization, not a new attack. It argues that a string of expensive cryptographic failures, from ECDSA signature malleability and the Nomad bridge's zero-value collapse to non-deterministic transaction encodings, message malleability, and hash-chain malleability, are instances of one vulnerability class with a common root. The root is a violated uniqueness condition between semantic objects and their byte representations, and it breaks in only two directions: several valid byte strings denote one object, or one byte string denotes several objects. The paper organizes these failures into a grid of two break directions across value, structure, and state levels, connects the pattern to representation theory, and turns it into a review procedure, the canonicalization obligation, that asks whether a canonical normal form is enforced before hashing, signing, or storing. If the thesis holds, enforcing uniqueness of representation can reduce a recurring exploitability class without claiming to deliver full cryptographic security.

What carries the argument

The key machinery is the uniqueness condition $\mathrm{dec}^{-1}(\{x\})=\{\mathrm{enc}(x)\}$, the requirement that exactly one valid code exist for each semantic object. It does the work of dividing every representation-divergence failure into exactly two break directions, surjectivity (S-break: multiple codes per object) and injectivity (I-break: one code for multiple objects), relative to a fixed valid-code set and equality relation. Around this identity the paper places a two-level grid of value, structure, and state, the distinction between composition canonicity and value canonicity for structured data, and an operational model of a canonicalization boundary: hashing or signing before the canonicalizer yields the S-break, while an ambiguous decoder or storage default yields the I-break. The derived canonicalization obligation, 'Sign what you compare, and compare what you sign, after canonicalization,' translates the mathematical condition into five checkable review steps: identify the bound bytes, name the downstream equality, check whether it is byte equality, require a computable and implemented normal form, and enforce it before binding.

What would settle it

A single documented cryptographic failure that satisfies the paper's definition, a semantic object with multiple byte codes or a byte code with multiple meanings feeding a security decision, but that cannot be classified as an S-break or I-break once the equality relation is fixed, would falsify the claim that the two directions exhaust the class. Concretely, find a case where the uniqueness condition is enforced before binding and representation divergence still produces the failure, or an incident where an unset storage slot returns a non-default error rather than a sentinel and yet the same semantic collapse occurs.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central claim is that the failures are not a list but a class. In the conclusion the author states that every incident traces back to 'the violation of a single uniqueness condition, relative to a fixed equality relation, in one of two directions, that is, multiple codes for one object or one code for multiple objects.' The formal anchor is the uniqueness condition $\mathrm{dec}^{-1}(\{x\})=\{\mathrm{enc}(x)\}$, requiring each semantic object to have exactly one valid byte code; breaking it breaks one half of the encoding bijection. Object-side multiple representation, the S-break, is several codes decoding to the same object, as in ECDSA's $(r,s)$ and $(r,n-s)$. Code-side semantic collapse, the I-break, is one code decoding to several meanings, as when an unset EVM storage slot returns $\mathtt{bytes32}(0)$ and that same zero value was initialized as a confirmed state in Nomad. The paper works both cases through the same four-step grid, contrasts them with the Wormhole incident as a boundary case, surveys cross-ecosystem evidence including Cosmos, EIP-712, ABI decoding, zero-knowledge aliasing, and Git hash-chain malleability, and derives a canonicalization obligation plus a review sequence from the framework.

Load-bearing premise

The framework assumes each incident can be modeled as a fixed encoder and decoder pair with a fixed, nameable semantic equality relation; if an application's equality is implicit or scattered across code paths, the two-direction classification and its checklist cannot be applied mechanically.

Editorial extensions

If this is right

If the class is real, evaluating a protocol for canonicity becomes a five-step reviewable question rather than a hunt for local incident patterns.
Enforcing the low-S normal form for ECDSA removes the mirrored-signature malleability class without changing the cryptographic scheme.
Separating an absence sentinel from the valid value range, by invariant rather than by default, removes the zero-value collapse class that struck Nomad.
Field types such as strings and number-strings carry high canonicity risk unless a normal form is enforced before the structure hash, while fixed-width integers and atomic bytes32 values are low-risk.
The same obligation carries across ecosystems: Cosmos's non-deterministic value encoding, Git's hash-chain malleability, and EIP-712 field-value ambiguity are all cases where binding happened before canonicalization.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper's documented asymmetry, in which almost every named local term covers S-breaks while I-breaks have no established ecosystem name, suggests that default-value and error-return collapses are an under-searched zone; incident reviews should specifically hunt for unset-storage defaults that coincide with valid states.
The rejection-versus-recomputation distinction implies a testable engineering rule beyond the paper's checklist: a system that silently normalizes non-canonical inputs may still be vulnerable through the acceptance path, so acceptance tests should submit non-canonical encodings and assert rejection, not just that the canonical form works.
The canonicalization obligation's requirement that the normal form be computable and implemented suggests that when a downstream equality has no practical normal form, such as arbitrary case-insensitive strings, the safer resolution is to keep that equality out of the security path entirely and compare byte-wise only, rather than attempting a partial normalization.
The framework predicts that each new cryptographic ecosystem will independently rediscover the same two directions; a forward-looking audit methodology could scan new protocols for the exact grid cells, especially the I-break at the state level, before large losses occur.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Read this if you do security reviews of signing or hashing code. It gives you a usable vocabulary and a five-step checklist for a real failure class. It is not a new technical result, and it says so itself; the contribution is the systematization, and that systematization is mostly sound.

What is actually new: the cross-ecosystem grid in Table 3, the review checklist in Section 7.2, and the EIP-712 field-value canonicity observation in Section 6.4. The two break directions are a restatement of the bijection property, but the discipline of applying them across Bitcoin, Cosmos, EVM, ZK, and Git is useful. The worked ECDSA and Nomad cases are accurate and carefully delimited. The Python tests are executable and substantiate the claims they make; the Solidity is compiled but not executed, and the paper says so. The checklist is the strongest part: concrete, mechanically applicable, and falsifiable in a review.

Soft spots, in proportion. The empirical grid relies on third-party incident write-ups the author did not independently reproduce. That is normal for a systematization, but it means Table 3 is a survey, not evidence. The stress-test point about Polygon MRC20 is fair: the paper classifies ecrecover's zero-address fallback as an I-break, but the loss also required a missing balance check, and one can read the zero-address handling as a simple validation gap, the Wormhole pattern the paper excludes. The paper already discloses the multi-causality and the sparseness of I-break evidence, and explicitly calls the I-direction a search zone. So the concern weakens the empirical breadth but does not damage the taxonomy: the dichotomy is exhaustive by construction. The dependency on the same-author companion paper for the computability boundary is a minor annoyance; the checklist does not actually need that boundary to be useful.

Bottom line: this is a careful, honest systematization. It deserves a serious referee. The main revision asks should be to re-examine the Polygon classification and either defend it as an I-break or move it to a borderline cell, and to temper the wording so the unification claim is clearly read as a taxonomy with thin I-direction evidence. I would accept it with revisions.

Referee Report

3 major / 5 minor

Summary. This manuscript proposes that a wide range of cryptographic failures—transaction malleability, non-deterministic value encoding, message malleability, and sentinel/default-value collapses—are instances of a single representation-theoretic vulnerability class. The class is defined by violation of the uniqueness condition dec^{-1}({x})={enc(x)} relative to a fixed encoder/decoder pair and a fixed semantic equality relation. Violations occur in exactly two directions: object-side multiple representation (S-break, multiple codes per object) and code-side semantic collapse (I-break, one code for multiple objects). The paper works out ECDSA malleability and the Nomad bridge incident as examples of the two directions, uses the Wormhole incident as a boundary case outside the class, places additional incidents in a grid by break direction and level (value, composition, state), and derives a review procedure called the canonicalization obligation with a five-step checklist. The authors explicitly limit their central claim to 'canonicalization could reduce the exploitability of a failure class' and disclaim that canonicalization alone would have prevented any concrete loss. The appendix contains executable Python tests, compilable Solidity code, and didactic minimal examples.

Significance. The systematization is useful and the worked cases are carefully delimited. The paper's strengths include honest boundary drawing: Section 4.3 and Section 8 explicitly exclude validation gaps and non-deterministic arithmetic, and Section 9 lists limitations including the dependence on a specified equality relation and the multi-causal nature of real incidents. The appendix artifacts are a concrete plus: the Python tests are executable and substantiate the ECDSA mirror property and the Nomad sentinel collapse, and the Solidity code is compilable. The two-direction dichotomy is a definitional consequence of the bijection condition and therefore cannot be wrong; the value of the paper lies in the ordering device, the worked cases, and the review procedure. The main risk is evidential: the cross-ecosystem grid in Table 3 rests on third-party classifications, and the I-direction's real-world support is thinner than the S-direction's. If the MRC20 classification and the outsourced formal foundation are resolved, this could become a solid systematization contribution.

major comments (3)

[Section 6.1 / Table 3] The classification of Polygon MRC20 as a code-side semantic collapse (I-break) is not sufficiently justified. The paper states that ecrecover returns address(0) for an invalid signature and that this return value was not checked, so 'the one code address(0) here carried at once the meaning "signature error" and that of a regular address value.' For this to be an I-break under the paper's own definition, address(0) must be a valid code for a legitimate semantic object in the application's equality relation. If no valid signature can recover the zero address, then address(0) is merely an error marker, and the exploit is a missing validation of an error return—exactly the Wormhole-type validation gap that Section 8 explicitly excludes. The same section also admits that the full loss 'became possible only through a second, independent gap, a missing balance check in the transfer path, which the operators themselves name as the core cause.' Since the I-direction's real-world evidence consists of Nomad and MRC20, reclassification would leave only one documented I-break incident and would materially weaken the asymmetry discussion in Section 6.2 and the empirical claim that both break directions recur. The authors should either prove or cite a proof that address(0) is in the image of valid recoveries and carries two distinct meanings in the application's equality relation, or reclassify MRC20 as a borderline case and adjust the wording accordingly.
[Section 2 / Section 6.3 / Section 7.2] The formal foundation of the paper—the uniqueness condition, byte-input invariance, and the claim that canonicalization is in general undecidable—is imported entirely from the companion paper [1] and is not stated or proved in this manuscript. Section 6.3 says that the undecidability and the computability boundary 'is the subject of the foundational paper [1], yet in the security literature on these incidents this boundary is not drawn.' Since the paper explicitly claims as its second contribution a bridge to this computability-theoretic foundation, the reader cannot verify that bridge without consulting [1]. The manuscript should either include the relevant definitions and the precise theorem used, or provide a proof sketch in an appendix, so that the 'foundational bridge' claim is checkable on its own.
[Table 3 / Section 6.2] The cross-ecosystem evidence in Table 3 is assembled from third-party audits, blog posts, and recent preprints (e.g., the Verichains ABI analysis, the Git hash-chain-malleability preprint, Cosmos ADR-076, and the zkSecurity aliasing post). The paper does not independently reproduce any of these analyses, yet Section 6.2 states that 'the actual finding becomes visible when one looks beyond a single ecosystem.' For a systematization contribution this evidence model is acceptable only if the provenance and confidence of each entry is explicit. The table currently gives equal weight to all entries, while only the ECDSA and Nomad cases are worked out in detail in the body. A provenance column (e.g., 'verified by the authors' versus 'taken from source') and a sentence in Section 6.2 distinguishing independently reproduced cases from reported cases would make the evidential basis precise and prevent the table from overstating the empirical breadth of the unification claim.

minor comments (5)

[Section 9] The limitation titled 'Dependence on a specified equality' is important but appears only in the limitations section; since Section 7.2's review procedure presupposes that the downstream equality can be named, the paper should state this precondition at the beginning of Section 7.1 as well.
[Section 6.2] The phrase 'the actual finding becomes visible' is too strong given the provenance caveat in Table 3; consider replacing it with 'the consolidation becomes visible' or similar.
[Table 2] The open cell for object-side multiple representation at the state/storage level is an interesting negative observation; the paper would benefit from a sentence stating explicitly whether a search for such cases was performed.
[Appendix B.3] The recommended fix in `verifyAndConsume` rejects address(0) as a signer; this is consistent with the MRC20 discussion, but the paper should clarify that rejecting an error sentinel is also standard validation, and explain precisely how this differs from the Wormhole-type validation gap.
[Title] The title contains 'A voidance' with an apparent line-break artifact; this should be corrected to 'Avoidance' in the final version.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: the S/I taxonomy is a definitional ordering device, explicitly framed as systematization; only minor reliance on the author's companion paper for terminology.

full rationale

The paper's central claim is a classification claim, not a derived prediction. The two break directions follow from the definition of the uniqueness condition (dec^{-1}({x})={enc(x)}) in Section 2 and are presented as an organizing grid, not as an empirically fitted result. The case studies are classified using independently documented incidents (EIP-2, Nomad post-mortems, Immunefi, etc.), and the canonicalization-guided fixes are logical consequences of enforcing the stated normal forms, carefully delimited in Section 4 as necessary but not sufficient. The only self-referential element is the companion paper [1], cited for the terminology of canonical encoding, byte-input invariance, and the computability boundary; the taxonomy and review procedure in Sections 2 and 7 are stated self-containedly, so the self-citation is not load-bearing. The potential fragility of the Polygon MRC20 I-break classification (Section 6.1) is an evidential/correctness concern about Table 3, not a circularity. I therefore assign 2 only to mark the minor, non-load-bearing self-citation.

Assumptions & free parameters 0 free parameters · 6 assumptions · 0 invented entities

No numerical parameters are fitted in this paper; the only constants are standard secp256k1 values. The analysis rests on set-theoretic definitions, Ethereum/EVM storage semantics, standard ECDSA facts, and the accuracy of third-party incident reports. The theoretical vocabulary comes from the author's companion paper [1], which is not reviewed in this preprint.

assumptions (6)

standard math A mapping between semantic objects and valid codes is a bijection iff each object has exactly one code and each code has exactly one object.
Used in Section 2.2 to argue that the two break directions exhaust all violations of the uniqueness condition.
ad hoc to paper Each system under analysis can be modeled by a fixed encoder/decoder pair with a fixed valid code set and a fixed semantic equality relation.
Sections 7.1 and 9 depend on this; the paper admits applications may not have an explicit equality relation, which limits mechanical application of the checklist.
standard math ECDSA signature verification uses s only via its inverse, so (r, n-s) is also valid unless a low-S rule is enforced.
Section 4.1 and Appendix C.1 rely on this standard elliptic curve fact.
domain assumption EVM storage returns bytes32(0) for unset mapping entries rather than an error.
Section 4.2 and Appendix B.2 use this as the core of the Nomad analysis.
domain assumption The incident narratives in cited third-party sources (Quantstamp, Immunefi, Halborn, Verichains, Cosmos ADRs) correctly describe the technical mechanisms.
Sections 4.2, 6.2, and Table 3 rely on these summaries without independent reproduction.
ad hoc to paper The companion paper [1] correctly establishes byte-input invariance and the computability boundary of canonicalization.
Sections 6.3, 6.4, and 7.2 invoke [1] for the theoretical bridge; [1] is a same-author preprint not reviewed in this document.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Canonicalization Failures as a Recurring Vulnerability Class: Representation Divergence in Cryptographic Systems and Its Avoidance." pith.science (2026). https://pith.science/paper/7DGETFWF

@misc{pith2026260806508,
  author       = {Pith},
  title        = {Pith review of: Canonicalization Failures as a Recurring Vulnerability Class: Representation Divergence in Cryptographic Systems and Its Avoidance},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7DGETFWF}},
  note         = {Machine review of arXiv:2608.06508}
}

read the original abstract

Cryptographic systems operate on bytes but mean semantic objects. The translation between the two is rarely unique. Where this uniqueness is not enforced, an attack surface opens up as soon as a hash, a signature, replay protection, or consensus identity depends on the representation. The same class of failure has been discovered independently and named locally across many ecosystems, as transaction malleability, non-deterministic value encoding, message malleability, or hash chain malleability, without its common root being tracked as a cross-ecosystem grid. This work organizes the scattered findings systematically: it shows that they are instances of one violated uniqueness condition, along two basic directions: multiple valid codes for one object (object-side multiple representation) or one code for multiple objects (code-side semantic collapse). The contribution is explicitly not the discovery of the phenomenon, but is threefold: the systematization by representation mechanism rather than by affected system, the bridge between classical canonicalization security and a representation- and computability-theoretic foundation, and the translation into an applicable review procedure (a canonicalization obligation with a sequence of review steps, a field-type classification, and an operational boundary model) with which the risk can be recognized preventively. We substantiate the class with worked-out cases, delimit it against incidents that are not representation problems, and deliberately keep the claims to what is demonstrable: enforced uniqueness can reduce the exploitability of a failure class, but it neither replaces further protective measures or makes any statement about cryptographic security in the narrower sense

Figures

Figures reproduced from arXiv: 2608.06508 by the authors.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 21 canonical work pages

[1]

Algorithmically Presented Numbers and Canonical Representations in Cryptographic Protocols

A. Brömme,Algorithmically Presented Numbers and Canonical Representations in Crypto- graphic Protocols. arXiv:2607.05016 [cs.CR], 6 July 2026. (German master version 0.9.5.17.)

work page Pith review arXiv 2026
[2]

org,https://capec.mitre.org(accessed July 2026)

MITRE,Common Weakness Enumeration, including CWE-180 (Incorrect Behavior Order: Validate Before Canonicalize), CWE-41 (Improper Resolution of Path Equivalence), CWE- 647 (Use of Non-Canonical URL Paths for Authorization Decisions); MITRE,Common Attack Pattern Enumeration and Classification, CAPEC-43/72/120.https://cwe.mitre. org,https://capec.mitre.org(ac...

work page 2026
[3]

Rundgren, B

A. Rundgren, B. Jordan, S. Erdtman,JSON Canonicalization Scheme (JCS). RFC 8785, RFC Editor, June 2020.https://www.rfc-editor.org/rfc/rfc8785(accessed July 2026). — Justifies the necessity of a canonical JSON form by the fact that cryptographic operations such as hashing and signing require an invariant data representation

work page 2020
[4]

Bormann, P

C. Bormann, P. Hoffman,Concise Binary Object Representation (CBOR), §4 (Deterministi- cally Encoded CBOR). RFC 8949, RFC Editor, December 2020.https://www.rfc-editor. org/rfc/rfc8949(accessedJuly2026); ITU-T,X.690: ASN.1 Distinguished Encoding Rules (DER), February 2021.https://www.itu.int/rec/T-REC-X.690(accessed July 2026)

work page 2020
[5]

Activa- tion

E.Lombrozo, J.Lau, P.Wuille,Segregated Witness (Consensus Layer).BIP-141, BitcoinIm- provement Proposals, 2015.https://github.com/bitcoin/bips/blob/master/bip-0141. mediawiki; Bitcoin Core,Segregated Witness Wallet Development Guide, section “Activa- tion”,https://bitcoincore.org/en/segwit_wallet_dev/(accessed July 2026). — From block height 481,824, SegW...

work page 2015
[6]

Proving With An Empty Leaf

Quantstamp,Nomad Audit Report, finding QSP-19 “Proving With An Empty Leaf” (Low Risk). Final report of 9 June 2022.https://certificate.quantstamp.com/full/nomad 31 (accessed July 2026). — Finding and date confirmed in the Nomad post-mortem on the incident of 1 August 2022

work page 2022
[7]

— The Solidity ABI decoder does not enforce a strict encoding mode, so that dynamic fields can be placed at non-minimal offsets

Verichains,Solidity’s Hidden Flexibility: How ABI Encoding Assumptions Led to an Exploit, 4 March 2026.https://blog.verichains.io/p/soliditys-hidden-flexibility-how (accessed July 2026). — The Solidity ABI decoder does not enforce a strict encoding mode, so that dynamic fields can be placed at non-minimal offsets

work page 2026
[8]

Non- deterministic Value Encoding

Cosmos SDK,Architecture Decision Record 076: Transaction Malleability, section “Non- deterministic Value Encoding”.https://github.com/cosmos/cosmos-sdk/blob/main/ docs/architecture/adr-076-transaction-malleability.md(accessed July 2026)

work page 2026

Show all 23 references

[9]

Ginesin,Git Hash Chain Malleability

J. Ginesin,Git Hash Chain Malleability. arXiv:2607.02820 [cs.CR], 2 July 2026

2026 arXiv
[10]

message malleability

C. Leal,CAIP-380: Portable Proof. Chain Agnostic Improvement Proposals, no. 380, October 2025 (Draft).https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/ caip-380.md(accessed July 2026). — The threat model lists “message malleability” and demands deterministic serializatio...

2025
[11]

Z. Li, Q. Wang, Z. Wang,Five Attacks on x402 Agentic Payment Protocol. arXiv:2605.11781 [cs.CR], 12 May 2026. — Presented here as a borderline case, not as an instance

2026 arXiv
[12]

McIntosh, P

M. McIntosh, P. Austel,XML Signature Element Wrapping Attacks and Countermeasures. In: Proceedings of the 2005 Workshop on Secure Web Services (SWS ’05), ACM, 2005, pp. 20–27. (Also as IBM Research Report RC23691.)

2005
[13]

Somorovsky, A

J. Somorovsky, A. Mayer, J. Schwenk, M. Kampmann, M. Jensen,On Breaking SAML: Be Whoever You Want to Be. In: Proceedings of the 21st USENIX Security Symposium, USENIX Association, 2012, pp. 397–412

2012
[14]

Ramananandro et al.,Secure Parsing and Serializing with Separation Logic Applied to CBOR, CDDL, and COSE(EverParse/EverCDDL)

T. Ramananandro et al.,Secure Parsing and Serializing with Separation Logic Applied to CBOR, CDDL, and COSE(EverParse/EverCDDL). arXiv:2505.17335; ACM CCS, 2025

2025 arXiv
[15]

McNally et al.,Deterministic CBOR (dCBOR)

W. McNally et al.,Deterministic CBOR (dCBOR). IETF Internet-Draft draft- mcnally-deterministic-cbor, IETF, 2025 (active Internet-Draft, not an RFC).https:// datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/(accessed July 2026)

2025
[16]

Google,Protocol Buffers Documentation: Proto Serialization Is Not Canonical.https: //protobuf.dev/programming-guides/serialization-not-canonical/(accessed July 2026)

2026
[17]

— Describes the missing bijectivity of the Protobuf encoding

Cosmos SDK,Architecture Decision Record 027: Deterministic Protobuf Serial- ization.https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/ adr-027-deterministic-protobuf-serialization.md(accessed July 2026). — Describes the missing bijectivity of the Protobuf encodi...

2026
[19]

Unicode Consortium,Unicode Standard Annex #15: Unicode Normalization Forms.https: //www.unicode.org/reports/tr15/(accessed July 2026)

2026
[20]

https://www.unicode.org/reports/tr39/(accessed July 2026)

Unicode Consortium,Unicode Technical Standard #39: Unicode Security Mechanisms. https://www.unicode.org/reports/tr39/(accessed July 2026). 32

2026
[21]

com/p/64ec66c24c7d(accessed July 2026); additionally independent analyses (including BEOSIN) as well as reporting on the hard fork of 5 December 2021

Immunefi,Polygon Lack Of Balance Check Bugfix Review — $2.2m Bounty(MRC20 transferWithSig,ecrecoveryzero-value fallback), December 2021.https://medium. com/p/64ec66c24c7d(accessed July 2026); additionally independent analyses (including BEOSIN) as well as reporting on the hard...

2021
[22]

Buterin,EIP-2: Homestead Hard-fork Changes

V. Buterin,EIP-2: Homestead Hard-fork Changes. Ethereum Improvement Proposals, no. 2, 2015.https://eips.ethereum.org/EIPS/eip-2(accessed July 2026). — Declares trans- action signatures withs >secp256k1n/2invalid and records that theecrecoverprecompile remains unchanged and con...

2015
[23]

Besier,Common Circom Pitfalls and How to Dodge Them, Part 1

M. Besier,Common Circom Pitfalls and How to Dodge Them, Part 1. zkSecurity, 24 June 2025.https://blog.zksecurity.xyz/posts/circom-pitfalls-1/(accessed July 2026). — Describes aliasing vulnerabilities in Circom/circomlib (Num2Bits,Bits2Num), in which non-canonical bit represent...

2025
[24]

Pailoor, Y

S. Pailoor, Y. Chen, F. Wang, C. Rodríguez-Núñez, J. Van Geffen, J. Morton, M. Chu, B. Gu, Y. Feng, I. Dillig,Automated Detection of Under-Constrained Circuits in Zero- Knowledge Proofs. Proceedings of the ACM on Programming Languages 7 (PLDI), Article 168, pp. 1510–1532, June...

2023 doi

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.

[1] [1]

Algorithmically Presented Numbers and Canonical Representations in Cryptographic Protocols

A. Brömme,Algorithmically Presented Numbers and Canonical Representations in Crypto- graphic Protocols. arXiv:2607.05016 [cs.CR], 6 July 2026. (German master version 0.9.5.17.)

work page Pith review arXiv 2026

[2] [2]

org,https://capec.mitre.org(accessed July 2026)

MITRE,Common Weakness Enumeration, including CWE-180 (Incorrect Behavior Order: Validate Before Canonicalize), CWE-41 (Improper Resolution of Path Equivalence), CWE- 647 (Use of Non-Canonical URL Paths for Authorization Decisions); MITRE,Common Attack Pattern Enumeration and Classification, CAPEC-43/72/120.https://cwe.mitre. org,https://capec.mitre.org(ac...

work page 2026

[3] [3]

Rundgren, B

A. Rundgren, B. Jordan, S. Erdtman,JSON Canonicalization Scheme (JCS). RFC 8785, RFC Editor, June 2020.https://www.rfc-editor.org/rfc/rfc8785(accessed July 2026). — Justifies the necessity of a canonical JSON form by the fact that cryptographic operations such as hashing and signing require an invariant data representation

work page 2020

[4] [4]

Bormann, P

C. Bormann, P. Hoffman,Concise Binary Object Representation (CBOR), §4 (Deterministi- cally Encoded CBOR). RFC 8949, RFC Editor, December 2020.https://www.rfc-editor. org/rfc/rfc8949(accessedJuly2026); ITU-T,X.690: ASN.1 Distinguished Encoding Rules (DER), February 2021.https://www.itu.int/rec/T-REC-X.690(accessed July 2026)

work page 2020

[5] [5]

Activa- tion

E.Lombrozo, J.Lau, P.Wuille,Segregated Witness (Consensus Layer).BIP-141, BitcoinIm- provement Proposals, 2015.https://github.com/bitcoin/bips/blob/master/bip-0141. mediawiki; Bitcoin Core,Segregated Witness Wallet Development Guide, section “Activa- tion”,https://bitcoincore.org/en/segwit_wallet_dev/(accessed July 2026). — From block height 481,824, SegW...

work page 2015

[6] [6]

Proving With An Empty Leaf

Quantstamp,Nomad Audit Report, finding QSP-19 “Proving With An Empty Leaf” (Low Risk). Final report of 9 June 2022.https://certificate.quantstamp.com/full/nomad 31 (accessed July 2026). — Finding and date confirmed in the Nomad post-mortem on the incident of 1 August 2022

work page 2022

[7] [7]

— The Solidity ABI decoder does not enforce a strict encoding mode, so that dynamic fields can be placed at non-minimal offsets

Verichains,Solidity’s Hidden Flexibility: How ABI Encoding Assumptions Led to an Exploit, 4 March 2026.https://blog.verichains.io/p/soliditys-hidden-flexibility-how (accessed July 2026). — The Solidity ABI decoder does not enforce a strict encoding mode, so that dynamic fields can be placed at non-minimal offsets

work page 2026

[8] [8]

Non- deterministic Value Encoding

Cosmos SDK,Architecture Decision Record 076: Transaction Malleability, section “Non- deterministic Value Encoding”.https://github.com/cosmos/cosmos-sdk/blob/main/ docs/architecture/adr-076-transaction-malleability.md(accessed July 2026)

work page 2026