TIP-7951: Precompile for secp256r1 Curve Support

[raymondliu0711]

tip: 7951
title: Precompile for secp256r1 Curve Support
author: lei19942016@hotmail.com
status: Draft
type: Standards Track
category: VM
created: 2025-07-25

Summary

Ethereum has proposed EIP-7951 to add support for secp256r1 ECDSA signature verification through a precompiled contract and has scheduled it for inclusion in next Fusaka upgrade. To maintain compatibility with Ethereum's implementation, TRON needs to introduce this TIP and implement the secp256r1 signature verification precompile.

Abstract

Add functionality to efficiently perform ECDSA signature verification over the secp256r1 elliptic curve (also known as P-256 or prime256v1). This precompile enables native support for signatures generated by modern secure hardware including Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn devices.

This specification addresses critical security issues discovered in RIP-7212 while maintaining full interface compatibility with existing Layer 2 implementations.

This TIP follows Ethereum's EIP-7951 specification, which supersedes RIP-7212 by implementing the same functionality with enhanced security fixes and proper validation checks.

Motivation

To maintain compatibility with Ethereum's precompiled contract standards, we are implementing corresponding secp256r1 ECDSA signature verification functionality in the TVM.

Original motivation from EIP-7951:

The secp256r1 elliptic curve is a NIST-standardized curve widely supported in modern secure hardware and authentication systems. Adding native support for secp256r1 signature verification to Ethereum enables several important use cases that are currently impossible or prohibitively expensive.

Modern secure hardware devices, including Apple Secure Enclave, Android Keystore, HSMs, TEEs, and FIDO2/WebAuthn authenticators, use secp256r1 for key storage and signing operations. Native secp256r1 support enables sophisticated account abstraction patterns like device-native signing, multi-factor authentication, and simplified key management - ultimately reducing friction for mainstream adoption through familiar authentication flows.

The secp256r1 curve is already widely supported across blockchain networks and protocols, including Layer 2 networks, enterprise blockchains, and interoperability protocols. This broad compatibility enables seamless integration with existing infrastructure while maintaining security through hardware-backed signing capabilities.

This EIP supersedes RIP-7212 by implementing the same functionality with the same interface, but without the vulnerability.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Precompile

We introduce P256VERIFY a precompile at the address 0x100 which performs ECDSA signature verification over the secp256r1 curve with a gas cost of 6900 gas

Curve Parameters

The secp256r1 curve is fully defined by the following set of parameters:

Base field modulus = p = 0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff
Curve equation: y^2 = x^3 + ax + b (mod p)
Curve coefficient a = 0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc
Curve coefficient b = 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b
Base point G:
  Gx = 0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296
  Gy = 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5
Subgroup order = n = 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551
Cofactor = h = 0x1

These parameters are standardized by NIST in SP 800-186[^1].

Fields and Groups

The field Fp is defined as the finite field of size p with elements represented as integers between 0 and p-1 (both inclusive).

The group G is defined as a set of Fp pairs (points) (x,y) such that either (x,y) is (0,0) (representing the point at infinity) or x,y satisfy the curve equation y^2 = x^3 + ax + b (mod p).

Points and Encoding

Field Elements Encoding

A base field element (Fp) is encoded as 32 bytes by performing BigEndian encoding of the corresponding (unsigned) integer. The corresponding integer must be less than the field modulus p.

Encoding of Points in G

Points in G are encoded as byte concatenation of the respective encodings of the x and y coordinates. Total encoding length for a G point is thus 64 bytes.

Point of Infinity Encoding

For secp256r1, the point with coordinates (0, 0) (zeroes in Fp) is not on the curve, so a sequence of 64 zero bytes is used by convention to encode the point of infinity.

Encoding of Scalars

A scalar is encoded as 32 bytes by performing BigEndian encoding of the corresponding (unsigned) integer. The corresponding integer is not required to be less than or equal to the subgroup order n.

Behavior on Invalid Inputs

