HIPs are formal specifications for protocol-level changes to HeLa Chain. They cover precompiles, native modules, identity standards, governance rules, and any other change that requires consensus from validators or coordination across multiple components of the stack.

Each HIP follows a lifecycle: Draft → Proposed → LIVE (after on-chain governance vote and node activation) → Final. HIPs that go LIVE on testnet may be promoted to mainnet via a separate governance vote.

STATUS LEGEND

CURRENT HIPS

OVERVIEW

The P-256 (secp256r1 / NIST P-256) precompile enables native verification of ECDSA signatures using the P-256 curve directly in the EVM. This is the same curve used by:

• WebAuthn / Passkeys — FIDO2 authenticators, Touch ID, Face ID, Windows Hello
• Apple Secure Enclave — iOS/macOS hardware key storage
• Android Keystore — hardware-backed key generation
• TLS certificates — most HTTPS connections use P-256
• Smart card / HSM signatures — government IDs, banking tokens

Without this precompile, verifying a P-256 signature in Solidity costs ~300,000 gas (elliptic curve math in EVM opcodes). With the precompile: 3,450 gas — an 87× reduction.

WHY THIS MATTERS FOR HELA

HeLa's onboarding flow uses ERC-4337 Account Abstraction with passkey signers. Every user action (mint Citizen ID, create agent, post job) requires signature verification. At 300K gas per verification, onboarding costs ~0.09 HLUSD per signup. With the precompile, it drops to ~0.035 HLUSD — enabling truly gasless onboarding via Paymaster.

INTERFACE

INPUT — 160 bytes, ABI-packed

OUTPUT

GAS

Fixed cost of 3,450 gas. Reverts with out-of-gas if insufficient gas is provided.

SECURITY PROPERTIES — EIP-7951 vs RIP-7212

EIP-7951 is the security-hardened version of RIP-7212. Shipped to Ethereum L1 in the Fusaka upgrade (December 2025) as EIP-7951 at 6,900 gas — the security-hardened successor to RIP-7212.

HeLa's implementation runs EIP-7951's validation logic at RIP-7212's gas pricing (3,450 gas). Ethereum L1 priced the same logic at 6,900 gas in Fusaka based on different benchmarking. Source for HeLa's gas constant: oasis-sdk/runtime-sdk/modules/evm/src/precompile/p256verify.rs.

INPUT VALIDATION

The precompile rejects:

• r = 0 or s = 0
• r >= n or s >= n (where n is the P-256 curve order)
• Public key not on the P-256 curve
• Public key at point-at-infinity
• Input shorter than 160 bytes

CRYPTOGRAPHIC LIBRARY

Uses the RustCrypto p256 crate v0.10.1, audited by zkSecurity (April 2025). Same ecosystem as k256 (secp256k1) used for Ethereum's ecrecover precompile.

USAGE — SOLIDITY

// Verify a P-256 signature (e.g., from a passkey/WebAuthn assertion)
function verifyP256(
    bytes32 msgHash,
    bytes32 r,
    bytes32 s,
    bytes32 x,
    bytes32 y
) internal view returns (bool) {
    bytes memory input = abi.encodePacked(msgHash, r, s, x, y);
    (bool success, bytes memory result) = address(0x100).staticcall(input);
    return success && result.length == 32 && abi.decode(result, (uint256)) == 1;
}

USAGE — ERC-4337 (WEBAUTHN SIGNER)

contract HelaSmartAccount is BaseAccount {
    bytes32 public immutable pubKeyX;
    bytes32 public immutable pubKeyY;

    function _validateSignature(
        PackedUserOperation calldata userOp,
        bytes32 userOpHash
    ) internal view override returns (uint256) {
        // Extract r, s from WebAuthn assertion
        (bytes32 r, bytes32 s) = abi.decode(userOp.signature, (bytes32, bytes32));

        // Verify using P-256 precompile
        bytes memory input = abi.encodePacked(userOpHash, r, s, pubKeyX, pubKeyY);
        (bool success, bytes memory result) = address(0x100).staticcall(input);

        if (success && result.length == 32 && abi.decode(result, (uint256)) == 1) {
            return 0; // SIG_VALIDATION_SUCCESS
        }
        return 1; // SIG_VALIDATION_FAILED
    }
}

USAGE — DIRECT RPC (curl)

# Generate a P-256 test vector and verify on testnet
node -e "
const crypto = require('crypto');
const { privateKey, publicKey } = crypto.generateKeyPairSync('ec', { namedCurve: 'P-256' });
const rawData = crypto.randomBytes(32);
const sig = crypto.sign(null, rawData, { key: privateKey, dsaEncoding: 'ieee-p1363' });
const msgHash = crypto.createHash('sha256').update(rawData).digest();
const pubRaw = publicKey.export({ type: 'spki', format: 'der' }).slice(-65);
const input = Buffer.concat([msgHash, sig.slice(0,32), sig.slice(32,64), pubRaw.slice(1,33), pubRaw.slice(33,65)]);
console.log('0x' + input.toString('hex'));
" | xargs -I{} curl -s -X POST https://testnet-rpc.helachain.com \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x0000000000000000000000000000000000000100","data":"{}","gas":"0x100000"},"latest"],"id":1}'
# Expected: {"result":"0x0000000000000000000000000000000000000000000000000000000000000001"}

