Welcome back! Seriously, welcome back, because we’re diving into the world of Zero-Knowledge Proofs (ZKP) once again. But this time, we’re looking at it from a fresh angle: the Stellar blockchain perspective.

I must admit, I was surprised by how beautifully this blockchain already supports ZKP - and their plans for the future are even more ambitious. So, if the clickbait title piqued your curiosity about what connects the God of the Sea (Poseidon) to medical imaging (X-ray), stay with me until the end. Grab a coffee, and let's explore elliptic curves, hash functions, and the magic of host functions.

ZKP and Stellar: A Match Made in Heaven

I’ve already written a few articles about ZKP (like ZKP Overview Part 2 or ZKP Overview Part 3), so before we dive in, please check those out to make sure you’re familiar with the basics. Or, you can ask your Agentic AI (oh look, I wrote about that too!) to explain keywords like circuits, Circom language, and proof generation/verification.

Let’s learn more about Stellar. They introduce themselves as  “an open-source blockchain used for a variety of payment and remittance applications.” It’s a wide net, but the most interesting Stellar feature for us right now is how it supports ZKP, and how we can write smart contracts that utilize this facet. The Stellar network has a smart contract platform called Soroban. Smart contracts here are written in Rust and compiled to WebAssembly (Wasm) for deployment (source). That’s enough for us to know at the moment, but if you’re interested in getting your hands dirty with Soroban, check out the Getting started guide.

Not so long ago, in 2024, Stellar took a quantum leap toward adopting advanced ZKP systems by adding support for the BLS12-381 elliptic curve. But what exactly do I mean by “adding support”? To understand this, let’s take a quick detour into the world of host functions.

Host Functions: The Captain and the Nav-Computer

Let’s use a space-themed analogy (we are talking about Stellar, after all). Imagine your smart contract is the Captain of a starship. If the Captain needs to open a sliding door or turn on the lights (simple smart contract logic), they do it easily. It consumes almost no energy. But imagine the Captain needs to calculate a hyper-jump trajectory through a moving asteroid field (that’s the heavy ZKP math). If the Captain tried to calculate this by hand using a pencil and paper on the bridge, it would take weeks, burn through all the ship's life support reserves (gas fees), and the ship would likely crash before the answer was found.

A host function is like using the ship’s dedicated Nav-Computer. The Captain doesn't do the math manually; they just punch in the destination and hit "Calculate." The ship’s mainframe (the Stellar nodes) runs the complex physics equations instantly using highly optimized hardware circuits. The Captain still decides where to go (the logic), but the heavy lifting is offloaded to the machine built specifically for speed. In technical terms, the "Nav-Computer" is the pre-compiled, native machine code running on the node, which is infinitely faster than the "Captain" trying to run math inside the constrained Wasm environment. Generally speaking, every blockchain has its own unique set of host functions (often called "precompiles," "syscalls," or "native programs"). Think of them like the operating system APIs for that specific blockchain.

BLS12-381…

So, back to the main topic: "adding support" meant adding host functions for BLS12-381 and its underlying field arithmetics. In simple terms: "Now you can play around with ZKP on Stellar!" Wooooow, isn’t that awesome? But if you opened the GitHub issue link I shared earlier (this one, cheers if you did!), you might have read: “The most widely used pairing friendly curve is BN254 (...) due to the fact that Ethereum has support for it.” Wait. What is BN254? Why was BLS12-381 chosen first? AND WHY DO THESE NAMES LOOK SO RANDOM? Let’s take another detour to talk about elliptic curves.

… and BN254

At their core, elliptic curves are specific mathematical structures, essentially complex algebra equations graphed as curves, that allow computers to perform cryptographic tasks like signing transactions or verifying proofs extremely efficiently. The names BN254 and BLS12-381 might look random, but they are scientific labels: "BN" and "BLS" stand for the researchers who discovered the curve families (Barreto-Naehrig and Barreto-Lynn-Scott), while the numbers describe precise parameters like the size of the prime numbers used to build them.

Think of these two curves as incompatible types of mathematical railroad tracks designed for the heavy lifting of Zero-Knowledge proofs.

• BN254 (aka `alt_bn128`) acts like a "legacy" high-speed rail line from around 2015. It was adopted early by Ethereum, making it the standard track for thousands of existing applications because it is lightweight and cheap to run. However, later research found its security walls (about 100-bit) to be slightly thinner than originally intended.
• BLS12-381 is the modern, heavy-duty freight line designed for long-term safety. It offers the gold-standard 128-bit security preferred by newer networks like Zcash and Ethereum 2.0. This extra armor means its keys are larger and its operations require slightly more computational power.

Because a proof written for one curve is mathematically unreadable by the other, Stellar's decision to support both is like building a station that can service both the older, widespread commuter trains and the newer, heavy-armored security transports. This ensures developers don't have to rebuild their entire fleet just to switch networks.

X-RAY: The Protocol Upgrade That Changes Everything

So, did Stellar make the right decision by implementing BLS12-381 first and not BN254? Yes and no. Yes, for the security reasons I mentioned above. No, because right now (Jan 2026), implementing support for BN254 is… actively in progress! But why? As explained in CAP-0074: Host functions for BN254 (CAP stands for Core Advancement Proposals): “While Stellar has native support for BLS12-381, many existing applications still rely on BN254 because it's the only pairing-friendly elliptic curve with native support in the EVM. Adding BN254 support will allow those applications to add support for Soroban without the need to use a different curve.”

Without native Soroban support for BN-254, developers building ZK apps on Stellar would have to either rewrite their applications or maintain complex workarounds. Supporting both gives developers the flexibility to choose the curve that best suits their goals. In Nov 2025, the Stellar Team announced an upcoming protocol upgrade called X-Ray. This upgrade proposes native support not only for BN254 but also for another important ZK primitive: Poseidon!

Poseidon: The Hash Function Built for Zero-Knowledge

Poseidon is a family of hash functions designed specifically for ZKP systems. As the article states: “While BN254 provides the pairing operations for proof verification, you also need an efficient cryptographic hash, which is where Poseidon comes in. (...) These primitives let developers design hash functions that are highly efficient in ZK circuits, addressing a key performance bottleneck in ZK systems.”

Traditional hashes like SHA-256 are computationally expensive to model within proofs. Poseidon is like a sports car built specifically for the ZK racetrack. And again, adding support for it means adding a host function to Soroban. This was introduced in CAP-0075: Cryptographic Primitives for Poseidon/Poseidon2 Hash Functions.

Why This Matters?

This perfect duo, CAP-0074 and CAP-0075, establishes the rock-solid cryptographic foundation developers have been waiting for. It allows us to build privacy-preserving applications on Stellar without compromising the transparency that makes blockchain so powerful.

So, what does this actually unlock for us? (Glad you asked!):

• Smooth Sailing: Migrating existing ZK apps becomes a walk in the park.
• Turbo Efficiency: Proof systems become faster, leaner, and more powerful.
• Wallet-Friendly: We’re talking significantly lower costs for ZK-based contracts.
• The Big Bridge: It opens a massive gateway to the broader ZK ecosystem, inviting everyone to the party.

I hope this (zero-) knowledge unlocks your curiosity and willingness to give Stellar a try with your new ZKP project. I’ve already tried it and can’t wait to see both CAPs live on mainnet! In the meantime, stay tuned, and as always, reach out to us if you have any questions. See you next time!