On inputs that cannot be valid encodings of field elements or points, the precompile must return `` (failure).

ABI for P256VERIFY Operation

Input

P256VERIFY call expects 160 bytes as input that is interpreted as byte concatenation of:

• 32 bytes: message hash h
• 32 bytes: signature component r
• 32 bytes: signature component s
• 32 bytes: public key x-coordinate qx
• 32 bytes: public key y-coordinate qy

Output

Output is 32 bytes on successful verification and 0 bytes on failure:

• 0x0000000000000000000000000000000000000000000000000000000000000001 for valid signatures
• `` for invalid signatures or invalid inputs

Input Validation

The precompile MUST perform the following validation checks and return `` (failure) if any check fails:

1. Input length: Input MUST be exactly 160 bytes
2. Signature component bounds: Both r and s MUST satisfy 0 < r < n and 0 < s < n
3. Public key bounds: Both qx and qy MUST satisfy 0 ≤ qx < p and 0 ≤ qy < p
4. Point validity: The point (qx, qy) MUST satisfy the curve equation qy^2 ≡ qx^3 + a*qx + b (mod p)
5. Point not at infinity: The point (qx, qy) MUST NOT be the point at infinity (represented as (0, 0))

Signature Verification Algorithm

The verification algorithm follows these steps:

# Input validation (as specified above)
if input_length != 160:
    return
if not (0 < r < n and 0 < s < n):
    return
if not (0 ≤ qx < p and 0 ≤ qy < p):
    return 
if qy^2 ≢ qx^3 + a*qx + b (mod p):
    return
if (qx, qy) == (0, 0):
    return

# Signature verification
s1 = s^(-1) (mod n)

# Recover the random point used during signing
R' = (h * s1) * G + (r * s1) * (qx, qy)

# Check for point at infinity
if R' is the point at infinity:
    return

# Extract x-coordinate from r
r' = R'.x

# Compare with modular reduction
if r' ≡ r (mod n):
    return 0x0000000000000000000000000000000000000000000000000000000000000001
else:
    return 

Error Cases

• Invalid input length (not exactly 160 bytes)
• Invalid field element encoding (≥ field modulus)
• Invalid signature component bounds (r or s not in range (0, n))
• Invalid public key (point at infinity or not on curve)
• Signature verification failure

Gas Schedule

P256VERIFY operation

6900 gas

This cost is based on benchmarking against the existing ECRECOVER precompile (3000 gas). During benchmarks we found that the actual cost of R1 verification was significantly slower than the ECRECOVER precompile and the decision was made to increase the gas cost to 6900 gas.

Gas Burning on Error

The precompile MUST NOT revert under any circumstances. Invalid inputs or verification failures MUST return `` and consume the same amount of gas had verification succeeded.

Rationale

Security Fixes

This specification addresses two critical vulnerabilities in RIP-7212:

1. Point-at-infinity check: The original RIP-7212 failed to check if the recovered point R' is the point at infinity. This could lead to non-deterministic behavior where the verification result depends on the underlying implementation's handling of infinity points, potentially causing consensus failures.

2. Modular comparison: The original comparison r' == r should be r' ≡ r (mod n) to handle cases where the x-coordinate of R' exceeds the curve order n. This ensures mathematically correct verification according to ECDSA standards.

Verification vs Recovery

This specification uses signature verification rather than public key recovery (like ECRECOVER) because:

• Most secp256r1 implementations in hardware and software verify signatures directly
• The NIST FIPS 186-5 standard[^2] specifies verification, not recovery
• Verification is more efficient than recovery for this curve
• Existing hardware implementations provide verification interfaces

Gas Cost Justification

The 6900 gas cost does not maintain compatibility with L2s, but it matches closer the benchmarks of actual implementations.

Backwards Compatibility

This TIP maintains full interface compatibility with RIP-7212 implementations deployed on Layer 2 networks. The same contract bytecode that works with RIP-7212 will work with this specification.

The security fixes are transparent to correctly implemented callers - they only affect edge cases that should have failed verification anyway. No existing valid use cases are broken.

