0x0D-BLS12_G2ADD

Precompile Summary

Property	Value
Address	0x0D
Name	BLS12_G2ADD
Gas	600 (fixed)
Input	512 bytes: two G2 affine points (256 bytes each). Each G2 point is encoded as x (128 bytes) followed by y (128 bytes), where each coordinate is an Fp2 element. An Fp2 element is encoded as c0 (64 bytes) ‖ c1 (64 bytes), representing c0 + c1·v in the quadratic extension field. Each 64-byte component is a big-endian Fp element whose top 16 bytes must be zero (canonical BLS12-381 limb layout).
Output	256 bytes: resulting G2 point as 128-byte x (Fp2) then 128-byte y (Fp2). The point at infinity is encoded as 256 zero bytes.
Introduced	Pectra hardfork (EIP-2537, May 2025)
Behavior	Performs point addition on the BLS12-381 G2 curve (defined over the Fp2 quadratic extension field). Each input point must lie on the G2 curve or represent the point at infinity (256 zero bytes). No subgroup check is performed — this is deliberate per EIP-2537, identical to G1ADD’s policy, but far more consequential because G2 has a non-trivial cofactor. On error (invalid coordinate encoding, point not on the G2 curve and not infinity, wrong input length), the precompile burns all gas forwarded to the call. On success, returns exactly 256 bytes.

---

Threat Surface

BLS12_G2ADD is a consensus-critical elliptic-curve primitive: it adds two affine G2 points on the BLS12-381 curve over the Fp2 extension field and returns their sum. Like its G1 counterpart, it does not interpret application semantics — no domains, authorization context, or proof-system binding — so correctness, failure handling, and cryptographic assumptions must be enforced by callers and by the protocol that consumes the resulting points.

The threat surface is qualitatively different from — and significantly larger than — BLS12_G1ADD, despite sharing the same API shape and “no subgroup check” policy. The difference is rooted in group theory:

1. Non-trivial cofactor on G2 makes “no subgroup check” dangerous. BLS12-381 G1 has cofactor h₁ = 1: every point on the G1 curve lies in the prime-order subgroup, so the absence of a subgroup check is mathematically harmless for G1 curve arithmetic. G2’s cofactor is h₂ ≈ 3.05 × 10¹⁴⁷ — an enormous integer. This means there are vast numbers of points that lie on the G2 curve but are not in the prime-order subgroup E'(Fp2)[r]. BLS12_G2ADD will accept and correctly add such points without any warning. If those non-subgroup outputs feed into BLS signature aggregation, custom verification schemes, or any protocol that assumes subgroup membership, the cryptographic guarantees break silently.

2. BLS signature aggregation runs through G2 operations. In the standard BLS signature scheme over BLS12-381, public keys live in G2 (or G1 depending on variant). Key aggregation — the operation that enables multi-signature and threshold schemes — is literally G2 point addition. A contract that aggregates public keys via G2ADD without independent subgroup validation or proof-of-possession is directly exposed to rogue key attacks, one of the most studied attack classes in aggregate signature literature.

3. Failure economics and Fp2 encoding complexity. The punishing error model (all forwarded gas burned on any error) is amplified by Fp2 encoding: each G2 coordinate has four 64-byte Fp components (two per Fp2 element, two Fp2 elements per point, times two points = eight Fp limbs). Each must satisfy top-zero padding and < p canonicality. The combinatorial surface for encoding errors — and therefore for gas-burning griefing — is larger than for G1. Misordering c0 and c1 within an Fp2 element produces a point that may still be valid-looking but is mathematically wrong, yielding a silent logic bug rather than a revert.

4. Client maturity and cross-implementation risk. BLS12-381 G2 arithmetic over Fp2 is more complex than G1 arithmetic over Fp. Library implementations must handle extension-field reduction, twist curves, and cofactor-related edge cases. CVE-2025-30147 on BN254 demonstrated that validation gaps in curve precompile implementations produce consensus divergence; the added complexity of G2/Fp2 increases the probability of such gaps in new or refactored client code.

---

Smart Contract Threats

T1: No Subgroup Check on G2 with Non-Trivial Cofactor (Critical)

EIP-2537 deliberately omits subgroup checking for BLS12_G2ADD. The precompile accepts any well-encoded point on the G2 curve (plus the infinity encoding). Unlike G1, this omission has direct cryptographic consequences.

