Building financial infrastructure for the real world means making explicit what most people leave implicit. So let me talk about our curve choices – because most blockchain projects don’t.
Chia started with BLS12-381 and added secp256k1 and secp256r1 in 2023 with our version 2.0 release. Here’s why we made the decisions we did.
Why Start With BLS?
The reason is architectural, not philosophical.
BLS signatures are aggregatable – thousands of individual signatures from thousands of coin spends collapse into a single validation operation. For something like Permuto’s Secure the Bag dividend payments, where we’re sending distributions to millions of holders for $20 in fees, that aggregation is what makes the economics work. The same properties extend to threshold signatures, BLS-based VDFs, and proof systems we’ve implemented. secp256k1 is a great curve for “store value, sign transactions.” BLS12-381 is the right curve for “run financial infrastructure at scale.”
So Why Did We Add the Other Two?
secp256k1 was the easy call – it’s what Bitcoin and Ethereum use, the constants are simple and transparent, and every crypto developer already has the libraries. No deliberation required.
secp256r1 (P-256) took a little more thought, but we found the ubiquity hard to argue with: it’s in every modern Apple device, many Android devices, most of the internet’s TLS stack, and the majority of HSMs. Adding it means institutions can work with Chia using tooling they already have. It’s the same logic as adding Transfer Agent rails for Permuto – the path to One Market runs through the existing financial system, not around it.
The question we had to answer honestly: are we comfortable with P-256’s security properties?
A Legitimate Concern
P-256’s parameter generation has never been fully explained. NIST produced the curve from a seed, and nobody has ever documented where that seed came from. Unlike secp256k1, whose constants are structurally obvious, P-256’s look like the output of a hash of something unknown. That matters because curves can be constructed to harbor trapdoors invisible to standard security tests but exploitable by whoever chose the parameters. NSA was involved in the P-256 standardization and Dual_EC_DRBG, a different and later NIST standard, which was proven to contain exactly this kind of NSA-inserted backdoor, confirmed by the Snowden documents.
The concern is real. But here’s my personal speculation on what that seed actually was: the curve generation was done by Certicom, reportedly by Jerry Solinas. I’d bet the “secret” isn’t an NSA trapdoor at all; it’s more likely that Solinas hashed something personally embarrassing, his kids’ names, his wife’s birthday, or maybe something a little ribald that he didn’t want in a federal standards document. A mathematician’s way of signing his work with no intent to ever explain it. That would account for everything: the opacity, the lack of documentation, nothing ever leaking. Not a conspiracy, just an awkward personal detail sitting quietly inside a NIST standard.
Why We Got Comfortable Anyway
It helps to remember what era P-256 was born in. The NSA of the mid-1990s was, by the historical record, genuinely trying to make US cryptography strong and there are two separate data points for this.
The first is the original DES hardening. When NSA modified the S-boxes in the 1970s, the cryptographic community assumed they’d been weakened. They hadn’t, instead NSA had secretly hardened them against differential cryptanalysis, a technique they knew about, but academia wouldn’t independently discover until 1990. That disclosure, when it came, was a genuine surprise: the agency everyone suspected of sabotage had actually been ahead of the field on attack techniques and quietly used that knowledge to strengthen the standard.
I can speak directly to the second hardening. Around 1996, NSA approached PGP, Inc. and disclosed additional hardening guidance around Triple-DES. I was in the SCIF for that meeting. Nobody in that room expected what they told us then, either. This wasn’t an agency trying to weaken commercial cryptography. It was an agency genuinely invested in ensuring encryption that American companies and citizens relied on was actually secure. The ‘predatory’ era of Dual_EC_DRBG and the Snowden leaks didn’t happen overnight; it was a post-9/11 pivot, triggered when a new set of mission priorities took the lead. P-256 was standardized in 1999, right at the tail end of the constructive era.
The significance of that guidance became clearer over the following years. Two-key Triple DES, the variant where the first and third keys are identical, turned out to have a meaningful known-plaintext vulnerability, the van Oorschot-Wiener attack first published at Eurocrypt 1990 and progressively refined through the late 1990s and 2000s. NIST eventually disallowed two-key Triple DES entirely in 2015. PGP, steered toward three-key Triple DES with three independent keys, was not vulnerable to this attack. What NSA told us in that SCIF put PGP on the right side of a distinction that took the broader standards community another two decades to fully act on.
Beyond the historical context, the math argues against a live exploit. A P-256 trapdoor would require a working ECDLP solver for that specific curve, the most valuable cryptographic secret in history. It would have had to stay completely secret for 25+ years across thousands of NSA employees and contractors, survive the Snowden disclosures, and escape notice from the cryptographic establishments of every adversarial nation-state, each with strong incentives to find exactly this. Classified programs leak. This one hasn’t. And NSA’s own behavior, pushing post-quantum standards, preferring P-384 for their own high-security uses, isn’t consistent with an agency sitting on a quiet shortcut.
What Needs to Change
secp256k1 and secp256r1 are bridges, not destinations. When BLS12-381 is as ubiquitous in HSMs, secure enclaves, and standard cryptographic libraries as P-256 is today, the pragmatic case for these others evaporates. That’s already moving, the Ethereum validator ecosystem has done more to mainstream BLS tooling than almost anything else in the last few years except Chia.
Until then: we’re comfortable with the bridges, clear-eyed about why we built them, and pointed firmly at BLS as the long-term answer. You make the right choice first, then build the bridges that get people there.
Further Reading
Chia
- CHIP-0011: New secp256k1 and secp256r1 CLVM operators — the actual specification for how we added the two curves
- The Challenges of Trading Securities on Most Blockchains — why Chia’s architecture matters for compliant financial infrastructure
- The Blockchain Trilemma is Real in the Real World — on decentralization, security, and why TPS claims are mostly snake oil
- One Market — the vision this all points toward
- The Permuto Trusts Started as a Chia Blockchain-Only Offering — Secure the Bag and why BLS aggregation matters in practice
Cryptography
- SafeCurves — Bernstein and Lange’s analysis of curve parameter transparency; the case for preferring Curve25519 and BLS over NIST curves for new systems
- Dual_EC_DRBG (Wikipedia) — the confirmed NSA backdoor in a NIST standard; the mechanism that makes P-256’s opacity worth discussing
- BLS Signatures (IETF RFC 9380) — the formal specification for BLS signature aggregation
- How were the NIST ECDSA curve parameters generated? — the best public investigation of where the P-256 seed came from, including Solinas’s own emails to Bernstein confirming he hashed “a humorous message” and forgot what it was
- Security Cryptography Whatever: “The NIST Curves” — podcast episode titled after the running joke that Jerry just wanted a raise; good discussion of the seed origin story and what serious cryptographers actually think about the backdoor question
- DES S-boxes and differential cryptanalysis (Wikipedia) — the historical record on NSA’s S-box modifications: suspected backdoor, turned out to be the opposite
- van Oorschot & Wiener: A Known-Plaintext Attack on Two-Key Triple Encryption (1990) — the attack that made two-key Triple DES problematic; three-key Triple DES, which PGP adopted, was not vulnerable