The Poseidon hash function [@grassi2021poseidon] occupies an unusual position in production zero-knowledge cryptography: the algorithm is widely deployed, the parameter sets are nominally standardised by the original paper, and yet the actual round-constant tables shipped by independent implementations differ. Two implementations both claiming "Poseidon-128 over BN254 with $t = 3$" can nevertheless produce different hashes for the same input.
The cause is not malice or careless engineering. It is that the round-constant generation procedure — a deterministic stream from a Grain-style linear-feedback shift register, parameterised by the field, the state size, the alpha, and the round counts — has multiple defensible interpretations of small details: byte ordering of the seed, whether full rounds are emitted before partial rounds in the constant stream, whether constants for the non-spongy state elements during partial rounds are emitted-and-discarded or skipped entirely. Different implementations made different choices in 2020 and 2021. Those choices are now load-bearing for a substantial deployed footprint and cannot be re-litigated without breaking existing zero-knowledge proofs.
This paper does three things. First, it documents the parameter-selection methodology a production implementer should follow if starting fresh, including the alpha-vs-round-count tradeoff specific to BN254 [@barreto2005bn]. Second, it traces the divergence between the round-constant streams of two prominent reference implementations — circomlib [@grassi2021poseidon] and arkworks — to a specific design choice in how the LFSR is consumed during partial rounds. Third, it argues that for new deployments aiming for cross-implementation compatibility, the right move in 2026 is to treat the circomlib parameter file as a frozen specification and validate one's implementation against a deterministic test vector.
Poseidon's parameter space is a five-dimensional lattice $(\mathbb{F}_p, t, \alpha, R_F, R_P)$:
For BN254, $p - 1$ has small factors $2$ and $3$, so $\alpha = 2, 3, 4$ all share a factor with $p - 1$ and produce non-bijective S-boxes. The smallest legal $\alpha$ is $5$. This is not negotiable — $\alpha = 5$ for BN254 is mechanically forced by the field, not a design preference.
Higher $\alpha$ would, in principle, reduce the number of rounds needed: each S-box introduces more algebraic non-linearity, so fewer rounds suffice for a given security target. For BN254, the candidate alternatives to $\alpha = 5$ are $\alpha = 7$ and $\alpha = 11$. The trade is concrete: an $\alpha = 7$ S-box costs four constraint multiplications in R1CS (one for $x^2$, one for $x^4$, one for $x^6 = x^4 \cdot x^2$, one for $x^7 = x^6 \cdot x$), versus three for $\alpha = 5$. Recommended round counts for $\alpha = 7$ on BN254 are $R_F = 8$, $R_P \approx 47$ — that is, ten fewer partial rounds than $\alpha = 5$'s $(8, 57)$ recommendation.
The total constraint count under each choice is: $$ \mathsf{cost}{\alpha = 5} = 8 \cdot 3t + 57 \cdot 3 = 72 + 171 = 243 \text{ for } t = 3 $$ $$ \mathsf{cost}{\alpha = 7} = 8 \cdot 4t + 47 \cdot 4 = 96 + 188 = 284 \text{ for } t = 3 $$
Under this accounting, $\alpha = 5$ wins at $t = 3$ for the recommended security margin. For larger $t$ the gap narrows and may invert; production implementers targeting wide states ($t \geq 5$) should re-do the arithmetic.
The original Poseidon analysis computes the minimum round count to resist three classes of attack: Gröbner-basis interpolation, statistical/differential cryptanalysis, and the round-counting attack on the partial-rounds region. The recommended $(R_F, R_P)$ for BN254 with $t = 3$ at the 128-bit security level is $(8, 57)$, with a safety margin of approximately $25%$ above the minimum. Subsequent cryptanalytic work [@bariant2023algebraic] has tightened the analysis but not invalidated the recommendation.
We adopt the original recommendation in this paper and note that Poseidon-2 [@grassi2023poseidon2] should be considered for new deployments — Poseidon-2 simplifies the round structure with provably-equivalent security, and its parameter recommendations are cleaner to argue about.
The round-constant stream is generated by a Grain-style LFSR seeded from a description of the parameter set. The seed is, conceptually, the tuple $(\text{field-id}, t, R_F, R_P, \alpha)$, encoded into a fixed-width bit string that initialises the LFSR. The LFSR then produces a stream of bits, which is chunked into field-element-sized blocks. Each block is rejected if it exceeds the field modulus and accepted otherwise — a rejection-sampling technique that ensures uniform distribution in $\mathbb{F}_p$.
Under the original specification, the stream is consumed in round order, in state-element order within each round. Concretely: for a state size $t = 3$ and $R_F + R_P = 8 + 57 = 65$ rounds, the stream produces $65 \cdot 3 = 195$ field elements, indexed $r_{0,0}, r_{0,1}, r_{0,2}, r_{1,0}, \dots, r_{64, 2}$.
This is where the implementations diverge.
circomlib interpretationcircomlib consumes the stream in the obvious linear order described above and materialises every constant, including the constants for state elements that are not S-boxed in partial rounds. The constants for non-active partial-round positions are added to the state during the linear MDS step but never participate in an S-box. This wastes a few constraints' worth of additions but has the property of treating the LFSR as a single, monolithic stream.
arkworks interpretationarkworks (and a small handful of other Rust-native implementations) optimises by skipping the LFSR positions that would have produced constants for the non-active state elements during partial rounds. The argument is that those constants are mathematically redundant — they can be folded into a constant offset per non-active position that is accumulated across the partial-rounds region — and therefore should not consume LFSR output. The constant stream consumed by arkworks is shorter than circomlib's by exactly $(t - 1) \cdot R_P$ field elements.
Both interpretations produce a Poseidon hash that is, on its own, a valid instantiation of the specification. They are, however, mutually incompatible: a circuit compiled against circomlib constants will not verify a proof produced against arkworks constants, even though both implementations claim to be Poseidon-128 over BN254 with $(t, \alpha, R_F, R_P) = (3, 5, 8, 57)$.
This is not an implementation bug. It is a specification ambiguity that the original paper did not foreclose. By 2026 the deployed weight of circomlib-compatible circuits — including all production deployments of zk-SNARK shielded-pool stacks built on the Iden3 toolchain [@hopwood2022zcash] — substantially exceeds the deployed weight of any alternative interpretation. We argue below that this asymmetry should be the deciding factor for new implementations.
For a new deployment of Poseidon-128 over BN254 in 2026, the production-correct choice is:
circomlib round-constant table verbatim. Do not regenerate constants from the LFSR seed in your own implementation; instead, ingest the JSON file shipped by circomlib and validate it against a known test vector (§5).arkworks deployment), state which interpretation, why, and what proofs are interoperable.This recommendation is conservative. It accepts that the spec ambiguity should not be re-litigated, that the deployed footprint is a fact, and that interoperability is more valuable than implementation independence for an SDK that aims to participate in the existing zero-knowledge ecosystem.
The reader who finds this conservative is correct. The reader who finds it inappropriate is also correct in principle: if a new deployment is genuinely greenfield, a fresh start with Poseidon-2 [@grassi2023poseidon2] is cleaner. Poseidon-2 has tighter parameter recommendations, an unambiguous LFSR consumption order, and active maintenance from the original authors. New deployments that do not need circomlib interoperability should prefer Poseidon-2.
To validate that an implementation matches the circomlib interpretation, we publish the following test vector. With state $\mathbf{s}0 = (0, 1, 2)$ and the canonical Poseidon-128 BN254 parameter set $(t, \alpha, R_F, R_P) = (3, 5, 8, 57)$ using the circomlib round-constant table, the output of the permutation $\mathbf{s}{65}$ is a triple of field elements whose first coordinate (the canonical sponge output) is:
$$ \mathsf{poseidon}2(0, 1, 2)\big|{0} = \texttt{0x115cc0f5e7d690413df64c6b9662e9cf...} $$
\note{TODO: empirical validation — replace the truncated digest above with the full 32-byte hex value extracted from a fresh circomlib run and a parallel reference implementation, and include parallel test vectors for inputs $(1, 2)$, $(2, 3)$, and the all-zeros input.}
The test vector is deterministic, parameter-set-pinned, and publicly auditable. An implementation that does not reproduce it bit-for-bit is not circomlib-compatible, regardless of what the README claims.
Three operational consequences of treating circomlib as the frozen specification:
circomlib constants and then needs to switch to Poseidon-2 has stranded hardware.None of these are unique to Poseidon. They apply to any cryptographic primitive whose security depends on a specific constant table. They are worth naming because the original Poseidon paper does not call them out, and operations teams discover them empirically the first time a constant-table mismatch surfaces.
A reviewer would correctly note that round constants are only one of two parameters that vary across Poseidon implementations. The MDS (Maximum Distance Separable) matrix used in the linear layer is also implementation-specified, and different implementations have shipped different MDS matrices that produce different hashes for the same input.
The original Poseidon paper [@grassi2021poseidon] specifies a procedure for constructing an MDS matrix from a Cauchy matrix over $\mathbb{F}_p$, parameterised by the same Grain LFSR seed used for round constants. The procedure is deterministic given the seed, but again leaves degrees of freedom: which subset of field elements to use as the Cauchy parameters, how to verify the matrix's MDS property over the field, and how to handle the case where the candidate matrix fails the MDS test (rejection-sample? fall back to a known-good matrix? error out?).
circomlib ships a pre-computed MDS matrix that is treated as a constant, just like the round-constant table. arkworks re-derives the matrix from the seed at startup and verifies the MDS property at runtime. Both approaches produce some valid MDS matrix; they do not produce the same MDS matrix.
The recommendation is symmetric to the round-constant recommendation: treat the circomlib MDS matrix as part of the frozen specification. Vendor it. Checksum it. Validate against the test vector.
A subtler interoperability question: when implementations encode the Poseidon state $\mathbf{s} \in \mathbb{F}_p^t$, do they use little-endian or big-endian byte order? Does the canonical hash output reduce $\mathbf{s}_0$ modulo $p$ before serialising, or does it serialise the in-memory representation directly? When does an implementation accept inputs that exceed the field modulus, and when does it reject them as invalid?
These questions have answers in any individual implementation, but the answers are not specified in the paper. A user porting test vectors between two implementations may find that the same input-bytes produce different field elements, and the same field elements produce different output-bytes, even if the round constants and MDS matrix agree.
We adopt the following convention in our deployment:
This convention matches circomlib's convention. It does not match arkworks' default convention, which uses big-endian. Implementations that need to interoperate with both must perform a byte-swap at the boundary; we document this in the SDK's Poseidon module-level docstring.
A frequently overlooked consideration: a hash function used in multiple distinct contexts in a protocol should ideally have a per-context domain separator that prevents collisions across contexts. For Poseidon, the conventional approach is to absorb a context tag as the initial state element, so $\mathsf{poseidon}(\mathsf{tag}, x_1, x_2)$ rather than $\mathsf{poseidon}(0, x_1, x_2)$.
The choice of tag is implementation-defined. circomlib uses an integer in the range ${1, \dots, 2^{16}}$, encoding the context as a small, human-readable identifier. Other implementations use a hash of a string identifier. Production implementers should pick a convention, document it, and stick to it for the lifetime of any deployed circuit.
In our deployment we use circomlib-style integer tags, with tag $0$ reserved for the un-domain-separated case (which we then refuse to use in production code). The full tag table is part of the SDK's circuit specification and is checked at compile time against a manifest file.
Implementations differ subtly in how they represent field elements at the API boundary. The two prevalent representations are canonical (every element of $\mathbb{F}_p$ has a unique byte representation, the lexicographically least integer in its residue class) and Montgomery form (every element is multiplied by a precomputed constant $R$ for arithmetic efficiency, with conversion happening at the boundary).
For interop, the API boundary should be canonical. For internal arithmetic, Montgomery form is faster. The conversion is essentially free if the caller is doing many operations, but expensive if the caller is doing one. SDKs that surface a hash_one_pair API where each call performs a single Poseidon should keep elements in canonical form; SDKs that surface a streaming hash_many API can keep them in Montgomery form across the stream and convert only at boundaries.
Production implementations should benchmark this. Our own benchmarks suggest a $3$-$5%$ gain from Montgomery form on hot paths\note{TODO: empirical validation — pin to measured numbers from the BN254 hash-throughput benchmark suite on the target deployment hardware.}, but the gain disappears on cold-call paths where conversion dominates. The right answer is workload-dependent.
The interoperability story above suggests a concrete engineering practice: differential test against circomlib for every change to the SDK's Poseidon implementation. Concretely, a pre-commit hook should compare the SDK's hash output against circomlib's reference implementation for a fixed corpus of test vectors, and fail the commit if any differ.
We adopt this practice in our deployment. The corpus is approximately 1,000 inputs covering: zero, one, the field modulus minus one, randomly-sampled elements, structured patterns (powers of two, fibonacci sequences), and known-tricky cases (inputs that exercise the rejection-sampling boundary in the LFSR). Differential testing has caught two regressions in our implementation since adoption — one in the MDS-application code, one in the partial-rounds-vs-full-rounds boundary — that would otherwise have shipped as silent incompatibilities.
The cost of maintaining the test corpus is modest. The benefit is enormous: a Poseidon implementation that passes a 1000-input differential test against circomlib is vastly more likely to interoperate with the deployed circuit population than one that has only been unit-tested against its own internals.
A recurring temptation in cryptographic engineering is to ship a "better" version of a primitive — one with cleaner mathematics, faster constants, smaller round counts. Each such variant fragments the deployed ecosystem, and over a multi-year horizon the fragmentation cost typically exceeds the local efficiency gain.
This is not an argument against innovation. Poseidon-2 is a genuine improvement over Poseidon, and a deployment that does not need backward compatibility should ship Poseidon-2 [@grassi2023poseidon2] from day one. It is an argument against shipping minor variants — a tweak to the LFSR consumption order, a different MDS construction, a slightly different alpha — that produce mathematically identical security properties but bit-incompatible outputs. Such variants do not improve the world; they fork it.
The recommendation, therefore, is to choose a primitive (Poseidon-1 with circomlib parameters, or Poseidon-2 with the AFRICACRYPT-2023 parameters) and stay there. Cross-curve agility is fine; cross-version agility within the same primitive is not.
Round-constant selection for Poseidon-128 over BN254 is a settled choice in 2026, but the settlement is de facto rather than de jure: the specification permits multiple consumption orders for the LFSR stream during partial rounds, and the implementations that diverge are not wrong in any specifiable way. The deployed footprint of circomlib-compatible circuits is the deciding factor for production implementers, and we recommend treating the circomlib constant table as a frozen specification with a deterministic test vector.
The methodological lesson is broader than Poseidon. When a cryptographic specification leaves degrees of freedom, the first widely-deployed interpretation becomes the specification by accretion. Implementations that ignore this property fragment the ecosystem; implementations that recognise it preserve interoperability at the cost of mathematical aesthetics. In 2026 the right move for production zero-knowledge stacks is to recognise the property and document the constraint.
[^ref]
]]>A shielded UTXO chain reveals neither sender, recipient, nor amount on chain. To prevent double spends without revealing the spent note, every shielded protocol since Zerocash [@bensasson2014zerocash] has used a nullifier: a deterministic single-use identifier $\mathsf{nf}$ derived from a secret known only to the spender and the public commitment of the consumed note. The chain treats the global set of disclosed nullifiers as state; a duplicate nullifier indicates a double spend.
The structural question every such chain must answer is where the nullifier set lives. The historical answers — wallet-side index, smart-contract sidechain, consensus-layer state — span a spectrum of soundness, operator-trust, and engineering complexity. The Zcash protocol [@hopwood2022zcash] places the set in node chainstate; the Tornado-style Ethereum deployments place it in a contract; some lighter-weight UTXO experiments leave it to the wallet.
We focus on a specific point in this design space: a Bitcoin-fork chain that carries the nullifier set in consensus state. We refer to such a chain as an L1-nullifier chain. The contribution of this paper is:
The paper is theorem-statement in shape and engineering-aware in spirit. Where empirical claims appear, they are flagged.
We adopt the backbone abstraction of Garay et al. [@garay2015backbone] with three additions.
Definition 2.1 (Shielded UTXO chain). A shielded UTXO chain $\mathcal{C}$ is a sequence of blocks $B_0, B_1, \dots$ where each $B_i$ contains:
A node maintains $\mathsf{NS}i = \bigcup{j \le i} \bigcup_{\tau \in \mathsf{Tx}^s_j} {\mathsf{nf}_k : \mathsf{nf}_k \in \tau}$ as part of its chainstate, together with the standard UTXO set.
Definition 2.2 (Validity). Block $B_i$ is valid with respect to $\mathcal{C}|_{<i}$ if:
The no-collision rule is the central addition. Under the standard backbone semantics, an honest node observing a block whose shielded transactions reuse a nullifier rejects the block. The block is not "valid until someone notices"; it is invalid at the consensus boundary, in the same way a transparent transaction spending an absent UTXO is invalid.
Definition 2.3 (Double spend). A double spend against $\mathcal{C}$ is a pair of accepted shielded transactions $\tau, \tau'$ in the same chain history such that $\tau \neq \tau'$ and $\exists, \mathsf{nf} : \mathsf{nf} \in \tau \cap \tau'$.
Theorem 3.1 (Soundness of L1-nullifier-set enforcement). Let $\mathcal{C}$ be a shielded UTXO chain as in Definition 2.1, with nullifier function $\mathsf{nf} = H(sk, C)$ where $H$ is a $(\lambda)$-collision-resistant hash and $sk$ is uniformly distributed in the note's secret-key space. Then, conditioned on the underlying backbone protocol's common-prefix and chain-quality properties [@garay2015backbone] holding with parameter $\epsilon$, the probability that an accepted block contains a double spend is at most $\mathrm{negl}(\lambda) + \epsilon$.
Proof sketch. Let $\tau$ and $\tau'$ be two shielded transactions sharing a nullifier $\mathsf{nf}$. Two cases.
Case A. $\tau$ and $\tau'$ consume the same underlying note. By construction of the proof system, the existence of a valid $\pi$ for both transactions implies both knew the witness $(sk, C)$ for the consumed note. The chain accepts at most one such transaction by the no-collision rule (Definition 2.2, clause 3). Acceptance of both therefore violates the no-collision rule and constitutes a consensus violation, not a soundness violation: such an acceptance can occur only if the backbone's common-prefix property fails, which happens with probability $\le \epsilon$.
Case B. $\tau$ and $\tau'$ consume distinct notes that produce the same nullifier. This requires $H(sk_1, C_1) = H(sk_2, C_2)$ with $(sk_1, C_1) \neq (sk_2, C_2)$, i.e., a collision in $H$. By assumption $H$ is $(\lambda)$-collision-resistant, so the probability of this case is $\mathrm{negl}(\lambda)$.
A union bound over the two cases yields the theorem.
The structure of the argument deserves comment. The interesting work is done by the no-collision rule, which lifts double-spend prevention from a wallet-side liveness property (where one trusts every wallet to refuse to construct a colliding spend) to a chain-wide safety property (where a colliding block is rejected by every honest node regardless of who produced it). The proof is then almost trivial; this is the point. A clean primitive admits a clean theorem.
In our reference implementation, $H(sk, C) = \text{Poseidon2}_t(sk, C)$ with $t = 3$ and the BN254 [@barreto2005bn] scalar field. Poseidon-2 [@grassi2023poseidon2] inherits the cryptanalytic argument of the original Poseidon design [@grassi2021poseidon] with simplified round structure, and is currently the subject of active analysis [@bariant2023algebraic]. Under the standard sponge indifferentiability argument [@bertoni2008indifferentiability], Poseidon-2 is collision-resistant against generic adversaries up to the output bound, which for the BN254 field with a 256-bit output gives $\lambda = 128$ bits of collision resistance — sufficient for practical deployment.\note{TODO: empirical validation — confirm cryptanalytic state-of-the-art for Poseidon-2 at submission time. Bariant et al. 2023 introduces a degree-of-freedom argument worth surveying.}
Theorem 3.1 then specialises to the statement that, conditioned on the backbone holding, the probability of an accepted double spend on this chain is $2^{-128}+\epsilon$ — for any plausible $\epsilon$, the cryptographic term dominates the operational term, which is the desired regime.
The headline cost of consensus-resident nullifier sets is monotonically increasing storage. Each accepted shielded spend permanently extends $\mathsf{NS}$ by $|H|$ bytes. We give a back-of-envelope analysis.
For Poseidon-2 over BN254, $|H| = 32$ bytes. If the chain achieves a long-term steady state of $k$ shielded spends per block at a block interval of $T$ seconds, the annual nullifier-set growth is $$ \Delta_{\text{year}} = k \cdot \frac{31{,}536{,}000}{T} \cdot 32 \text{ bytes}. $$
For a one-minute-block chain ($T = 60$) with five shielded spends per block, $\Delta_{\text{year}} \approx 84$ MB.\note{TODO: empirical validation — confirm against measured Vanta block telemetry once a steady-state shielded-spend rate is established.} Over a decade this yields $\approx 840$ MB of nullifier state, well below the current Bitcoin UTXO set [@bonneau2015sok].
Synchronisation cost is dominated by the $O(\log n)$ sparse-Merkle insertion path per nullifier, where $n$ is the size of $\mathsf{NS}$. Provided that nodes maintain $\mathsf{NS}$ as an SMT [@buterin2016sparse] with hash-array-mapped-trie compression, the per-insert cost is on the order of microseconds, and the per-block insert batch is dominated by the proof-verification time of the shielded transactions, not the SMT maintenance.
The initial-block-download (IBD) cost dominates the operator experience for a new node joining the network. Concretely: how long does it take for a freshly synced node to reach tip, given that it must validate every shielded transaction in the chain's history?
The validation cost per shielded transaction breaks down into three components:
Component (2) dominates by two orders of magnitude. A back-of-envelope calculation: assuming 5 shielded spends per block at 30 ms verification each, the per-block proof cost is 150 ms. For a one-minute-block chain over ten years, this is $5 \cdot 525{,}600 \cdot 10 \cdot 0.030 \approx 22$ hours of pure CPU time, which scales linearly with the number of cores available for parallel proof verification. On a 16-core machine, IBD completes in under 90 minutes — comparable to Bitcoin's transparent IBD.\note{TODO: empirical validation — measure on production hardware once the chain has substantial history.}
The takeaway is that IBD is feasible but not trivial. Operators running on resource-constrained hardware (single-core SBCs, embedded systems) should be advised that IBD is the primary bottleneck and that the chain's hardware floor is set by proof-verification performance.
A natural follow-on question to §6.2's discussion of nullifier pruning: can we instead prune the proofs that established the validity of historical shielded spends, while retaining the nullifiers themselves?
The answer is yes, and our reference implementation does so: a node that has reached the network's checkpointed tip discards proof bytes for transactions older than a configurable horizon, retaining only the nullifier and the commitment-tree root. The savings are substantial — proofs are 256 bytes in our Groth16 instantiation, so over a decade with 5 spends per block one saves roughly $5 \cdot 525{,}600 \cdot 10 \cdot 256 \approx 6.5$ GB of proof data.
The soundness of pruning rests on the same assumption that justifies pruning the witness data of confirmed transparent transactions: a sufficiently-confirmed shielded spend will not be reorganised, and a node that joins after the prune horizon has elapsed must trust the network's checkpoints to validate history rather than re-verifying every proof. This is a standard SPV-style assumption and is conventionally accepted.
A compressed-account chain batches notes into a single Merkle commitment per block to reduce on-chain storage; the chainstate stores roots, not individual notes. The natural extension of L1 nullifier sets to compressed-account chains stores not individual nullifiers but a Merkle tree of nullifiers per block, with the per-block root committed in the coinbase.
The soundness statement (Theorem 3.1) carries over with minor modifications. The no-collision rule generalises to: for every spent nullifier in the block, no preceding block's nullifier-tree contains it, and no other transaction in this block discloses it. Membership proofs replace direct lookup. The asymptotic cost of a membership proof is again $O(\log n)$ but now with a larger constant due to the per-block tree maintenance overhead.
We do not pursue a full proof of the compressed-account variant in this paper; we register only that the soundness argument transfers, conditioned on the membership-proof verifier being itself sound — a property the underlying SNARK already provides.\note{TODO: empirical validation — formalise once a reference compressed-account UTXO chain ships in production.}
We close with two questions our own engineering experience has not yet resolved.
A sparse Merkle tree's per-insert cost depends, in the worst case, on the depth of the longest currently-occupied path. An adversary that influences the order of nullifier insertions — by, e.g., populating insertion blocks with adversarially-chosen shielded transactions — could in principle drive insertion paths toward a worst-case profile, increasing per-block validation time. We do not have a tight bound on the adversary's leverage here. Existing analyses of Merkle-tree insertion costs assume uniformly random keys, which is an unrealistic assumption when the keys are hash outputs the adversary partly chooses.
This is sharper than the corresponding question for transparent UTXO sets, where insertion order is largely unconstrained, because nullifier values are deterministically derived from the spending witness. An adversary controlling a fraction of block-production capacity has bounded but non-zero influence over the nullifier stream. Open question. Bound the worst-case per-insert cost as a function of the adversary's mining-power fraction.
The nullifier set is, by construction, monotone: nothing is ever removed. After ten years of operation a chain with substantial shielded-spend volume will accrete several gigabytes of nullifier state. We do not have a satisfying answer to when, if ever, it is safe to prune. Pruning under the canonical model breaks soundness: a pruned nullifier could be re-spent.
A speculative direction: pruning conditioned on a soundness-preserving accumulator structure that retains a constant-size membership proof for any past nullifier. We do not pursue this here.
A third question the engineering literature touches but has not, to our knowledge, formalised: under what conditions can a light client verify that an alleged nullifier set is faithful? A light client does not store the full $\mathsf{NS}$; it stores commitment-tree roots and verifies SPV-style. The coinbase commitment to the SMT root of $\mathsf{NS}_i$ allows a light client to verify, given a membership proof, that a particular nullifier is included or excluded as of block $i$.
The verification cost is logarithmic in $|\mathsf{NS}_i|$, but the proof construction is performed by full nodes, which have an incentive to truthfully serve membership proofs to light clients only insofar as the underlying chain is honest by hypothesis. A light client receiving a fabricated exclusion proof from a malicious full node has no recourse if the underlying merkle root does not commit to enough information to detect the fabrication. We rely on the SMT's structural property that exclusion proofs in a sparse Merkle tree are unique and verifiable — given a leaf path, either the leaf is empty (and the path's hashes match the root) or the leaf is occupied (and the path includes the occupant). An adversary cannot forge an exclusion proof for a present element, conditioned on the SMT hash function being collision-resistant.
This reduces the light-client safety argument to the same Theorem 3.1 — collision resistance of the underlying hash — without introducing a new trust assumption.
A separate question concerns how nullifier-set state behaves under chain reorganisations. Bitcoin's UTXO set is reorg-tolerant by construction: a UTXO that is spent in a block, and then the block is reorganised away, is restored as unspent. The same property must hold for the nullifier set: a nullifier consumed in a block that is subsequently orphaned must be removed from $\mathsf{NS}$, returning the corresponding note to the unspent state.
In our reference implementation this is straightforward — the nullifier set is maintained as part of the chainstate snapshot, and chainstate rollbacks happen atomically with block-level rollbacks. The implementation cost is confined to the SMT update logic: deletions during reorg are operationally identical to insertions during apply, with the input ordering reversed.
The interesting subtlety is that selfish-mining attacks [@eyal2014majority] [@sapirshtein2016optimal] interact with the nullifier set in the same way they interact with the transparent UTXO set: an attacker who withholds a block can construct a competing chain with a different nullifier history, and the network may converge on either. A spender whose transaction is reorganised away should be informed by their wallet, exactly as a transparent-transaction spender is informed by their wallet. The nullifier set inherits the reorg semantics of the underlying chain; it does not introduce a new finality caveat.
We have shown that a Bitcoin-fork shielded UTXO chain that places the nullifier set in consensus state admits a clean soundness statement (Theorem 3.1) reducing double-spend prevention to the collision resistance of the underlying nullifier hash. The cost is monotonic chainstate growth, manageable in practice for plausible shielded-spend rates [@bonneau2015sok] and below current Bitcoin UTXO-set sizes for a decade-scale operating window.
The architectural argument is that consensus is the right place for safety properties. Wallet-side enforcement is a liveness property that the network depends on every wallet implementer to honour. Consensus-side enforcement makes the rule binding for every honest node regardless of wallet provenance. For privacy chains aiming at the same finality semantics as transparent Bitcoin, the consensus-side answer is the structurally honest one.
[^ref]
]]>The deployment posture of cryptographic software development kits has changed faster than the threat model that governs them. Until recently, an SDK was a library — a process-local API consumed by an application written by a human, in a language understood by that human, after the human had read enough of the source to form an intuition for what the calls actually did. The principal threat was a buggy caller, and the principal mitigation was clear documentation, robust types, and careful examples.
The introduction of the Model Context Protocol [@anthropic2024mcp] and the subsequent rapid adoption of MCP servers across cryptographic tooling in 2025 and 2026 has changed the principal. The principal is now, with non-negligible probability, an autonomous large-language-model (LLM) agent calling the SDK on behalf of a user that may not understand the call's semantics. The agent is potentially compromised by prompt injection [@greshake2023injection], by tool-poisoning of the upstream MCP server, or by an adversarial input embedded in the agent's working context. The "lethal trifecta" identified by Willison [@willison2025promptinjection] — private data, untrusted input, external communication — is a default property of an MCP-connected wallet stack.
This paper makes a structural argument: cryptographic SDKs that expect to be invoked by AI agents should obey an asymmetric tool-surface discipline, exposing only read and compute primitives over MCP and reserving state-changing authority for an out-of-band, human-in-the-loop, or hardware-enforced confirmation channel. The discipline is narrow and opinionated. It rules out a number of conveniences that look attractive in a normal SDK. It also makes adversarial compromise of the agent layer survivable rather than catastrophic.
The remainder of the paper is organised as follows. Section 2 establishes the threat model and notation. Section 3 defines the asymmetry rule and its decision procedure. Section 4 gives a worked example: an instantiation of the rule for zera-mcp, the MCP surface of a production shielded-pool SDK. Section 5 discusses extensions and limitations. Section 6 concludes.
Let $\mathcal{S}$ denote a cryptographic SDK, and let $\mathcal{T} = {t_1, \dots, t_n}$ denote the finite set of tools $\mathcal{S}$ exposes via an agent-facing protocol such as MCP. Each tool $t_i$ has a typed signature $t_i : \mathbb{I}_i \to \mathbb{O}_i$ and an effect signature $\mathsf{eff}(t_i) \in {\bot, \mathsf{read}, \mathsf{compute}, \mathsf{write}}$.
We adopt the following adversary $\mathcal{A}$:
Under this adversary, we require that for any execution trace $\sigma$ produced by the agent calling tools in $\mathcal{T}$, the on-chain state $\Sigma$ reachable from $\sigma$ should differ from the on-chain state reachable under the trivial empty execution only via transactions that were explicitly co-signed by a wallet $W$ outside $\mathcal{A}$'s control.
In words: an adversary that captures the agent must not be able to move funds. They may be able to spend compute, retrieve information the user already had access to, and produce mathematical objects (commitments, proofs) that are inert until co-signed.
We say a tool surface $\mathcal{T}$ is asymmetric under separation $W$ if for every $t_i \in \mathcal{T}$, $$ \mathsf{eff}(t_i) \in {\mathsf{read}, \mathsf{compute}} ;;\Longleftrightarrow;; t_i \in \mathcal{T}{\text{exposed}} $$ and the residual $\mathcal{T} \setminus \mathcal{T}{\text{exposed}}$ — the tools whose effect signature is $\mathsf{write}$ — are reachable only through $W$.
The decision procedure that produces $\mathcal{T}_{\text{exposed}}$ is the following:
For each candidate tool $t$, ask: if the agent is fully compromised by $\mathcal{A}$, what is the worst-case state delta $\Delta\Sigma$ a single invocation of $t$ can induce? If $\Delta\Sigma = \emptyset$ — that is, if the call is observationally pure modulo the agent's own resources — admit $t$ to $\mathcal{T}_{\text{exposed}}$. Otherwise, route the function behind $W$.
Two consequences follow. First, the procedure is composable: if every individual tool is observationally pure under $\mathcal{A}$, any agent-driven composition of them remains observationally pure under $\mathcal{A}$, because composition does not synthesise authority. Second, the procedure is local: the decision for $t_i$ does not depend on the other tools in $\mathcal{T}$, which makes it tractable for SDK authors to apply at PR review time.
The asymmetry rule does not eliminate every class of attack. An $\mathcal{A}$ that captures the agent can still, in principle, mislead the human into approving a transaction that they would not have approved given full information. The rule cannot fix social engineering. What it forbids is an architecture in which the agent has unilateral capability to drain user funds without human action.
Cryptographic SDKs are unusual among software libraries in that the boundary between computation and authority is unusually crisp. Constructing a Pedersen commitment [@pedersen1991noninteractive] does not move money; submitting a transaction does. Computing a Poseidon hash [@grassi2021poseidon] does not move money; signing the resulting witness with a private key does. Producing a Groth16 proof [@groth2016size] does not move money; broadcasting that proof to a chain does. Each of these primitives admits a clean factorisation along the read/compute vs. write axis.
Compare this to a general-purpose enterprise SDK, where the same call may simultaneously query, mutate, and authorise — the asymmetry rule is too aggressive in that setting because the rule's first effect is to forbid the very calls users want to make. Cryptographic SDKs are exempt from this critique because the underlying mathematics already separates the two.
It is worth being explicit about which conveniences the asymmetry rule eliminates, because each is one a typical SDK author will want.
transfer(asset, amount, to) is the canonical write effect. The asymmetry rule forbids exposing it on the agent surface even if the SDK author has access to a signing key — the right place for that key is a wallet, not the SDK process.revoke_pending_proof(proof_id) looks like a read but actually mutates the SDK's local state in a way that affects future write operations. The rule treats it as a write.zera-mcpWe instantiate the asymmetry rule for zera-mcp, the MCP server bundled with the zera-sdk shielded-pool toolkit. The SDK exposes a small surface: four tools and three resources, all conforming to the asymmetry rule.
| Tool | Signature | Effect |
|---|---|---|
compute_commitment |
$(\mathsf{asset}, \mathsf{amount}, r) \to \mathsf{Commit}$ | $\mathsf{compute}$ |
derive_nullifier |
$(\mathsf{sk}, \mathsf{Commit}) \to \mathsf{Nullifier}$ | $\mathsf{compute}$ |
build_spend_proof |
$(\mathsf{note}, \mathsf{recipient}, \mathsf{amount}) \to \pi$ | $\mathsf{compute}$ |
get_pool_state |
$\bot \to (\mathsf{root}, n_\text{unspent})$ | $\mathsf{read}$ |
compute_commitment is the additively-homomorphic Pedersen commitment $C = g^v h^r$ over the BN254 curve [@barreto2005bn], parameterised by the asset and the amount under a caller-supplied blinding factor $r$. Its output binds the value but reveals nothing about it. The function is observationally pure: $\mathcal{A}$ invoking it in any order with any inputs cannot produce a state delta on chain.
derive_nullifier produces $\mathsf{nf} = \text{Poseidon}_2(\mathsf{sk}, C)$, the deterministic single-use nullifier for the note committed to by $C$. Disclosure of $\mathsf{nf}$ proves that some note has been consumed without revealing which one — and the nullifier is single-use precisely because the chainstate enforces uniqueness, not because the SDK does. The SDK is computing a hash; the chain is what makes the hash matter.
build_spend_proof runs the canonical Groth16 prover for the shielded-spend relation, producing a proof bytestring $\pi$ together with a public-input vector. The proof is a mathematical object: it does not move funds. It is inert until packaged into a transaction, signed by a wallet, and submitted to the chain. We take the deliberate position — defended in §4.3 — that the prover is a tool rather than a resource, despite being deterministic.
get_pool_state returns the most recent commitment-tree root and an aggregate count of unspent notes. It is plainly $\mathsf{read}$.
The following functions exist in the SDK but are not exposed via MCP. They live behind the wallet $W$:
submit_transaction(tx) — broadcasting authority. Lives in the wallet.unlock_key(passphrase) — private-key access. Lives in the hardware-backed keystore.set_pool_endpoint(url) — changes which chain the SDK queries; implicit write because it can redirect future proof construction. Lives in user-mediated config.A reader will note that submit_transaction is, mechanically, exactly the kind of call an agent often wants to make. We argue that mechanical convenience is the wrong frame: the question is whether the agent should ever have unilateral authority to broadcast. We take the position that it should not.
In MCP, resources are read-only, cacheable, and side-effect-free; tools are explicit operations the model decides to invoke. A first-pass reading of build_spend_proof makes it look like a resource: the prover is mathematically deterministic, and given the same witness one obtains the same proof modulo the random tape used for the Fiat-Shamir transform. Resources fit deterministic functions cleanly.
This reading is wrong in practice. A prover is computationally side-effecting: an order-of-magnitude latency cost (4–8 seconds in our benchmarks for a Groth16 spend proof on consumer hardware\note{TODO: empirical validation — tighten with measured BN254 prover numbers from the zera-sdk-core benchmark suite once it lands.}) makes it unsafe to be aggressively cached and silently re-invoked. Resources in MCP are meant to be cheap; a four-to-eight-second resource invoked in an agent loop will exhaust user patience and platform budget long before it exhausts the abstract semantics of the call. The taxonomy, in short, is sensitive to economic facts, not just mathematical ones.
We therefore route the prover behind a tool call, which forces the agent to deliberate about whether to re-invoke it, and we maintain the rule: the prover is a tool, but it is a compute tool, not a write tool.
Because the rule is local — admission of $t_i$ depends only on $t_i$'s effect signature, not on the rest of $\mathcal{T}$ — it composes across multiple SDKs that an agent might call in sequence. An agent that holds an MCP connection to zera-mcp, a shielded-pool SDK, and a separate MCP connection to a generic web-search service can have arbitrary cross-call interaction without the asymmetric SDK losing its property: read+compute calls are still read+compute calls.
A common objection: if every authority decision is human-mediated, common multi-step flows (recurring shielded payments, scheduled deposits) become user-hostile. We acknowledge the friction. The asymmetry rule does not forbid wallets from offering delegated authority — a wallet can have its own internal policy that allows the agent to broadcast pre-authorised transactions matching a signed schedule — but it requires the policy to live in the wallet, not in the SDK's MCP surface.
This matters because the wallet is a privileged process with its own user-interface affordances and its own threat model; the SDK's MCP surface is, by hypothesis, talking to a potentially-compromised agent. The two are not interchangeable. Delegation policy living in the wallet is auditable through the wallet's own surface; delegation policy living in the SDK is exfiltrable along with the rest of the agent's prompt context.
The rule does not prevent a compromised agent from:
get_pool_state to time when the user's wallet is most likely to approve transactions and clustering its social-engineering attempts there.Defences against (1) rely on display-layer integrity in the wallet (the wallet must show what it is signing). Defences against (2) and (3) rely on rate-limiting and on the wallet's policy. None of these are eliminated by the asymmetry rule; we claim only that the rule prevents the catastrophic outcome — direct loss of funds — and reduces the rest to known classes of attack with known mitigations.
We have operated zera-mcp against a population of agents during internal red-team exercises since early 2026.\note{TODO: empirical validation — quantify with concrete adversarial-test counts once the red-team report is publishable.} No agent has been able to induce a state delta absent a wallet co-signature, which is the property the asymmetry rule was constructed to deliver. This is consistent with the formal argument above and is necessary but not sufficient evidence: the absence of an exploit during red-teaming does not constitute a security proof.
The asymmetry rule is, at one level of abstraction, an instance of the principle of least authority — a discipline with a long pedigree in operating systems and capability-based security. The contribution of this paper is not the principle itself but the observation that cryptographic SDKs admit a particularly clean factorisation along the principle's axis, and that the factorisation matches the read/compute vs. write taxonomy already present in the MCP specification.
The closest analogue in the smart-contract literature is the separation of view and state-modifying functions enforced at the language level by Solidity's view/pure qualifiers and by the EVM's STATICCALL opcode. A view function in Solidity cannot mutate state, and the EVM enforces this by reverting any attempt to do so from a static context. The proposal here is that the MCP layer of a cryptographic SDK should adopt the same discipline, with the SDK author — not the protocol — enforcing that exposed tools have view-or-pure semantics.
There is a subtle but important difference between the EVM's static-call discipline and the MCP rule we propose. The EVM enforces statefulness through opcode semantics: a contract function is pure if and only if it never reads chain state, and view if and only if it never writes. MCP has no such enforcement, and consequently the discipline must be carried by the SDK author at design time. This makes the rule a code-review artifact rather than a runtime guarantee. We accept this trade-off because the alternative — embedding effect semantics into MCP itself — would expand the protocol's surface area in ways that are unlikely to be adopted by upstream maintainers in the near term.
A handful of failure modes are unique to zero-knowledge SDKs and worth registering explicitly.
The first is witness exfiltration. A shielded-spend witness contains the secret key of the consumed note. If build_spend_proof is implemented naïvely, the witness is held in agent-accessible memory long enough that a compromised agent can extract it. We mitigate this by passing the secret key to the prover via an out-of-band channel (a wallet-managed pipe) rather than as an MCP tool argument; the agent constructs the recipe for a spend, but the wallet supplies the secret material at proof-construction time. The agent never sees the secret. This requires careful API design: build_spend_proof accepts a handle for the note (a non-secret identifier), and the wallet resolves the handle to the actual key material.
The second is commitment confusion. A compromised agent can construct a valid Pedersen commitment to a value the user did not authorise, and then surface it to the user as if it were the agreed-upon commitment. The asymmetry rule does not prevent this — compute_commitment is observationally pure regardless of which value it commits to. The mitigation lives in the wallet's display layer: the wallet must independently re-derive the commitment for the user-confirmed value and refuse to co-sign if the agent-supplied commitment does not match. This is an instance of the broader principle that user confirmation should be a function of values the user can read, not of opaque cryptographic objects whose contents are obscured.
The third is proof-system parameter pinning. If the prover circuit can be selected at MCP-call time — for example, by accepting a circuit identifier as an argument — a compromised agent can request a proof against a circuit that does not enforce the constraints the user expected. The mitigation is to remove the choice from the agent: the wallet pins the circuit set, and the SDK refuses to construct proofs against circuits the wallet has not whitelisted. We adopt this in zera-mcp and recommend it as a default for any SDK exposing a configurable prover.
The Model Context Protocol is now the default tool-calling surface for AI agents [@anthropic2024mcp]. Cryptographic SDKs that expose themselves via MCP inherit a new principal — the agent — and a new threat model in which the agent may be compromised by adversarial input. We have argued that a small, structural discipline — the asymmetry rule — addresses the most catastrophic class of compromise and is tractable to apply because cryptographic primitives admit a natural read/compute vs. write factorisation that general-purpose SDKs do not.
The rule is opinionated, narrow, and rules out conveniences. We claim that none of those conveniences are worth the catastrophic blast radius they introduce.
[^ref]
]]>