• G2 cofactor h₂ is enormous. The BLS12-381 G2 cofactor is 305502333931268344200999753193121504214466019254188142667664032982267604182971884026507427359259977847832272839041616661285803823378372096355777062779109. There are vast families of points on E'(Fp2) that satisfy the curve equation yet are not in the prime-order subgroup of order r.
• G2ADD accepts non-subgroup points. A point that is on the G2 curve but in a low-order subgroup will be added without error. The output is a valid curve point — also not in the prime-order subgroup.
• Downstream pairing checks enforce subgroups; other paths do not. If the result of G2ADD is passed to BLS12_PAIRING_CHECK (0x0F), the pairing precompile will perform subgroup validation and reject non-subgroup points. But if the output is stored, hashed, compared, or used in any custom verification logic that does not independently verify subgroup membership, the lack of validation is a critical gap.
• Contrast with G1ADD. BLS12_G1ADD (0x0B) carries the same “no subgroup check” wording, but G1 cofactor = 1 makes that policy safe for G1 curve arithmetic. Developers who copy G1 patterns to G2 inherit a fundamentally different risk profile.

Why it matters: This is the most dangerous of the ADD precompiles. Non-subgroup G2 points silently corrupt any protocol that assumes subgroup membership — BLS signatures, threshold schemes, proof-of-custody, and any construction where e(P, Q) = 1 reasoning depends on Q ∈ G2[r]. The precompile provides no guardrail; the developer must supply all validation.

T2: Small Subgroup Attacks via G2ADD Output (Critical)

An attacker can construct G2 points that satisfy the curve equation over Fp2 but reside in a small subgroup determined by divisors of the cofactor h₂.

• Crafted low-order points pass G2ADD. Because G2ADD only checks on-curve membership (not subgroup), adding two low-order points produces another low-order point — all without error.
• Aggregation is corrupted. If a contract uses G2ADD to aggregate public keys, signature components, or commitment elements, injecting a non-subgroup point contaminates the aggregate. The aggregate may appear to be a valid G2 curve point but will fail in pairing equations or, worse, satisfy weakened pairing equations that an attacker can exploit.
• Scalar multiplication of non-subgroup points leaks information. If a non-subgroup point Q of order d | h₂ is multiplied by scalar s (via G2MSM), the result depends only on s mod d. For small d, this leaks scalar bits — a classic small-subgroup information-extraction attack.

Why it matters: Small-subgroup attacks are a textbook threat against elliptic-curve protocols operating on curves with composite-order groups. G2ADD on BLS12-381 is precisely the scenario these attacks target: a non-prime-order group where the protocol primitive does not enforce subgroup membership.

T3: Rogue Key Attacks in BLS Signature Aggregation (Critical)

BLS signature aggregation works by adding public keys (in G2 for the “minimal-signature-size” variant, or in G1 for “minimal-pubkey-size”). G2ADD is the natural precompile for this.

• The attack. An adversary observes other participants’ public keys pk₁, pk₂, …, pkₙ. The adversary generates pk_attack = −(pk₁ + pk₂ + … + pkₙ) + pk_forge, where pk_forge is a key the adversary controls. The naive aggregate pk₁ + pk₂ + … + pkₙ + pk_attack = pk_forge, and the adversary can sign for the entire group.
• G2ADD enables this trivially. The precompile performs arbitrary G2 addition with no restrictions on how points relate to each other or to any proof-of-possession.
• Proof-of-possession (PoP) is the standard mitigation. Each participant proves knowledge of the secret key corresponding to their public key. But G2ADD provides no PoP enforcement; it is a raw arithmetic primitive.
• Multi-message verification (e.g., BGLS scheme) is an alternative mitigation that requires per-signer distinct messages, preventing the cancellation trick.

Why it matters: Rogue key attacks are the primary real-world threat when BLS key aggregation is done naively. Any contract using G2ADD for multi-party public key aggregation without PoP or equivalent is vulnerable.

T4: Gas Burning on Error (Medium)

Like all BLS12 EIP-2537 precompiles, BLS12_G2ADD burns all gas forwarded to the precompile on error.

