Forem: Vano Chkheidze

# 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

Why I Built a Zero-Dependency secp256k1 Library From Scratch

Vano Chkheidze — Sun, 15 Feb 2026 11:17:45 +0000

The Problem
If you've ever tried to do secp256k1 cryptography across multiple platforms — from a server with AVX-512 to an ESP32 microcontroller to a WebAssembly module — you know the pain. Different libraries, different APIs, different dependency trees, different bugs.

I wanted one library that works everywhere, depends on nothing, and covers everything the modern Bitcoin/EVM ecosystem needs.

What UltrafastSecp256k1 Covers
Core: Field/Scalar/Point arithmetic, GLV endomorphism, precomputation, RFC 6979, low-S normalization.

Signatures: ECDSA (sign, verify, recover, batch), Schnorr BIP-340 (sign, verify, batch).

Advanced Protocols: MuSig2 (2-round aggregation), FROST (t-of-n threshold), Adaptor signatures, Pedersen commitments, Multi-scalar multiplication (Strauss/Shamir), ECDH.

Bitcoin: Taproot (BIP-341/342), BIP-32 HD keys, BIP-44 coin derivation, BIP-352 Silent Payments, P2PKH/P2WPKH/P2TR/Base58/Bech32.

Multi-Chain: 27+ coins including ETH (EIP-55 checksums), LTC, DOGE, ZEC, DASH — with a built-in Keccak-256.

Zero dependencies means: SHA-256, SHA-512, HMAC, Keccak-256, RIPEMD-160, Base58Check, Bech32/Bech32m — all implemented from scratch in the library.

Performance Design
Assembly backends for x64 (BMI2/ADX → 3-5× speedup), ARM64 (~5×), and RISC-V. SIMD with AVX2/AVX-512. GPU with CUDA (4.63M kG/s), OpenCL (3.39M kG/s), and ROCm/HIP.

Constant-time operations live in a separate secp256k1::ct namespace — no runtime flag switching, explicit API separation.

9 Platforms, One Codebase
Platform Notes
x86-64 BMI2/ADX assembly, AVX2/AVX-512
ARM64 MUL/UMULH inline asm
RISC-V RV64GC native assembly
ESP32 Xtensa LX7/LX6
STM32 ARM Cortex-M3
WebAssembly Emscripten, ES6 + TypeScript
iOS SPM, CocoaPods, XCFramework
Android NDK r27, Clang 18
GPU CUDA, OpenCL, ROCm/HIP
Try It
MIT licensed. 200+ tests. PRs welcome.

→ github.com/shrec/UltrafastSecp256k1