Interface Compatibility

The precompile maintains a similar interface as RIP-7212 to ensure compatibility with existing Layer 2 deployments:

• Same address: 0x100
• Same input format: 160 bytes
• Same output format: 32 bytes
• Different gas cost: 3450 gas vs 6900 gas
• Same return values

Test Cases

A set of test vectors for verifying implementations is located in a separate file.

Reference Implementation

A reference implementation is not supplied due to the ubiquity of secp256r1, if however a reference is needed, the NIST specification in FIPS 186-5[^2]

Security Considerations

Cryptographic Security

The secp256r1 curve provides approximately 128 bits of security, equivalent to secp256k1 already in use in TRON. The curve parameters are standardized by NIST SP 800-186[^1] and have undergone extensive cryptographic analysis by the wider cryptographic community in addition to this curve being deployed to several L2s in the form of RIP-7212.

Malleability

Unlike secp256k1 ECDSA signatures, secp256r1 ECDSA signatures are not required to be non-malleable per NIST FIPS 186-5 standard [^2]. Applications requiring non-malleability should implement additional checks at the application layer.

Side-Channel Resistance

We explicitly state that this precompile IS NOT REQUIRED to perform all the operations using constant time algorithms.

Use Case

TIP-7951 enables new capabilities that were previously impossible or prohibitively expensive:

1. Mobile Wallets with Hardware Security: Enable iOS/Android wallets to use device-native secure hardware (Apple Secure Enclave, Android Keystore).

2. FIDO2/WebAuthn Integration: Enable support for standard authentication protocols (FIDO2/WebAuthn) that use secp256r1 and are used by billions of devices.

3. Hardware-Backed Key Management: Enable enterprise solutions using Hardware Security Modules (HSMs) and Trusted Execution Environments (TEEs) that use secp256r1.

Use Case: Smart Contract Wallet with Mobile Hardware Security

Scenario Overview

This use case demonstrates a smart contract wallet that leverages mobile device hardware security for transaction signing and authentication.

A mobile wallet application wants to provide users with seamless, secure transactions using the built-in hardware security features already present in billions of smartphones worldwide. Modern mobile devices (iPhone, Android) use secp256r1 for their secure hardware (Apple Secure Enclave, Android Keystore).

Security Comparison:

• secp256r1 (Hardware-Backed): Private keys are stored in the device's built-in secure hardware and cannot be exported, providing cold wallet-level security. Keys never leave the secure hardware, making wallets extremely difficult to compromise. Available to every iPhone and Android user with biometric authentication (Face ID, Touch ID, Fingerprint).
• secp256k1 (Software-Based): Private keys are stored as exportable data (mnemonic phrases, keystore files) in the device's file system or memory. If compromised by malware, phishing, or physical access, the mnemonic phrase or private key can be extracted, leading to complete wallet theft. Users must manually protect mnemonic phrases, which is error-prone and insecure.

Current Limitation (Without TIP-7951)

Current Workaround (if secp256r1 is not supported):

// Contract must verify secp256r1 signatures in Solidity
// This is extremely expensive and impractical
function verifySecp256r1Signature(
    bytes32 messageHash,
    bytes32 r,
    bytes32 s,
    bytes32 qx,
    bytes32 qy
) public pure returns (bool) {
    // Manual secp256r1 verification in Solidity
    // Cost: ~500,000+ gas (prohibitively expensive)
    // Complexity: Requires complex elliptic curve math
    // Security: Error-prone implementation
}

Issues:

• Gas cost: >1000,000+ energy per verification (prohibitively expensive)
• Complexity: Requires implementing complex elliptic curve math in Solidity
• Security: High risk of implementation errors
• Performance: Extremely slow execution
• User Experience: Transactions fail or are too expensive

Solution (With TIP-7951)

Native Precompile Support:

// Simple, efficient secp256r1 signature verification
function verifyBiometricSignature(
    bytes32 messageHash,
    bytes32 r,
    bytes32 s,
    bytes32 qx,
    bytes32 qy
) public view returns (bool) {
    // Call precompile at address 0x100
    bytes memory input = abi.encodePacked(
        messageHash,
        r,
        s,
        qx,
        qy
    );
  
    (bool success, bytes memory result) = address(0x100).staticcall(input);
  
    if (!success || result.length != 32) {
        return false;
    }
  
    // Result is 0x00...01 for valid, 0x00...00 for invalid
    return result[31] == 0x01;
}

Benefits:

• Gas cost: 73x cheaper than Solidity implementation
• Simplicity: Simple precompile call, no complex math
• Security: Cryptographically secure, battle-tested implementation
• Performance: Native execution, extremely fast
• User Experience: Affordable, reliable transactions

Conclusion

TIP-7951 is essential for TRON's growth and mainstream adoption. By enabling native secp256r1 signature verification, TRON can:

1. Support modern mobile wallets with device-native security
2. Reduce transaction costs by at least 50x compared to Solidity implementations
3. Improve user experience with biometric authentication
4. Maintain compatibility with Ethereum and Layer 2 networks
5. Enable new use cases in DeFi, enterprise, and consumer applications

Copyright

Copyright and related rights waived via CC0.

[Jake151987]

I hold the secp256r1 precompile is a necessary measure to meet wider ecological compatibility and functional integrity requirements; additionally, it is an urgent need to keep up with industry standards. Do you have a timeline for implementing this support?

[raymondliu0711]

I hold the secp256r1 precompile is a necessary measure to meet wider ecological compatibility and functional integrity requirements; additionally, it is an urgent need to keep up with industry standards. Do you have a timeline for implementing this support?

Thanks for your attention. I don't have a concrete timeline yet.

Ethereum just announced they'll include it in next upgrade, so I think we need the same comprehensive consideration. Like other crypto-related precompiles, this TIP needs community discussion around its necessity, urgency, and implementation approach before we can nail down a specific plan.

[fyyhtx]

@raymondliu0711 The text mentions that ECDSA signature verification can be efficiently executed in TVM. Compared to the current ECDSA signature verification methods, how much can the performance be improved?

[Federico2014]

@raymondliu0711 The text mentions that ECDSA signature verification can be efficiently executed in TVM. Compared to the current ECDSA signature verification methods, how much can the performance be improved?

It says that secp256r1 verification is significantly slower than the current ECRECOVER precompile. So ECRECOVER precompile costs 3000 gas while secp256r1 costs 6900 gas.

[lxcmyf]

@raymondliu0711
The gas cost of the new proposal (6900) is twice that of RIP-7212 (3450), but the document only mentions "benchmark testing that is closer to actual implementation". Is there specific performance testing data to support this adjustment? For example, how to compare the verification time of secp256r1 and secp256k1 in different hardware environments?

[sYNCHROtime]

Does secp256r1 have any advantages over secp256k1 besides widespread hardware support, such as in terms of security?

[raymondliu0711]

@raymondliu0711 The gas cost of the new proposal (6900) is twice that of RIP-7212 (3450), but the document only mentions "benchmark testing that is closer to actual implementation". Is there specific performance testing data to support this adjustment? For example, how to compare the verification time of secp256r1 and secp256k1 in different hardware environments?

EIP-7951 is still in Draft status and actively being refined. Ethereum just updated the gas cost to 6900 in early July's ACDE, but didn't show detailed benchmark data. They stated that Devnet-3 will focus on benchmarking and updating the gas costs.

We'll continue tracking the progress of this EIP.

[raymondliu0711]

Does secp256r1 have any advantages over secp256k1 besides widespread hardware support, such as in terms of security?

You're right - the main advantage of secp256r1 is indeed widespread hardware support. From a security perspective, both curves provide the same 128-bit security level as mentioned.

The key benefit is that secp256r1 is natively supported by modern secure hardware. This enables features that users can sign transactions with their device's authentication, making interactions more secure and user-friendly.