Stellar X-Ray Makes ZK Parameter Safety a Smart-Contract Responsibility
Stellar’s X-Ray upgrade exposes BN254 and Poseidon primitives to Soroban, widening ZK interoperability while leaving parameter selection and resource safety in developers’ hands.

Stellar’s Protocol 25, known as X-Ray, is now live, according to the Stellar Development Foundation’s Q1 2026 report. Its significance for ZK developers is less about adding a complete privacy protocol and more about moving core cryptographic building blocks into Soroban’s host environment.
X-Ray adds native BN254 operations—bn254_g1_add, bn254_g1_mul, and bn254_multi_pairing_check. BN254 is widely used by Ethereum-compatible proving systems, so native support can reduce the need to rewrite circuits or ship expensive workarounds when bringing ZK applications to Soroban. The CAP also specifies explicit byte encodings, validation behavior, and separate metering categories for decoding, curve checks, scalar multiplication, and pairings.
The second half of the upgrade exposes Poseidon and Poseidon2 permutation primitives. This is an important design choice: Soroban does not provide one fixed hash function, but a configurable permutation that applications can combine into hash, compression, or Merkle-tree constructions. The CAP supports both the BLS12-381 and BN254 scalar fields and allows parameters such as state width, round counts, matrices, and round constants to be supplied by the caller.
That flexibility is also the sharpest security boundary. The specification performs basic shape and field validation, but does not determine whether supplied rounds, matrices, and constants form a cryptographically secure configuration. Developers therefore need established parameter sets, test vectors, and interoperability tests—not merely a successful host-function call. Incorrect parameters can weaken collision or preimage resistance, while inaccurate cost calibration can create denial-of-service exposure.
There is also a documentation caveat worth preserving in release checklists: CAP-0075’s preamble identifies protocol 25, but its transition section says the new functions are available from protocol 24. That conflict does not invalidate the architectural direction, but builders should verify the live protocol version, SDK bindings, and deployment behavior before relying on these imports in production.
For ICP developers, the lesson is portable. A ZK-enabled chain becomes easier to target when it offers native curve and hash primitives, but interoperability is not the same as safety. A production integration should pin the curve, serialization format, proving-system parameters, host-function availability, and resource budget as one tested compatibility contract.
Get the wire in your inbox
Every new signal, straight from the generator. No noise, unsubscribe anytime.