• Higher base cost amplifies loss. At 600 gas (vs 375 for G1ADD), the minimum waste per failed call is higher, but the real danger is staticcall(gas(), 0x0D, ...) forwarding the entire remaining gas.
• 512-byte input surface. The larger input (512 bytes vs 256 for G1) means more opportunities for encoding errors and therefore more opportunities for adversary-triggered gas burns.
• Griefing pattern. Attacker supplies 512 bytes with correct length but invalid Fp2 encoding or off-curve coordinates; all forwarded gas is consumed.

Why it matters: Attackers can force maximum gas loss per failed invocation, enabling griefing and breaking contracts that assumed precompile failures are low-cost.

T5: Fp2 Element Encoding Complexity (Medium)

G2 points use Fp2 coordinates, each 128 bytes — double the size of G1’s Fp coordinates — with strict internal structure.

• Fp2 encoding is c0 ‖ c1, representing c0 + c1·v. Each of c0 and c1 is a 64-byte big-endian Fp element with the top 16 bytes zero and value < p.
• Swapping c0 and c1 produces a different, valid-looking Fp2 element. If the resulting point happens to be on the G2 curve, the precompile succeeds with a mathematically different answer — a silent logic bug, not a revert.
• Eight Fp limbs per call (4 per point × 2 points). Each must independently satisfy padding and range constraints. The combinatorial surface for encoding errors is 4× larger than G1ADD.
• Off-chain tooling mismatches. Different libraries may use different Fp2 serialization conventions (c0 ‖ c1 vs c1 ‖ c0, or imaginary-first vs real-first). EIP-2537 specifies c0 ‖ c1; using a library with the opposite convention silently produces wrong results if the point happens to land on the curve.

Why it matters: Fp2 encoding errors are harder to detect than Fp errors, produce subtler bugs (silent wrong answers instead of reverts when the misordered point is on-curve), and affect a wider surface area per precompile call.

---

Protocol-Level Threats

P1: No-Subgroup-Check on G2 Is Far More Consequential Than on G1

The EIP-2537 design choice to omit subgroup checks on ADD operations is safe for G1 (cofactor 1) but dangerous for G2 (cofactor ≈ 3 × 10¹⁴⁷). The spec states that MSMs and pairings must check subgroups, but ADD operations do not. This creates a validation gap: points can enter a computation pipeline through G2ADD without subgroup validation, be stored or aggregated, and only fail when (if) they eventually reach a pairing check. If the pipeline never routes through pairing or MSM, the invalid points persist unchecked.

P2: Validation Gap Between ADD and MSM/Pairing Creates Inconsistent Trust Boundaries

Developers building multi-step BLS verification on-chain may use G2ADD for intermediate aggregation steps and G2MSM or PAIRING_CHECK for final verification. The implicit assumption is that the final check catches all invalid points. But if the intermediate aggregated point is stored (e.g., in a registry of aggregate public keys) before reaching the final check, or if a code path bypasses the final check, the non-subgroup point becomes enshrined in contract state.

P3: CVE-2025-30147 Analogue Risk for G2 Curve Operations

CVE-2025-30147 demonstrated that BN254 curve precompiles could ship with inadequate point validation, causing consensus divergence between clients. BLS12-381 G2 operations over Fp2 are more complex than BN254 or BLS12-381 G1 arithmetic: extension-field reduction, twist-curve formulas, and cofactor-related edge cases increase the likelihood of subtle implementation differences between clients. Any future library swap or optimization in a client’s BLS12 G2 code path is in the same risk class.

---

Edge Cases

Edge Case	Behavior	Security Implication
Point at infinity (256 zero bytes) + P	Returns P (identity semantics)	Callers must treat all-zero 256-byte encoding as infinity, not as unconstrained zeros
P + (−P)	Returns point at infinity (256 zero bytes)	Valid; downstream logic must accept infinity outputs where the math allows
P + P (doubling)	Handled as addition of identical affine points	Implementation must follow EIP-2537; test doubling vectors in CI
Point on G2 curve but NOT in prime-order subgroup	Accepted — no error	This is the key security concern. The precompile provides no warning; caller must independently validate subgroup membership if the protocol requires it
Input length < 512 bytes	Error; all forwarded gas burned	Strict length; no silent padding — validate length before call
Input length > 512 bytes	Error; all forwarded gas burned	Surplus bytes are not ignored — unlike some legacy precompile padding behaviors
Fp2 coordinate with c0 or c1 ≥ p (field modulus)	Error; gas burned	Each of the eight 64-byte Fp limbs must be canonical: value < p with top 16 bytes zero
Top 16 bytes of any 64-byte Fp limb non-zero	Error; gas burned	Violates canonical Fp encoding within the Fp2 element
c0 and c1 swapped within an Fp2 element	If resulting point is on-curve: accepted with wrong answer; if not: error	Silent logic bug when the misordered point happens to satisfy the curve equation — no revert to alert the developer
Empty input (0 bytes)	Error; gas burned	Treated as invalid length
Valid Fp2 encoding, point not on G2 curve	Error; gas burned	Distinguish encoding validity from curve membership

