DEV Community: Vano Chkheidze

UltrafastSecp256k1 v4.0 — Optional Secondary secp256k1 Backend for Evaluation

Vano Chkheidze — Sun, 17 May 2026 00:47:55 +0000

Overview
UltrafastSecp256k1 v4.0 is a high-performance secp256k1 engine built for evaluation as an optional secondary backend for Bitcoin Core. The goal is not to replace libsecp256k1, but to make it possible to measure, compare, and selectively enable an alternative implementation under controlled conditions.

This post presents the current state of the project, its integration model, and the evidence gathered through continuous audit infrastructure.

Repository: https://github.com/shrec/UltrafastSecp256k1 Release v4.0.0: https://github.com/shrec/UltrafastSecp256k1/releases/tag/v4.0.0

Integration Model
Integration uses a shim layer that exposes the identical secp256k1.h API surface. Bitcoin Core can be built with the alternative backend using a single CMake flag:

cmake -B build -DSECP256K1_BACKEND=ultrafast
cmake --build build
The default backend remains libsecp256k1 unchanged. All existing Bitcoin Core C++ source files remain unmodified — only the CMake build system references a different library.

Fork demonstrating this integration: https://github.com/shrec/bitcoin/tree/feature/ultrafast-secp256k1-backend

Shim API coverage:

secp256k1.h — context, pubkey, seckey
secp256k1_extrakeys.h — keypair, x-only pubkey (BIP-340/341)
secp256k1_schnorrsig.h — Schnorr sign/verify (BIP-340)
secp256k1_ecdh.h — ECDH
secp256k1_recovery.h — ECDSA recovery
secp256k1_ellswift.h — ElligatorSwift (BIP-324)
secp256k1_musig.h — MuSig2 (BIP-327, all 14 functions)
Performance — Bitcoin Core Integration Paths
All numbers from bench_bitcoin (Bitcoin Core's native benchmark harness) on Intel i5-14400F, GCC 14.2.0, Release+LTO, intel_pstate/no_turbo=1, taskset -c 0, nice -20, 5 runs.

Canonical artifact: docs/BITCOIN_CORE_BENCH_RESULTS.json

Transaction signing:

Benchmark Ultra libsecp256k1 Delta
SignSchnorrWithMerkleRoot 83.9 µs 113.4 µs +35% faster
SignSchnorrWithNullMerkleRoot 84.0 µs 113.0 µs +35% faster
SignTransactionECDSA 149.5 µs 165.1 µs +10% faster
SignTransactionSchnorr 125.4 µs 137.5 µs +10% faster
Script verification:

Benchmark Ultra libsecp256k1 Delta
VerifyScriptP2TR_KeyPath 45.4 µs 46.3 µs +2.0% faster
VerifyScriptP2TR_ScriptPath 76.5 µs 83.8 µs +10% faster
VerifyScriptP2WPKH 46.0 µs 45.8 µs parity (within noise)
Block validation aggregate (ConnectBlock, 2000 unique signatures):

Scenario Ultra libsecp256k1 Delta
All ECDSA 254.3 ms 257.4 ms +1.2% faster
All Schnorr 253.0 ms 255.3 ms +0.9% faster
Mixed (2k Schnorr + 1k ECDSA) 253.9 ms 257.7 ms +1.5% faster
Without LTO: ConnectBlock is ~0.5–1.0% slower than libsecp256k1 due to i-cache pressure from a larger code footprint. LTO is required for Ultra to win the aggregate. This tradeoff is documented in docs/SHIM_KNOWN_DIVERGENCES.md.

Bitcoin Core test suite: 749/749 passing with Ultra backend (GCC 14.2.0, May 2026).

Performance — Constant-Time Signing Primitives
From docs/bench_unified_2026-05-16_gcc14_x86-64.json. CT-vs-CT co-measured in the same run (ratios are TSC-independent):

Operation Ultra CT libsecp256k1 Ratio
CT ECDSA sign 21.6 µs 59.7 µs 1.30× faster
CT Schnorr sign (BIP-340) 18.1 µs 46.5 µs 1.28× faster
Schnorr verify 84.3 µs 84.3 µs equal
Field arithmetic primitives:

Primitive Ultra libsecp256k1 Ratio
field_mul 20.1 ns 26.5 ns 1.32×
field_sqr 18.7 ns 22.3 ns 1.19×
field_inv 1253.9 ns 1506.0 ns 1.20×
field_from_bytes 4.8 ns 13.0 ns 2.71×
Continuous Audit and Assurance (CAAS)
The repository includes a continuous audit infrastructure tracking security regressions across every commit.

Current state at v4.0.0:

262 exploit PoC modules covering 20+ CVE/attack classes — all pass
369 total audit modules (262 exploit PoC + 107 non-exploit)
CAAS autonomy score: 100/100 (8/8 gates)
Source: docs/SECURITY_AUTONOMY_KPI.json

Audit surfaces include: nonce reuse, side-channel timing (dudect), CT boundary verification, batch verify soundness, MuSig2/FROST protocol attacks, adaptor signatures, DER BIP-66 strict parsing, BIP-340/RFC-6979 known-answer tests, Wycheproof vectors, structure-aware fuzzing, differential testing vs libsecp256k1, and Python-based algebraic property testing.

Security properties enforced:

Constant-time signing: ECDSA, Schnorr, MuSig2, FROST, BIP-324 XDH
Per-context DPA blinding (secp256k1_context_randomize fully implemented)
Strict scalar parsing for private key inputs (parse_bytes_strict_nonzero)
Fail-closed batch signing APIs
BIP-66 strict DER enforcement in all shim paths
Benchmarking Methodology
Benchmarks distinguish between:

CT vs CT — constant-time Ultra signing vs constant-time libsecp signing (production-equivalent, fair comparison)
Bitcoin Core integration — bench_bitcoin binary, real validation pipeline
LTO vs no-LTO — both measured and documented
Warm-cache vs cold-cache — noted where applicable
All claimed improvements include error percentage from nanobench's internal statistics. Inconclusive results (overlapping ranges) are reported as such. Results are reproducible from the canonical JSON artifacts in the repository.

Reproducibility
Builds are deterministic:

-ffile-prefix-map strips source paths from debug info
SOURCE_DATE_EPOCH awareness
Fixed -march=x86-64-v3 (no host-native variation)
SLSA provenance attached to v4.0.0 release artifacts (via Sigstore/Cosign)
Platform Coverage
CI passing on all platforms as of v4.0.0:

Platform Architecture Compiler
Linux x86-64-v3 GCC 14 / Clang 17
Linux ARM64 GCC 14
Linux RISC-V 64 GCC 14
macOS ARM64 (Apple Silicon) Clang 15
Windows x86-64 MSVC / GCC
Additional: Android ARM64 (NDK), WASM, ESP32, STM32.

Known Limitations
ConnectBlock improvement requires Release+LTO. Without LTO: ~0.5–1.0% slower than libsecp256k1.
GPU backends (CUDA, OpenCL, Metal) are present but not part of the Bitcoin Core evaluation profile.
This covers the CPU backend only.
Current Objective
No mandatory integration path is proposed. The current objective is to make an alternative backend available for evaluation on technical grounds, with reproducible evidence, minimal integration surface, and an easy rollback path.

The default backend remains libsecp256k1. All existing behavior is preserved unless the new backend is explicitly enabled at build time.

Reviewer Entry Path
git clone https://github.com/shrec/UltrafastSecp256k1
cd UltrafastSecp256k1
python3 ci/verify_external_audit_bundle.py --allow-commit-mismatch
Key documents:

docs/BITCOIN_CORE_BACKEND_EVIDENCE.md — full reviewer package
docs/BENCHMARKS.md — benchmark methodology and raw data
docs/AUDIT_CHANGELOG.md — security audit history
docs/SHIM_KNOWN_DIVERGENCES.md — documented behavioral differences from libsecp256k1
All performance numbers are from controlled benchmark runs with hard turbo lock. Raw data available in the repository. Canonical benchmark artifact: docs/BITCOIN_CORE_BENCH_RESULTS.json, docs/bench_unified_2026-05-16_gcc14_x86-64.json.

UltrafastSecp256k1 v3.67.0

Vano Chkheidze — Wed, 22 Apr 2026 09:08:35 +0000

v3.67.0 — CAAS hardening, multi-CI reproducible builds, OpenSSF Scorecard cleanup, Zenodo + funding outreach
This release closes the remaining CAAS gap-closure roadmap, lands the multi-CI reproducible-build attestation surface, brings the OpenSSF Scorecard code-scanning queue to zero open alerts, and pre-stages Zenodo metadata + a funding-outreach playbook. No public-API or ABI breakage; no behavioral changes to the crypto engine.

Highlights
Continuous Audit (CAAS) — roadmap complete
All eleven CAAS hardening items (H-1 … H-11) closed in a single sweep.
Gap-closure roadmap G-1 … G-10 closed: threat model, RNG entropy attestation, hardware side-channel methodology, compliance stance, INTEROP matrix, multi-CI reproducible builds, CT-tool independence, SPEC traceability matrix, protocol spec, traceability-join gate, RFC 9116.
scripts/audit_gate.py now wires G-1 / G-1b / G-8 / G-10 as first-class sub-gates; caas_runner.py is fail-fast across all five stages.
scripts/check_exploit_wiring.py enforces the Exploit / Audit Test Conversion Standard at CAAS Stage 0 — every audit/test_exploit_*.cpp file must be wired into unified_audit_runner.cpp or the gate refuses the push.
Audit dashboard refreshed: hardening progress 12/12 (100%).
Multi-CI reproducible-build attestation
.gitlab-ci.yml and .woodpecker.yml (Codeberg) added alongside the existing GitHub Actions surface — the same release artifact is now built on three independent CI providers and verified byte-identical via SHA-256.
docs/MULTI_CI_REPRODUCIBLE_BUILD.md documents the protocol; docs/SUPPLY_CHAIN_LOCAL_PARITY.md describes the local-parity check.
INTEROP differential testing
First INTEROP §2 reference wired: OpenSSL 3.x random-vector differential PoC (audit/test_exploit_differential_openssl.cpp), advisory module, host-only.
INTEROP §3 closure tracked for k256 (Rust), btcd (Go), BoringSSL, WolfSSL, NSS, MuSig2 wire, FROST wire.
OpenSSF Scorecard — code-scanning queue cleared
All open code-scanning alerts on main resolved.
PinnedDependenciesID (6): every GitHub Action pinned by 40-character SHA in mutation-weekly.yml, rocm-smoke.yml, and formal-verification.yml; pip installs in those workflows switched to pip install --require-hashes -r ... against new hash-pinned requirement files.
TokenPermissionsID (1 fixed in code): caas-evidence-refresh.yml top-level contents: write dropped to read; write retained only at the job level where the workflow actually pushes refreshed evidence back to dev.
Six remaining TokenPermissionsID alerts dismissed as legitimate job-scoped writes (release sync-docs, audit-report publish to gh-pages, bench-regression baseline push, three ClusterFuzzLite SARIF uploads).
BranchProtectionID resolved at config level: main-protection ruleset hardened — bypass_actors=, required_approving_review_count=2, require_code_owner_review=true, require_last_push_approval=true, dismiss_stale_reviews_on_push=true.
Crypto bug-pattern scanner
13 CVE-grounded pattern checkers added to scripts/dev_bug_scanner.py (timing-dependent branches on secret data, missing zeroization, RFC 6979 misuse patterns, ECDSA nonce reuse signatures, scalar-mod-n omission, …).
False-positive reduction pass across eight checkers; investigation report at docs/SCANNER_INVESTIGATION_REPORT.md.
GPU backend parity
schnorr_snark_witness_batch parity gap closed via deterministic host-side CPU fallback in gpu/src/gpu_backend_fallback.cpp — CUDA, OpenCL, and Metal now all return correct byte-identical results. Native GPU kernels remain a future optimisation; public-data-only operation.
Cross-compile / CI fixes
arm64 + riscv64 cross-compile no longer picks up host OpenSSL headers via bare __has_include. The OpenSSL gate is now driven by a CMake UFSECP_HAVE_OPENSSL=1 define that is only set when find_package(OpenSSL) actually links — the source guard requires both the define and __has_include.
-Werror build no longer trips on OpenSSL EC_KEY deprecation warnings (pragma block scoped to the differential PoC).
CAAS verdict accepts both PASS and PASS with advisory.
Visibility surface
.zenodo.json added — academic metadata staged for the next release; the next release-tag push will trigger Zenodo archival and DOI minting (Zenodo↔GitHub OAuth toggle is enabled).
README.md "Cite this work" section + DOI badge placeholder.
CITATION.cff linked from "Where to Start"; docs/ADOPTION.md and docs/FUNDING_TARGETS.md linked next to it.
docs/FUNDING_TARGETS.md — funding playbook covering Bitcoin grant programmes (HRF, OpenSats, Brink, Spiral, Strike Catalyst, MIT DCI), Ethereum programmes (EF ESP, Protocol Guild, EF Academic, Optimism RetroPGF, Arbitrum, Coinbase / Base), EU / cross-cutting (NLnet NGI Zero, Sovereign Tech Fund, OSTIF, GitHub Accelerator, a16z crypto Open Source Grants), with 30-second + 5-minute pitches and an evidence-pointer column.
README.md hero block now carries explicit CTAs: a one-line invitation for production users to PR themselves into docs/ADOPTION.md, and a one-line pointer for prospective sponsors to docs/FUNDING_TARGETS.md.
Documentation reconciliation
Exploit-PoC counts reconciled across all audit docs to the real number (189).
Non-exploit module + CI workflow counts reconciled to reality.
docs/SPEC_TRACEABILITY_MATRIX.md paths reconciled; traceability-join gate flipped to strict by default.
Compatibility
C ABI: unchanged.
Public C++ API: unchanged.
GPU backend GpuBackend virtual interface: one method (schnorr_snark_witness_batch) gained a deterministic CPU fallback; previously returned Unsupported on every backend.
Reproducible build: byte-identical to v3.66.0 for the engine + library outputs; only CI / docs / audit-tooling surface changed.
Adoption
Sparrow Wallet Frigate ships UltrafastSecp256k1 by default since 1.4.0. See docs/ADOPTION.md for the integration details and Craig Raw's independent benchmarks.

Cite this work
This release will be archived on Zenodo with a DOI assigned automatically once the tag push completes. See .zenodo.json and CITATION.cff.

https://github.com/shrec/UltrafastSecp256k1/releases/tag/v3.67.0
https://github.com/shrec/UltrafastSecp256k1

# I Replaced a $100K Security Audit with a CI Pipeline — And It Caught More Bugs

Vano Chkheidze — Tue, 14 Apr 2026 01:34:17 +0000

When I built UltrafastSecp256k1 — a high-performance secp256k1 cryptography library targeting CPU, CUDA, OpenCL, Metal, ESP32, and a dozen other platforms — I faced a decision every serious crypto library author eventually faces.

"You need a third-party audit."

The quotes I got: $80K–$120K. Two weeks of engagement. A PDF. No contractual accountability for what happens after the next commit.

I couldn't afford it. And honestly, once I understood what I was actually buying, I didn't want it.

So I built something else.

The Problem With Snapshot Audits

The dominant model is:

code → audit firm reviews for 2 weeks → PDF published → trust badge acquired

The structural flaw: it's a snapshot, not a system.

A PDF tells you the state of the code at the moment of review. It says nothing about what happens after the next commit, after a new platform port, after a new protocol feature lands. The "audit passed" badge persists even if the code is completely rewritten.

Consider: Heartbleed lived in OpenSSL for two years. OpenSSL had been reviewed by expert eyes and was trusted everywhere. The problem wasn't that too few people looked — it's that no system continuously checked the specific property that failed.

A missing bounds check. Two years. Production everywhere.

What I Built Instead: CAAS

Continuous Adversarial Audit System.

The core principle: every security claim must be backed by an executable test that runs on every commit.

Not "we believe this is constant-time." But: "ct-verif LLVM pass, Valgrind taint analysis, and dudect statistical timing all pass for this function — on every commit, across x86-64 and ARM64."

Here's what CAAS looks like in practice for UltrafastSecp256k1:

The Numbers

Metric	Value
Assertions per build	~1,000,000+
Exploit PoC tests	187 files, 171 registered modules
CI workflows	36 GitHub Actions
Nightly differential checks	1,300,000+ vs libsecp256k1 reference
CT verification pipelines	3 independent (LLVM ct-verif + Valgrind + dudect)
Formal proofs	Z3 SMT (17 proofs) + Lean 4 (19 theorems) on SafeGCD
Build matrix	595 combinations (7 arch × 17 config × 5 OS)

The Bug Capsule System

When a bug is found — by me, by a contributor, by fuzzing, by a new ePrint paper — it becomes a permanent regression test:

{
  "id": "BUG-2026-0001",
  "category": "CT",
  "severity": "critical",
  "title": "CT branch leak in ecdsa_sign_recoverable low-s normalization",
  "fix_commit": "0a93ff4b",
  "affected_functions": ["ct::ecdsa_sign_recoverable"],
  "expected": { "result": "no_timing_leak", "timing_threshold": 10.0 },
  "exploit_poc": true
}

Run python3 scripts/bug_capsule_gen.py capsule.json and it generates:

A deterministic regression test (.cpp)
An exploit PoC test (if exploit_poc: true)
A CMakeLists.txt CTest fragment

The bug can never silently return. The knowledge is encoded in the test suite, not in anyone's memory.

A Real Example: RISC-V CT Leak

When I ported to RISC-V, the CT verification pipeline caught a timing side-channel on the first run. GCC was optimizing constant-time code into secret-dependent branches — because the RISC-V backend had different optimization behavior than x86-64.

A snapshot audit done on x86-64 would never have seen this. The PDF would say "constant-time: verified." The RISC-V port would ship with a private key leak.

CAAS caught it in the same commit as the port. Bug capsule created. CI gate added. Can never regress.

The Custom Static Analyzer

dev_bug_scanner.py is a 700-line domain-specific static analyzer with 28 rule classes — including rules that generic tools like Clang-Tidy and CodeQL simply cannot catch:

# CT_VIOLATION: fast:: call in CT-required signing path
# TAGGED_HASH_BYPASS: plain sha256() where BIP-340 tagged_hash required  
# SECRET_UNERASED: Scalar without secure_erase on signing path exit
# RANDOM_IN_SIGNING: getrandom() in RFC 6979 deterministic path

These patterns are invisible to generic analyzers because they require secp256k1 domain knowledge. fast::scalar_mul() in a signing function is valid C++ — but it's a side-channel vulnerability.

Full Reproducibility

Everything runs locally in Docker:

# Exact GitHub CI environment, locally
docker compose -f docker-compose.ci.yml run --rm pre-push   # ~5 min gate
docker compose -f docker-compose.ci.yml run --rm gh-parity  # Full GitHub parity

# Auditor challenge environment — self-contained, no setup
docker build -f Dockerfile.auditor -t ufsecp-auditor .
docker run --rm ufsecp-auditor  # runs full audit suite

# Bit-for-bit reproducible build verification
docker build -f Dockerfile.reproducible -t uf-repro-check .
docker run --rm uf-repro-check  # compares two independent builds

An external auditor doesn't need to install a toolchain. The Docker image includes libsecp256k1, @noble/secp256k1, coincurve, and python-ecdsa for differential testing — all hash-pinned.

What Happened With Real-World Adoption

Craig Raw, author of Sparrow Wallet, integrated the library into Frigate — a DuckDB-based Silent Payments scanner used for real Bitcoin mainnet transactions.

Real-world scan result: 2× RTX 5090 scans 2 years of Bitcoin mainnet transactions (133M tweaks) in 3.2 seconds using this library. That's ~41.5 million BIP-352 operations per second.

What CAAS Does Not Claim

Full transparency matters:

No third-party audit yet. This is acknowledged openly. CAAS is designed to make one as efficient as possible when it happens — but it hasn't happened yet.
GPU CT is code-discipline only. Vendor JIT compilers (CUDA PTX assembler, Metal, OpenCL runtime) transform kernels at runtime. The 3-pipeline formal CT verification applies to CPU only. Production signing always routes through CPU.
Novel attacks. By definition, no prior PoC covers unknown unknowns. 11 fuzz harnesses and CT analysis are the mitigations.

The Actual Cost Comparison

Approach	Cost	Coverage	Ages?	Accountability?
Snapshot audit	$80–120K	Bounded time window	Yes, immediately	"Reasonable effort"
CAAS + bug bounty	$5–10K bounty pool	Continuous, adversarial	No	CI fails = hard stop

The $100K buys a PDF with "reasonable effort" liability language. $10K in bug bounties buys adversarial researchers with economic incentive to find what breaks — and every finding becomes a permanent CI gate.

Fork It

The entire infrastructure is MIT-licensed and ships with the library:

git clone https://github.com/shrec/UltrafastSecp256k1.git

You get: 171 exploit PoC tests, 36 CI workflows, Docker environment, dev_bug_scanner.py, bug capsule system, source graph, AI memory — the accumulated security knowledge of every platform port, every bug found, every ePrint paper evaluated.

A startup that forks this doesn't start from zero security. They start from a system that has already caught a RISC-V CT leak, a Metal field arithmetic truncation affecting 0.05% of inputs, an OpenCL carry propagation bug, a CT branch leak in ECDSA signing.

That's the compound effect that a PDF can never provide.

UltrafastSecp256k1 is open source under MIT. Full documentation at github.com/shrec/UltrafastSecp256k1. Discussions on Discord.

UltrafastSecp256k1 v3.60

Vano Chkheidze — Sat, 04 Apr 2026 16:57:42 +0000

v3.60.0 — Audit Campaign Wave II · ZK Layer · Full GPU Parity · Wallet API · Performance

Release date: 2026-04-04
Previous release: v3.50.0 (2026-03-XX)
Commits since v3.50.0: 50+
ABI-compatible with v3.50.x — drop-in upgrade

Security & Correctness

ECDSA large-x fix (cpu/src/ecdsa.cpp) — corrected r_less_than_pmn comparison in both FE52 and 4×64 paths. Wrong PMN constants assumed limb[2]=0; actual p−n has limb[2]=1. Signatures where k·G.x ∈ [n, p−1] (~2⁻¹²⁸ probability per sig) were incorrectly rejected. Equivalent to the Stark Bank CVE-2021-43568..43572 false-negative class. Found and confirmed by Wycheproof tcId 346. ([ea8cfb3c])
ECDSA r-overflow test suite (audit/test_exploit_ecdsa_r_overflow.cpp) — 19 checks: k·G.x ≥ n accept case (tcId 346), r=p−3 strict-parse rejection, r=n zero-reduction reject, r=0 reject, range sanity and sign/verify consistency. Closes Wycheproof PR #206 / Stark Bank CVE assurance gap.
Wycheproof ECDSA Bitcoin vectors (audit/test_wycheproof_ecdsa_bitcoin.cpp) — 53 checks: BIP-62 low-S enforcement, tcId 346/347/348/351, high-S malleability boundary, r=0/s=0 special-value rejection, point-at-infinity rejection during verify.
CUDA jacobian_add_mixed_unchecked infinity flag — missing r->infinity = false in the normal code path caused generator table entries table[3..15] to carry uninitialized infinity flags. Scalars with many consecutive high nibbles (e.g. n−1) hit table[15] and produced wrong public keys. All 52/52 CUDA signing tests now pass.
ASan/UBSan clean: 210/210 C++ tests pass under -fsanitize=address,undefined -fno-sanitize-recover=all after full rebuild.

Exploit PoC / Audit Coverage (Wave II)

Suite	Tests	What it proves
`test_exploit_schnorr_nonce_reuse.cpp`	SNR-1..16	Nonce reuse → full privkey recovery via `d' = (s1−s2)·(e1−e2)⁻¹ mod n`; RFC6979 safety
`test_exploit_bip32_child_key_attack.cpp`	CKA-1..18	xpub + child_sk → parent_sk recovery; chained grandchild→child→master; hardened blockage
`test_exploit_frost_identifiable_abort.cpp`	FIA-1..14	`frost_verify_partial()` correctly attributes bad partial sigs; multi-cheater, honest subset
`test_exploit_hash_algo_sig_isolation.cpp`	HAS-1..11	Cross-hash confusion rejected; Schnorr↔ECDSA format confusion; domain prefix isolation
`test_exploit_zk_adversarial.cpp`	14 tests	Malformed/forged ZK proofs: garbage bytes, scalar overflow, identity pubkey, 64-byte-flip
`test_exploit_pedersen_adversarial.cpp`	12 tests	Switch commitment security, imbalanced verify_sum, double-spend detection
`test_exploit_ethereum_differential.cpp`	10 tests	go-ethereum / web3.py / ethers.js KAT vectors, ecrecover, EIP-155/EIP-191, keccak256
`test_fuzz_musig2_frost.cpp`	15 tests	MuSig2 key_agg/nonce_agg/partial_verify; FROST keygen/sign/verify random inputs (5000+ rounds)
`test_wycheproof_ecdsa_bitcoin.cpp`	53 checks	Wycheproof BIP-62 + large-x vectors
`test_exploit_ecdsa_r_overflow.cpp`	19 checks	Wycheproof PR #206 r-overflow class
EIP-712 KAT	12 tests	Typed structured data, 13 assertions

Python Dynamic Audit Suite (9 CTest targets)

All powered by --lib path/to/libufsecp.so, integrated in CI and unified_audit_runner:

CTest target	Checks	What it catches
`py_differential_crossimpl`	1000+	Wrong low-S, pubkey parity bugs, ECDH mismatches (vs coincurve + python-ecdsa)
`py_nonce_bias`	10,000+ ops	Chi-squared + KS + per-bit sweep (Minerva/TPM-FAIL-class biases)
`py_rfc6979_spec`	200+	Independent RFC 6979 §3.2 HMAC-SHA256 nonce derivation + Appendix A.2.5 KAT
`py_bip32_cka`	—	Live BIP-32 parent key recovery demo + hardened immunity
`py_glv_exhaustive`	5000+ scalars	GLV decomposition — adversarial Babai-boundary scalars vs coincurve reference
`py_semantic_props`	1450+	Algebraic properties (kG+lG==(k+l)G), roundtrip, determinism, Hypothesis
`py_invalid_input_grammar`	37	Structured rejection — bad prefix, x≥p, sk=0/n, r=0/s=0, invalid BIP-32 paths
`py_stateful_sequences`	401+	Error-injection recovery, BIP-32 multi-level consistency, 5000-op endurance
`py_dev_bug_scan`	221 files	15-category static scanner: NULL, CPASTE, SIG, RETVAL, MSET, OB1, ZEROIZE, …

ClusterFuzzLite expanded to 5 targets: added fuzz_ecdsa.cpp (sign→verify invariant, wrong-msg, compact parse) and fuzz_schnorr.cpp (BIP-340 sign→verify, adversarial from_bytes).

Performance

Path	Before	After	Delta
CUDA ECDSA Sign (w=8 generator table)	220.9 ns	198.3 ns	−10.2%
CUDA/OpenCL/Metal MSM (GLV Shamir w=1 scatter)	baseline	+18–24%	+18–24%
ARM64 ECDSA Sign (SHA-2 HW accel)	25.89 µs	22.22 µs	−14.2%
ARM64 Schnorr Sign (precomputed)	17.73 µs	16.67 µs	−6.0%
Bulletproof MSM verifier	5,079 µs	2,634 µs	−48% (1.93×)
CPU KPlan zero-alloc (stack wnaf arrays)	heap	stack	alloc eliminated
BIP-352 SHA-256 tag midstate	per-call	precomputed	hash call eliminated
`precompute` (scalar_mul_generator)	2 heap allocs	0	zero-alloc hot path

Zero-Knowledge Proof Layer (new)

Knowledge proofs — non-interactive Schnorr PoK, Fiat-Shamir with tagged SHA-256, no trusted setup.
DLEQ proofs — discrete log equality, batch-verify capable.
Bulletproof range proofs — 64-bit range, MSM-optimized verifier (Pippenger + Montgomery batch inversion).
GPU ZK: CUDA CT kernels (ct_zk.cuh), OpenCL (secp256k1_zk.cl), Metal (kernels 19–22), all batch-capable.
5 new GPU C ABI functions: ufsecp_gpu_zk_knowledge_verify_batch, ufsecp_gpu_zk_dleq_verify_batch, ufsecp_gpu_bulletproof_verify_batch, ufsecp_gpu_bip324_aead_encrypt_batch, ufsecp_gpu_bip324_aead_decrypt_batch.
24 tests in test_zk.cpp; 8.5 benchmarks in bench_unified.

Full GPU Parity (zero Unsupported stubs)

Bulletproof on OpenCL + Metal: removed #if 0 guard in secp256k1_zk.cl; fixed address-space qualifiers; wired bulletproof_verify_batch on both backends. CUDA ↔ OpenCL ↔ Metal parity complete.
4 new OpenCL kernels wired: zk_knowledge_verify_batch, zk_dleq_verify_batch, bip324_aead_encrypt_batch, bip324_aead_decrypt_batch.
4 Metal kernels connected: same 4 operations — kernels existed but dispatch was unwired.
Metal ZK fix: zk_knowledge_verify_batch was treating pubkey buffer as a scalar; corrected to lift_x to recover full point.
CUDA 13 compatibility: replaced deprecated cudaDeviceProp::clockRate / ::memoryClockRate with cudaDeviceGetAttribute. Backward-compatible with CUDA 12. (RTX 5080 / CUDA 13 reported by @craigraw)

Wallet API & Address Formats (new)

Unified Wallet API (wallet.hpp/wallet.cpp) — chain-agnostic key management, address generation, message signing, pubkey recovery — Bitcoin, Ethereum, Tron, and all 28 coins from a single wallet:: namespace.
BIP-39 Mnemonic (bip39.hpp/bip39.cpp) — entropy→mnemonic (12–24 words), validation, PBKDF2-HMAC-SHA512 seed derivation. 57 tests.
Bitcoin message signing (message_signing.hpp) — BIP-137/Electrum compatible: sign, verify, recover, Base64.
P2SH-P2WPKH (nested SegWit, BIP-49) — 3... addresses.
P2SH and P2WSH primitives.
CashAddr (BIP-0185) — bitcoincash:q... addresses.
Tron (TRX) coin — coin_type=195, 0x41 prefix + Keccak-256 + Base58Check. Now 28 coins total.

Bindings

Stable validation closure across 11 language bindings: C#, Java, Swift, Python, Go, Rust, Node.js, PHP, Ruby, Dart, React Native. Fixed wrapper/API drift, zero-length FFI buffer edge cases, Dart NativeFinalizer, local Dart smoke-runner.

Audit Coverage Summary

Surface	Count
C ABI functions (`ufsecp_*`)	155
GPU C ABI functions (`ufsecp_gpu_*`)	23
Unified audit runner modules	70
Python CTest audit targets	9
ClusterFuzz targets	5
Exploit PoC test files	13
Active GPU Unsupported stubs	0

CI/CD

All jobs green on: Linux (GCC + Clang), macOS (arm64 + amd64), Windows, Android (ARM64), RISC-V, ARM64 cross, ROCm, CUDA.
Fixed: macOS externally-managed-environment, Windows Unicode cp1252, Python-order CMake embed, ASan/MSan/TSan py_* symbol issue, SonarCloud coincurve missing.
10 CodeQL code-scanning alerts resolved.

Full diff: v3.50.0...v3.60.0

Don’t Trust, Verify — Continuously: UltrafastSecp256k1 Meets Frigate

Vano Chkheidze — Wed, 01 Apr 2026 14:07:25 +0000

Introduction

Most cryptographic libraries rely on a simple model:

write code
get audited once
ship a PDF

But modern systems don’t stand still.

They evolve daily.

So I asked a different question:

What if audit was not a document, but a continuous process?

The Idea

UltrafastSecp256k1 was designed around two principles:

High-performance cryptographic execution (CPU + GPU)
Continuous, self-evolving audit system

Instead of relying on one-time audits, the system:

runs ~1M+ checks per audit
performs nightly differential validation
converts every discovered exploit into a permanent test
uses AI-assisted adversarial analysis
enforces correctness through CI

Security is not declared — it is continuously verified.

Real-World Adoption: Frigate

Recently, Sparrow Wallet’s Frigate integrated UltrafastSecp256k1 as its core compute layer.

Frigate is an experimental Silent Payments (BIP352) server that performs high-throughput blockchain scanning using DuckDB.

Instead of treating cryptography as a separate layer, Frigate embeds it directly into the database via a custom extension:

ufsecp.duckdb_extension
ufsecp_scan(...)

This extension is powered by UltrafastSecp256k1.

Performance in Practice

Independent benchmarks from Frigate show:

~40 million operations/sec on 2 RTX 5090

This is not a synthetic benchmark —

it’s a real-world scanning pipeline.

Source:
https://github.com/sparrowwallet/frigate/blob/master/README.md

Why This Matters

This is not about “fastest library” claims.

This is about:

independent integration
real-world validation
reproducible performance
continuous verification

No contracts.

No paid audits.

No marketing.

Just:

clone → build → run → verify

Rethinking Audit

Traditional model:

audit = event
output = PDF
trust = assumption

This model:

audit = process
output = evidence
trust = reproducibility

Final Thought

If a system cannot be verified continuously,

it is only temporarily trusted.

UltrafastSecp256k1 is an attempt to change that.

Why UltrafastSecp256k1?

Vano Chkheidze — Fri, 27 Mar 2026 16:18:26 +0000

https://github.com/shrec/UltrafastSecp256k1
A detailed look at what sets this library apart — not just in speed, but in engineering discipline, audit culture, and verified correctness.

1. Audit-First Engineering Culture

Most high-performance cryptographic libraries ship fast code and trust that it is correct.
UltrafastSecp256k1 ships fast code and then systematically tries to break it.

The internal self-audit system is not a layer of unit tests bolted on after the fact —
it was designed in parallel with the cryptographic implementation, as a first-class engineering artifact.

The underlying philosophy is Bitcoin-style: don't trust, verify. The project does
not center its trust model on a one-time PDF artifact written by someone else at a
fixed moment in the past. Instead, it tries to make assurance continuously rerunnable:
every important claim should be tied to code, tests, CI artifacts, benchmark logs, or
traceable documentation that another engineer can reproduce on demand.

This is why the audit framework keeps expanding with the codebase. The repository ships
not only tests, but also reviewer-facing infrastructure: structured audit artifacts,
threat-model docs, adversarial exploit tests, differential checks, and a repo-local
SQLite source graph that makes the codebase searchable as an audit surface rather than
just a pile of files.

These top-level differentiators are claim-keyed in the ledger: exploit-audit surface A-005, graph-assisted review A-006, self-audit transparency A-007, and benchmark reproducibility A-004 in docs/ASSURANCE_LEDGER.md.

What the Audit Infrastructure Covers

Area	What is Tested	Assertion Count
Field arithmetic (𝔽ₚ)	Commutativity, associativity, distributivity, canonical form, carry propagation, batch inverse, sqrt	264,622
Scalar arithmetic (ℤ_n)	Reduction mod n, overflow, GLV decomposition, negation, edge cases (0, 1, n−1)	93,215
Point operations	Infinity handling, Jacobian↔Affine round-trip, scalar multiplication, 100K stress	116,124
Constant-time layer	No secret-dependent branches, no secret-dependent memory access, formal CT verification	120,652
Exploit PoC tests	86 dedicated adversarial PoC tests across 14 coverage areas (`audit/test_exploit_*.cpp`)	86 test files, 0 failures
Fuzz / adversarial	libFuzzer harnesses + 530K deterministic corpus adversarial checks	~530,000+
Wycheproof vectors	Google's cryptographic test vectors for ECDSA and ECDH	Hundreds of vectors
Fiat-Crypto linkage	Cross-validates field arithmetic against formally-verified Fiat-Crypto reference	Full suite
FROST / MuSig2 KAT	Protocol-level Known Answer Tests per BIP-327 and FROST spec	Full suite
Fault injection	Tests behaviour under simulated hardware faults (bit flips, counter skips)	Full suite
ABI gate	FFI round-trip stability, C ABI regression detection	Full suite
Performance regression	Automated micro-benchmark gate — fails CI if throughput regresses	Every push
Nightly differential	Random round-trip differential tests against reference implementations	~1,300,000+/night
Total (audit runner)	unified_audit_runner across 55 modules plus standalone audit surfaces	~1,000,000+
Total (exploit PoC tests)	86 exploit-style PoC tests across 14 coverage areas, all in `audit/test_exploit_*.cpp`	86 tests, 0 failures

All 55 audit modules across all tested platforms return AUDIT-READY. Zero failures.
All 86 exploit PoC tests pass. Zero failures across all 14 coverage areas.

Self-Audit Documents

Document	Purpose
AUDIT_GUIDE.md	Navigation guide for external auditors — build steps, source layout, test commands
AUDIT_REPORT.md	Historical formal audit report (v3.9.0): 641,194 checks, 0 failures
AUDIT_COVERAGE.md	Current coverage matrix by module and section
THREAT_MODEL.md	Layer-by-layer risk analysis — what is in scope and out of scope
SECURITY.md	Vulnerability disclosure policy and contact
docs/CT_VERIFICATION.md	Constant-time formal verification evidence and methodology
audit/AUDIT_TEST_PLAN.md	Detailed test plan covering all 8 audit sections
audit/platform-reports/	Per-platform audit run results and logs
tools/source_graph_kit/source_graph.py	SQLite-backed repository graph for fast impact tracing, audit scoping, and reproducible review
docs/ASSURANCE_LEDGER.md	Canonical claim-to-evidence ledger for public trust statements
docs/AI_AUDIT_PROTOCOL.md	Formal protocol for AI-assisted auditor/attacker review loops
docs/FORTRESS_ROADMAP.md	Gap-closing roadmap for fortress-grade self-audit

2. CI/CD Pipeline — 24 Automated Workflows

The continuous integration pipeline is not a basic build-and-test gate.
It is a multi-layer quality enforcement system with 24 GitHub Actions workflows
covering security, correctness, performance, supply chain, and formal analysis.

It is also only one part of the assurance model. The repository is routinely reviewed
through external-style passes as if by auditors, attackers, and bug bounty hunters,
including LLM-assisted review loops that help surface edge cases, exploit ideas, and
documentation gaps. Those passes are not treated as magic or as a replacement for
deterministic tests; they are useful because they feed new cases back into the same
reproducible audit framework.

Workflow Index (selected)

Workflow	What It Does	Trigger
`ci.yml`	Core build + full test suite across 17 configurations × 7 architectures × 5 OSes	Every push / PR
`preflight.yml`	Fast pre-merge smoke check — blocks merge on basic failures	Every PR
`nightly.yml`	Nightly stress: 1.3M+ differential checks, extended fuzz, full sanitizer run	Nightly
`security-audit.yml`	Runs the full `unified_audit_runner` (55 modules, ~1M assertions) plus sanitizer and warning gates	Every push
`audit-report.yml`	Generates and archives structured audit report artifacts	On release / manual
`ct-arm64.yml`	Constant-time verification on native ARM64 hardware	Every push
`ct-verif.yml`	Formal constant-time verification pass	Every push
`valgrind-ct.yml`	Valgrind memcheck + CT analysis on Linux x64	Every push
`bench-regression.yml`	Performance regression gate — CI fails if throughput drops	Every push
`benchmark.yml`	Full benchmark suite — results published to live dashboard	On push to dev/main
`codeql.yml`	GitHub CodeQL static analysis (C++)	Every push
`clang-tidy.yml`	Clang-Tidy lint pass with project-specific rules	Every push
`cppcheck.yml`	CPPCheck static analysis	Every push
`sonarcloud.yml`	SonarCloud code quality and security rating	Every push
`mutation.yml`	Mutation testing — verifies test suite kills injected faults	Scheduled
`cflite.yml`	ClusterFuzz-Lite continuous fuzzing integration	Every push
`bindings.yml`	Tests all 12 language bindings (Python, Rust, Node, Go, C#, Java, Swift, ...)	Every push
`dependency-review.yml`	Scans dependency changes for known vulnerabilities	Every PR
`scorecard.yml`	OpenSSF Scorecard supply-chain security scan	Weekly
`valgrind-ct.yml`	Valgrind constant-time path analysis	Every push
`docs.yml`	Docs build and deployment validation	Every push
`packaging.yml`	NuGet, vcpkg, Conan, Swift Package, CocoaPods packaging validation	On release
`release.yml`	Full release pipeline: build, sign, attest, publish	On tag

Build Matrix Scale

Dimension	Coverage
Configurations	17 (Release, Debug, ASan+UBSan, TSan, Valgrind, coverage, LTO, PGO, ...)
Architectures	7 (x86-64, ARM64, RISC-V, WASM, Android ARM64, iOS ARM64, ROCm)
Operating systems	5 (Linux, Windows, macOS, Android, iOS)
Compilers	GCC 13, Clang 17, Clang 21, MSVC 2022, AppleClang, NDK Clang

3. Static Analysis & Sanitizer Stack

Every commit is checked by multiple independent static and dynamic analysis layers:

Tool	What It Catches
CodeQL	Semantic security vulnerabilities, data-flow bugs
SonarCloud	Code quality, security hotspots, cognitive complexity
Clang-Tidy	Style violations, anti-patterns, performance issues
CPPCheck	Memory errors, null dereferences, buffer overflows
ASan + UBSan	Memory errors, undefined behaviour in CT paths
TSan	Data races and threading issues
Valgrind memcheck	Heap errors, uninitialized reads
Valgrind CT	Constant-time path analysis via shadow value propagation
libFuzzer	Corpus-driven bug finding in field, scalar, and point arithmetic
ClusterFuzz-Lite	Continuous fuzzing integrated into CI

The -Werror flag is enforced — warnings are build failures.

4. Supply Chain Security

Cryptographic libraries are high-value supply chain targets.
UltrafastSecp256k1 applies the OpenSSF supply-chain hardening model:

OpenSSF Scorecard — automated weekly supply-chain health score
OpenSSF Best Practices badge — verified against the CII/OpenSSF criteria
Pinned GitHub Actions — all third-party actions pinned to commit SHA, not floating tags
Dependency Review — automated PR-level scan for vulnerable dependencies
Harden-runner — runtime monitoring of CI runner behaviour
Reproducible builds — Dockerfile.reproducible for bit-for-bit build verification
SBOM — software bill of materials generated on release
Artifact attestation — GitHub Artifact Attestation on release builds

5. Formal Verification Layers

Layer	Method	Status
Field arithmetic correctness	Fiat-Crypto cross-validation (differential testing against formally-verified reference)	Active
Constant-time (field/scalar)	`ct-verif` tool + ARM64 hardware CI	Active
Constant-time (point ops)	Dedicated `ct-arm64.yml` pipeline + Valgrind shadow analysis	Active
Wycheproof ECDSA/ECDH	Google's adversarial test vector suite	Active
Fault injection	Simulated hardware faults in signing/verification paths	Active
Cross-libsecp256k1	Differential round-trip against Bitcoin Core's libsecp256k1	Active

6. Performance — Verified, Not Just Claimed

Every benchmark number in this project is:

Produced by a pinned compiler version with exact flags documented
Reproducible via a published command in docs/BENCHMARKS.md
Gated by an automated performance regression check in CI (bench-regression.yml)
Published to a live dashboard on pushes to dev/main

Sample verified numbers (RTX 5060 Ti, CUDA 12):

Operation	Throughput
ECDSA sign	4.88 M/s
ECDSA verify	4.05 M/s
Schnorr sign (BIP-340)	3.66 M/s
Schnorr verify (BIP-340)	5.38 M/s
FROST partial verify	1.34 M/s

Sample verified numbers (x86-64 rerun, i5-14400F, Clang 19):

Operation	Latency
Generator multiplication (kG)	5.9 µs
Scalar multiplication (kP)	16.0 µs
ECDSA sign	7.8 µs
ECDSA verify	20.2 µs

7. What "Not Paid-Externally Audited" Actually Means Here

UltrafastSecp256k1 has not yet undergone a paid third-party professional audit.
That is a factual status note, not the center of the project's security philosophy.
The project is open to external audit and continuously prepares evidence so outside reviewers can audit it at any time.
At the same time, it does not wait for a third party to begin strengthening correctness and security, and it does not outsource trust to a single PDF milestone.

However, "not externally audited" does not mean "unverified." The internal quality infrastructure described in this document represents a systematic, multi-layer correctness assurance program that most open-source cryptographic libraries do not have:

Over 1,000,000 internal audit assertions executed on every build
24 CI/CD workflows enforcing correctness, security, and performance on every push/PR plus scheduled assurance runs
Formal constant-time verification on two independent platforms
Supply-chain hardening at the OpenSSF standard
Nightly differential testing at 1.3M+ additional random checks per night

The honest summary:

This library does not rely on a paid-audit badge as its primary trust story.
It does rely on open self-audit, reproducible evidence, graph-assisted review, and reviewer-friendly verification so anyone can inspect and challenge the implementation.
External audit is welcomed, but assurance work already happens continuously through internal audit on every build, every push/PR gate, and every nightly extended run.

Summary Table

Quality Dimension	Evidence
Mathematical correctness	473,961 audit assertions (field + scalar + point)
Constant-time guarantees	ct-verif, ARM64 CI, Valgrind CT, 120K CT assertions
Adversarial resilience	Wycheproof, fault injection, 530K+ fuzz corpus
Protocol correctness	FROST/MuSig2 KAT, cross-libsecp256k1 differential
Memory safety	ASan, TSan, Valgrind — every commit
Static analysis	CodeQL, SonarCloud, Clang-Tidy, CPPCheck
Supply chain	OpenSSF Scorecard, pinned actions, SBOM, artifact attestation
Performance regression	Automated gate on every push
Build reproducibility	Dockerfile.reproducible + pinned toolchains
Self-audit documentation	AUDIT_GUIDE, AUDIT_REPORT, AUDIT_COVERAGE, THREAT_MODEL

https://github.com/shrec/UltrafastSecp256k1

UltrafastSecp256k1 v3.3.0

Vano Chkheidze — Fri, 20 Mar 2026 00:54:42 +0000

Highlights
Batch operations 17-67x faster — all-affine fast path with Pippenger touched-bucket + window tuning (#169)
OpenCL generator mul ~10% faster — precomputed affine table with mixed J+A adds eliminates per-thread table construction
CUDA precomputed tweak tables — BENCH_CLOCK_WARMUP and simplified warmup path
Schnorr batch verify optimized — cached x-only pubkeys, reused scratch buffers, retuned crossover, fast path through N=64
463+ code-scanning alerts resolved — braces, const, widening, dead-stores, init-vars, argumentSize
Complete audit infrastructure — P0+P1+P2 audit TODO completed (#148)
Performance
Batch ops 17-67x faster via all-affine fast path; Pippenger touched-bucket + window tuning (#169)
OpenCL generator mul — hardcode precomputed affine table for scalar_mul_generator + force __NV_CL_C_VERSION
CUDA BIP352 — precomputed tweak tables, BENCH_CLOCK_WARMUP, simplified warmup
CUDA BIP352 benchmark optimization and enriched project graph
OpenCL GLV generator phi table optimization
OpenCL generator nibble lookup optimization
Silent payment scan invariants optimization
Coin HD fixed-path derivation optimization
Schnorr batch verify — cache repeated x-only pubkeys in large batches, reuse scratch buffers, retune crossover, reduce setup passes, keep fast path through N=64, tune cutoff for N=128, trim seed serialization overhead, cache x-only lifts in parse path, reuse SHA256 base for batch weights
Field batch inversion — trim scratch overhead
OpenCL batch-inversion kernels added
Added
OpenCL LUT primitives for generator multiplication (#172)
Metal scalar_mul_generator_lut for Metal shaders (#171)
Metal wNAF w=4 for Metal shaders (#158)
Metal scalar_mul_glv for batched scalar multiplications (#155)
Cached schnorr batch path and preflight coverage fixes
Benchmark cached schnorr batch verification
Larger batch verify benchmark sizes
Source graph pipeline command and tooling improvements
Security & Hardening
Wallet seed-to-address cleanup hardened
ABI secret cleanup paths hardened
ECIES zero-ephemeral cleanup hardened
N-03 CT path for message signing (constant-time)
Solinas reduction — replaced broken Barrett reduction with correct implementation (#141)
Fixed
ARM64 SHA-256 — vsha256h2q_u32 bug using modified abcd register
MSVC C2026 string literal limit workaround (#173)
precompute_point_multiples stack allocation fix; ASan timeout 300→600s
Metal generator_mul_batch — use scalar_mul_glv correctly (#163)
CI bip39 audit regression (#161)
Clang-tidy code scanning warnings (#170)
463+ code-scanning alerts resolved across 4 PRs (#154, #156, #157, #162)
CI auto-detect compilers + best-effort source graph refresh
SonarCloud — exclude hash_accel.cpp, address.cpp from CPD; exclude cuda/** and platform-specific field_asm/field_simd from coverage (#139, #140)
CI SECP256K1_MARCH respected in cpu/CMakeLists.txt; benchmark regression downgraded to x86-64-v2 (#138)
SonarCloud fork PRs skipped + continue-on-error for Quality Gate (#159)
Audit
Complete audit infrastructure — P0+P1+P2 audit TODO finished (#148)
Test coverage for CT PrivateKey overloads and FE52 conditional_negate (#143)

[Boost]

Vano Chkheidze — Mon, 09 Mar 2026 04:34:03 +0000

Vano Chkheidze

Mar 8

Building a Faster secp256k1 Library – UltrafastSecp256k1 v3.21

#blockchain #opensource #performance #security

Comments

1 min read

Building a Faster secp256k1 Library – UltrafastSecp256k1 v3.21

Vano Chkheidze — Sun, 08 Mar 2026 18:23:39 +0000

I’ve been working on UltrafastSecp256k1, a high‑performance secp256k1 cryptography library focused on throughput and auditability.

The new v3.20 release consolidates more than 120 commits and introduces major improvements in constant‑time security, performance, and testing infrastructure.

Key highlights:

• Constant‑time scalar inversion rewritten using Bernstein‑Yang SafeGCD
• 6.4× improvement in scalar inverse
• ~43% faster constant‑time ECDSA signing
• strict BIP‑340 parsing and safer APIs
• expanded audit infrastructure
• reproducible Docker CI pipeline

Benchmarks across several architectures show strong performance improvements compared to libsecp256k1 in signing workloads and generator multiplication.

The project now includes:

• cross‑platform benchmark campaigns
• formal constant‑time verification tools
• Wycheproof and Fiat‑Crypto verification
• full local Docker CI

GitHub:
https://github.com/shrec/UltrafastSecp256k1

🚀 Breaking the Speed of Light: Secp256k1 Optimization in 12 Days

Vano Chkheidze — Thu, 26 Feb 2026 18:36:18 +0000

In the world of blockchain infrastructure, speed is not just a luxury—it’s a security requirement. After 12 days of intensive development, the UltrafastSecp256k1 v3.14.0 has reached a milestone that redefines performance expectations for cryptographic libraries.

📊 The Numbers (i7-11700 @ Single Core)
These benchmarks were taken on a standard development machine under typical load. In a dedicated, headless Linux environment, we expect even higher throughput due to reduced OS jitter.

🛠️ Why This Matters for Node Operators
The primary bottleneck for any new node is the Initial Block Download (IBD). Validating billions of historical signatures is a massive task.

Massive Scalability: Validating ~1.35 billion signatures takes just 1.5 hours on 8 cores.

Peak Efficiency: At ~32,000 ECDSA tx/sec per core, this library is ready for the next generation of high-throughput networks.

Hardware Optimized: The field multiplication (field_mul) completes in just 56 cycles, showing deep low-level optimization.

🛡️ Built-in Security & Auditability
Speed means nothing without correctness. This project maintains a "Zero-Bug" status through a centralized, AI-driven testing core.

641,194 Audit Checks: Every mathematical edge case is covered.

Security Suite: Integrated with CodeQL, Clang-Tidy, and SonarCloud—all currently in PASSING status.

https://github.com/shrec/UltrafastSecp256k1

UltrafastSecp256k1 v3.14.0

Vano Chkheidze — Wed, 25 Feb 2026 10:44:23 +0000

Swift — 20 new functions: DER encode/decode, recovery sign/recover, ECDH, tagged hash, BIP-32/39, taproot, WIF, address encoding

React Native — 15 new functions: DER, recovery, ECDH, Schnorr, BIP-32/39, taproot, WIF, address, tagged hash

Python — 3 new functions: ctx_clone(), last_error(), last_error_msg()

Rust — 2 new functions: last_error(), last_error_msg()

Dart — 1 new function: ctx_clone()

Go, Node.js, C#, Ruby, PHP — already complete (verified, no changes needed)

9 new binding READMEs — c_api, dart, go, java, php, python, ruby, rust, swift

Selftest report API — SelftestReport and SelftestCase structs in selftest.hpp; tally() refactored for programmatic reporting

Fixed — Documentation & Packaging
Package naming corrected across all documentation — libsecp256k1-fast* → libufsecp* (apt, rpm, arch); CMake target secp256k1-fast-cpu → secp256k1::fast; linker flag -lsecp256k1-fast-cpu → -lfastsecp256k1; pkg-config Libs -lsecp256k1-fast-cpu → -lfastsecp256k1

RPM spec renamed — libsecp256k1-fast.spec → libufsecp.spec

Debian control — source libufsecp, binary packages libufsecp3/libufsecp-dev

Arch PKGBUILD — pkgname=libufsecp, provides=('libufsecp')

3 existing binding READMEs fixed — Node.js, C#, React Native: removed inaccurate CT-layer claims (C API uses fast:: path only)

README dead link — INDUSTRIAL_ROADMAP_WORKING.md → ROADMAP.md

Fixed — CI / Build
-Werror=unused-function — added [[maybe_unused]] to get_platform_string() in selftest.cpp

Scorecard CI — pinned ubuntu:24.04 by SHA digest in Dockerfile.local-ci
https://github.com/shrec/UltrafastSecp256k1

UltrafastSecp256k1 v3.14.0

Vano Chkheidze — Tue, 24 Feb 2026 21:56:13 +0000

Added — Language Bindings (12 languages, 41-function C API parity)
Java — 22 new JNI functions + 3 helper classes (RecoverableSignature, WifDecoded, TaprootOutputKeyResult): full coverage of ECDSA sign/verify, DER encoding, recovery, ECDH, Schnorr, BIP-32, BIP-39, taproot, WIF, address encoding, tagged hash
Swift — 20 new functions: DER encode/decode, recovery sign/recover, ECDH, tagged hash, BIP-32/39, taproot, WIF, address encoding
React Native — 15 new functions: DER, recovery, ECDH, Schnorr, BIP-32/39, taproot, WIF, address, tagged hash
Python — 3 new functions: ctx_clone(), last_error(), last_error_msg()
Rust — 2 new functions: last_error(), last_error_msg()
Dart — 1 new function: ctx_clone()
Go, Node.js, C#, Ruby, PHP — already complete (verified, no changes needed)
9 new binding READMEs — c_api, dart, go, java, php, python, ruby, rust, swift
Selftest report API — SelftestReport and SelftestCase structs in selftest.hpp; tally() refactored for programmatic reporting
Fixed — Documentation & Packaging
Package naming corrected across all documentation — libsecp256k1-fast* → libufsecp* (apt, rpm, arch); CMake target secp256k1-fast-cpu → secp256k1::fast; linker flag -lsecp256k1-fast-cpu → -lfastsecp256k1; pkg-config Libs -lsecp256k1-fast-cpu → -lfastsecp256k1
RPM spec renamed — libsecp256k1-fast.spec → libufsecp.spec
Debian control — source libufsecp, binary packages libufsecp3/libufsecp-dev
Arch PKGBUILD — pkgname=libufsecp, provides=('libufsecp')
3 existing binding READMEs fixed — Node.js, C#, React Native: removed inaccurate CT-layer claims (C API uses fast:: path only)
README dead link — INDUSTRIAL_ROADMAP_WORKING.md → ROADMAP.md
Fixed — CI / Build
-Werror=unused-function — added [[maybe_unused]] to get_platform_string() in selftest.cpp
Scorecard CI — pinned ubuntu:24.04 by SHA digest in Dockerfile.local-ci