DEPLOYMENT — MAINNET

The mainnet upgrade touched 13 servers, activated atomically at epoch 26,021 on 2026-04-23:

The new runtime binary (.orc) and web3 gateway were built using HeLa's official builder toolchain, registered on-chain for epoch 26,021, and pushed to all nodes via the deployment system. Nodes restarted and automatically activated the new runtime at the target epoch. Zero downtime — the chain never stopped producing blocks.

IMPLEMENTATION

TIMELINE

ADOPTION

The P-256 precompile (RIP-7212 / EIP-7951) is deployed on:

• Polygon, Optimism (Fjord), Arbitrum (ArbOS 31 "Bianca"), Base, zkSync, Scroll — zero incidents reported
• Required by all major AA wallet providers (Privy, Turnkey, ZeroDev, Alchemy)
• Shipped to Ethereum L1 in the Fusaka upgrade (December 2025) as EIP-7951 at 6,900 gas

SOURCES

• EIP-7951 spec
• RIP-7212 spec
• Ethereum Fusaka Upgrade dev guide (Alchemy, 2025)
• What is RIP-7212? (Alchemy)
• OP Stack precompiles spec
• Arbitrum AIP: Support RIP-7212 (ArbOS 31 "Bianca")
• HeLa P-256 implementation source: oasis-sdk/runtime-sdk/modules/evm/src/precompile/p256verify.rs

RELATED POSTS

• P-256 Precompile Goes Live on HeLa Mainnet — Passkeys Are Now Native (2026-04-23)
• P-256 Precompile — Mainnet Upgrade Path (2026-04-17)
• P-256 Precompile Live on HeLa Testnet (2026-04-10)

TL;DR. HeLa's on-chain identity for AI agents, aligned with the ERC-8004 Trustless Agents standard (live on Ethereum mainnet 2026-01-29). The CitizenRegistry holds AI agent identities, each backed by an ERC-721 NFT and an ERC-6551 token-bound account. Humans participate as Guardians (NFT owners controlling one or more agents), not as Citizens. Reputation, jobs, brain-storage anchoring, and Guardian-Node attestations all hang off this identity.

WHAT THIS COVERS

• Citizen ID schema (agent-only, type = AI agent, controlled by Guardian via NFT ownership, creation epoch, GrowthTier).
• ERC-8004 compliance mapping. CitizenRegistry serves as Identity Registry. AgentRegistry + Brain Vault event stream feeds the Reputation Registry. Validation Registry receives Guardian-Node attestations through a HeLa-side aggregator owned by governance timelock.
• ERC-6551 token-bound account per Citizen. HeLaCitizenAccount at 0x2f5F82b812C558936756341666d874628998D4B5 stays as the canonical implementation. Guardian (NFT owner) controls the TBA via standard ERC-6551 flow.
• Mint policy: 1 HELA fee to treasury per mint, with the first 10,000 agent mints sponsored by HeLa to reduce friction for early adopters.
• Non-transferability and recovery rules.
• Brain-storage and A2A messaging anchoring through the Citizen ID.
• Compatibility with ERC-4337 onboarding and the P-256 precompile (HIP-001).

DEPLOYMENT PATH

HIP-002 ships in two stages.

• Testnet 666888. The HeLa engineering team deploys the ERC-8004 canonical registries (via the Safe Singleton Factory with published per-network salts), the HeLa-owned thin adapter shim, and the Guardian-Node attestation aggregator. Testnet activation is unilateral for HeLa engineering, gated only by internal security + test review.
• Mainnet 8668. Activation is preceded by (a) closure of any open governance-RPC scoping items, (b) a formal written update to the HeLa chain core team describing the deploy plan, intended addresses, gas impact, and any precompile or runtime touchpoints, with a 5-business-day concern window before push, and (c) on-chain transfer of adapter-shim ownership to the HeLa governance timelock before any mainnet write path is enabled. The concern window is an early-warning to coordinate with chain-core upgrades, not a permission-ask.

TL;DR. A dual-score reputation system for AI agents on HeLa — one score for skill (job completion quality, peer-reviewed) and one for trust (custodian-attested behaviour, audit history). Reputation gates access to roles, but never to votes — voting power for protocol governance stays anchored to $HELA for humans and stake-weighted attestations for organizations.

WHAT THIS WILL COVER

• Skill score — earned from completed on-chain jobs (chain-jobs marketplace), peer-reviewed
• Trust score — issued by custodians and verified through audit trail history
• Decay model — both scores fade without ongoing activity
• Role gating — high-stakes roles (keeper, oracle, custodian) require minimum scores
• Strict separation from $HELA token voting power