---

Real-World Exploits

Exploit 1: No Known BLS12_G2ADD Exploits; Rogue Key Literature and CVE-2025-30147 as Precedents

Root cause: There is no known public exploit chain targeting BLS12_G2ADD specifically as of early 2026 — the precompile is new (Pectra, May 2025) and on-chain BLS signature aggregation usage is still maturing.

Rogue key attacks on BLS signatures are extensively documented in academic literature:

• Boneh, Drijvers, and Neven (“Compact Multi-Signatures for Smaller Blockchains,” 2018) formalized rogue key attacks and the proof-of-possession defense.
• The Harmony blockchain experienced issues related to BLS key aggregation in its consensus layer, motivating stricter PoP requirements in production BLS deployments.
• Multiple audit reports for BLS-based protocols (e.g., Ethereum 2.0 deposit contracts, EigenLayer AVS registration) have flagged the rogue key attack surface when key aggregation lacks PoP enforcement.

CVE-2025-30147 (BN254) is the closest on-chain precedent for curve precompile validation failures. Besu versions 24.7.1–25.2.2 did not adequately validate BN256ADD/MUL/PAIRING inputs were on-curve, causing consensus divergence. The vulnerability class — incomplete point validation in a client’s curve implementation — is directly analogous to risks in BLS12 G2 implementations, where Fp2 arithmetic and twist-curve formulas add complexity.

Impact model: The primary current risk is not a catalog of mainnet thefts but the combination of (a) protocol-level subgroup validation gaps inherent in G2ADD’s design, (b) the well-studied rogue key attack class that maps directly onto naive G2ADD-based aggregation, and (c) client implementation maturity for the more complex G2/Fp2 code paths.

References:

• CVE-2025-30147 - The curious case of subgroup check on Besu | Ethereum Foundation Blog
• CVE-2025-30147 (NVD)
• EIP-2537: BLS12-381 Curve Operations
• Boneh, Drijvers, Neven — “Compact Multi-Signatures for Smaller Blockchains” (ASIACRYPT 2018)

---

Attack Scenarios

Scenario A: BLS Key Aggregation via G2ADD Without Proof-of-Possession (Rogue Key Attack)

// VULNERABLE PATTERN: naive BLS public key aggregation using G2ADD
// without proof-of-possession — enables rogue key attack
pragma solidity ^0.8.0;
 
contract VulnerableBLSRegistry {
    address internal constant BLS12_G2ADD = address(0x0D);
 
    // Stored aggregate public key (G2 point, 256 bytes)
    bytes public aggregatePubkey;
    uint256 public participantCount;
 
    // BUG: accepts any G2 point as a public key with no proof-of-possession.
    // Attacker can register pk_attack = -(pk1 + pk2 + ... + pkN) + pk_forge,
    // making the aggregate equal to pk_forge, which the attacker controls.
    function registerPublicKey(bytes calldata newPubkey) external {
        require(newPubkey.length == 256, "invalid G2 point length");
 
        if (participantCount == 0) {
            aggregatePubkey = newPubkey;
        } else {
            bytes memory input = abi.encodePacked(aggregatePubkey, newPubkey);
            bytes memory output = new bytes(256);
            bool ok;
            assembly {
                ok := staticcall(
                    gas(),          // dangerous: all gas forwarded
                    BLS12_G2ADD,
                    add(input, 32),
                    512,
                    add(output, 32),
                    256
                )
            }
            require(ok, "G2ADD failed");
            aggregatePubkey = output;
        }
        participantCount++;
    }
}
 
// Attack flow:
// 1. Honest participants register pk1, pk2, ..., pkN via registerPublicKey().
// 2. Attacker reads aggregatePubkey (= pk1 + pk2 + ... + pkN).
// 3. Attacker computes pk_attack = -aggregatePubkey + pk_forge (off-chain).
// 4. Attacker calls registerPublicKey(pk_attack).
// 5. New aggregatePubkey = (pk1+...+pkN) + pk_attack = pk_forge.
// 6. Attacker can now sign messages for the entire group using sk_forge.
//
// Mitigation: require proof-of-possession (signature over the sender's address
// or public key) verified via BLS12_PAIRING_CHECK before accepting registration.

Scenario B: Non-Subgroup G2 Points Fed Through G2ADD to Create Invalid Aggregates

// VULNERABLE PATTERN: contract aggregates G2 points via G2ADD
// without subgroup validation — non-subgroup points corrupt the aggregate
pragma solidity ^0.8.0;
 
contract UnsafeG2Aggregator {
    address internal constant BLS12_G2ADD = address(0x0D);
 
    // Aggregates arbitrary G2 curve points. G2ADD accepts points on the curve
    // regardless of subgroup membership. If any input is not in the prime-order
    // subgroup, the aggregate is also not in the subgroup.
    function aggregateG2Points(bytes calldata points) external view returns (bytes memory) {
        require(points.length >= 512 && points.length % 256 == 0, "bad length");
 
        uint256 n = points.length / 256;
        bytes memory result = points[0:256];
 
        for (uint256 i = 1; i < n; i++) {
            bytes memory input = abi.encodePacked(result, points[256 * i : 256 * (i + 1)]);
            bytes memory output = new bytes(256);
            bool ok;
            assembly {
                ok := staticcall(
                    2000,   // capped gas — good practice for griefing defense
                    BLS12_G2ADD,
                    add(input, 32),
                    512,
                    add(output, 32),
                    256
                )
            }
            require(ok, "G2ADD failed");
            result = output;
        }
        return result;
    }
}
 
// Attack:
// 1. Attacker constructs a point Q on the G2 curve but NOT in the prime-order subgroup.
//    (Q satisfies the twist curve equation over Fp2 but has order dividing h2, not r.)
// 2. G2ADD accepts Q without error — it only checks on-curve, not subgroup membership.
// 3. The aggregated result is now a non-subgroup point.
// 4. If this result is later used in a pairing check, the pairing precompile rejects it.
//    But if it is used in any other context (stored as a "valid" aggregate key, compared
//    for equality, used in a custom hash-based scheme), the corruption goes undetected.
//
// Mitigation: validate subgroup membership independently (e.g., via G2MSM with scalar = 1,
// which enforces subgroup checks), or route all points through PAIRING_CHECK before storage.

Scenario C: Ignoring Return Status After G2ADD

// VULNERABLE PATTERN: does not check staticcall success — stale buffer read
pragma solidity ^0.8.0;
 
contract UncheckedG2Add {
    address internal constant BLS12_G2ADD = address(0x0D);
 
    function addG2Points(
        bytes calldata p1,
        bytes calldata p2
    ) external view returns (bytes memory) {
        require(p1.length == 256 && p2.length == 256, "length");
 
        bytes memory input = abi.encodePacked(p1, p2);
        bytes memory output = new bytes(256);
 
        assembly {
            // BUG: success flag discarded via pop()
            pop(staticcall(
                gas(),
                BLS12_G2ADD,
                add(input, 32),
                512,
                add(output, 32),
                256
            ))
        }
 
        // On failure: returndata may be empty; output buffer contains stale
        // zeros or prior memory contents, interpreted as a G2 point.
        return output;
    }
}
 
// Failure mode:
// 1. Provide 256-byte points with valid length but invalid Fp2 encoding or off-curve.
// 2. Precompile fails; all forwarded gas is burned; staticcall returns success = false.
// 3. Contract returns output buffer as if it were a valid G2 point (likely all zeros,
//    which encodes the point at infinity — a potentially exploitable confusion).
// Mitigation: always check success AND returndatasize() == 256.

---

Mitigations

Threat	Mitigation	Implementation
T1: No subgroup check on G2	Independently validate subgroup membership for all G2 points that enter trust-sensitive pipelines	Use G2MSM with scalar = 1 (enforces subgroup check per EIP-2537) as a validation gate; or route through PAIRING_CHECK before accepting points into storage
T2: Small subgroup attacks	Reject G2 points not in the prime-order subgroup before aggregation	Same as T1; additionally, restrict point sources to trusted origins (e.g., points produced by MAP_FP2_TO_G2 followed by cofactor clearing)
T3: Rogue key attacks	Require proof-of-possession (PoP) for every public key before aggregation	Verify a BLS signature over the registrant’s identity (address or public key hash) via BLS12_PAIRING_CHECK at registration time; alternatively use multi-message verification (BGLS)
T4: Gas burning on error	Cap forwarded gas to precompile budget + small buffer	Use explicit gas stipend (~600 + overhead) instead of gas(); validate input length (== 512) and Fp2 limb ranges before calling the precompile
T5: Fp2 encoding errors	Validate c0 ‖ c1 ordering and each limb < p with top 16 bytes zero	Canonical serialization in off-chain tooling; on-chain range checks where economical; property tests against execution-spec vectors; document which Fp2 convention your library uses
P1–P3: Protocol/client risk	Monitor client advisories; diversify nodes; track EIP-2537 errata	Same operational playbook as post-CVE-2025-30147 BN256 response; audit BLS12 G2 code paths with extra scrutiny on Fp2 arithmetic
General	Centralize BLS12 G2 calls in one audited module	Single wrapper for G2ADD/G2MSM/pairing with uniform error handling, subgroup validation, and PoP enforcement

Compiler/EIP-Based Protections

• EIP-2537 (Pectra, May 2025): Defines BLS12-381 precompiles including BLS12_G2ADD at 0x0D, fixed 600 gas, Fp2 input/output layouts, infinity encoding, no subgroup check policy for ADD operations, subgroup checks required for MSM and pairing, and all forwarded gas burned on failure.
• Execution-spec-tests / reference vectors: Ethereum’s cross-client test suite provides conformance coverage for G2ADD; they do not protect against a buggy single client — operators need version hygiene and client diversity.
• Solidity / Yul: No compiler-enforced success-or-length check for precompile returns — mitigations are programmatic (explicit staticcall success, returndatasize == 256, and gas stipends). No built-in Fp2 encoding validation exists in the language.

---

Severity Summary

Threat ID	Category	Severity	Likelihood	Real-World Precedent
T1	Smart Contract / Cryptographic	Critical	High	G2 cofactor ≈ 3×10¹⁴⁷ enables non-subgroup points; no check by design. Academic literature extensively documents subgroup attacks on pairing-friendly curves
T2	Smart Contract / Cryptographic	Critical	High	Small-subgroup attacks are textbook threats for composite-order groups; BLS12-381 G2 is the canonical example
T3	Smart Contract / Protocol	Critical	Medium–High	Rogue key attacks on BLS are well-documented (academic literature, Harmony blockchain); direct mapping to naive G2ADD aggregation
T4	Smart Contract / DoS economics	Medium	Medium	EIP-2537 gas burn on error — griefing via malformed inputs with high stipends
T5	Smart Contract / Encoding	Medium	Medium	Fp2 serialization mismatches between libraries; c0/c1 ordering bugs produce silent wrong answers
P1	Protocol / Spec design	High	N/A (structural)	Asymmetry between G1 (cofactor 1, safe) and G2 (cofactor huge, unsafe) under same “no subgroup check” policy
P2	Protocol / Trust boundaries	High	Medium	Validation gap between ADD (no check) and MSM/pairing (checked) enables non-subgroup points to enter storage
P3	Protocol / Client	High	Low	CVE-2025-30147 (Besu / BN256) shows validation bugs become consensus issues; G2/Fp2 complexity increases risk

---

Related Precompiles

Precompile	Relationship
BLS12_G2MSM (0x0E)	G2 multi-scalar multiplication; performs subgroup checks unlike G2ADD — use for subgroup-validated G2 operations
BLS12_G1ADD (0x0B)	G1 addition with same “no subgroup check” policy; safe on G1 (cofactor 1) — contrast with G2’s dangerous cofactor
BLS12_PAIRING_CHECK (0x0F)	Pairing verification consuming G1/G2 points; enforces subgroup checks — use as validation gate before trusting G2 points
BN256ADD (0x06)	Legacy alt_bn128 addition; different curve, encoding, gas, and failure semantics; CVE-2025-30147 precedent
BLS12_MAP_FP2_TO_G2 (0x11)	Hash-to-curve / field-to-G2 map; outputs feed G2 operations; produces points that may need cofactor clearing for subgroup membership