Shielded pool on Stellar.

Stellar has an existing research primitive in this class — SDF commissioned shielded-payment protocol work (SPP) that showed a Groth16 pool is viable on this network. Hypertron is a CAP-0059 deployment of that construction: live testnet contracts, browser proving, an indexer for leaf availability, and merchant-facing layers on the same note set. Cite the primitive. This page describes Hypertron's circuits and contracts, not a comparison.

The transfer pool is the only authority that may insert commitments or mark nullifiers spent. Verifier-key administration can replace a registered VK with no timelock.

owner_pk = Poseidon(spend_sk, 0)
cm       = Poseidon(Poseidon(owner_pk, k), v)
nf       = Poseidon(spend_sk, k)

• spend_sk — secret required to spend. Never encrypted into viewing blobs.
• owner_pk — public receiving material. Deposit does not require the spend key.
• k — per-note blinding. Reused k under the same spend key collides nullifiers.
• v — value. Spent input value is constrained by conservation, not a second bit decomposition.

Blob length for a valid AEAD ciphertext is 144 bytes: 32-byte ephemeral public key, 96-byte plaintext, 16-byte Poly1305 tag. The ChaCha nonce is implicit all-zeros; uniqueness comes from a fresh ephemeral key per note.

Transfer blobs are not circuit public inputs. A submitter can replace, empty, or omit them without invalidating the proof. Scanners must recompute cm from a decrypted note and match the published leaf. Ownership still follows the proof-bound commitments.

Unshield recipient_field is the BLS12-381 scalar reduction of SHA-256(XDR(ScVal::Address(recipient))). The contract derives it from the actual payout address, so a submitter cannot redirect funds. Unshield does not emit an encrypted change blob; the wallet must retain change material. Withdraw UI is still the 1-in unshield path.

// N ∈ {2, 4}. No dummy-input padding.
Public:  [root, nf_1 … nf_N, out_cm1, out_cm2]
Private: [spend_sk,
          for each input i: k_i, v_i, Merkle path,
          owner_pk1, k1, v1, owner_pk2, k2, v2]
Checks:
  owner = Poseidon(spend_sk, 0)
  each input cm is in root under that owner
  nf_i = Poseidon(spend_sk, k_i)
  out_cm1, out_cm2 open correctly
  v1, v2, each input v are 64-bit
  Σ v_i = v1 + v2

Checkout selects the smallest confirmed-note set whose values sum to at least the payment, with size in {1, 2, 4}. A three-note cover takes a fourth owned note when one exists; otherwise the caller must top up. There is no 3-in circuit. That hole is intentional: a 3-in VK would be another setup, another proving key, another registration.

Contract entry points: transfer (VK 3) and transfer_n (VK 4 or 5, requiring 2 or 4 nullifiers). WASM exports transfer_2_proof and transfer_4_proof.

# Hashes local artifacts against deployments/testnet.json
# then checks the chain accepts a fresh proof from each PK.
./scripts/verify_deployment.sh

A Groth16 pairing check cannot pass against an unrelated verifying key, so the script confirms the on-chain keys without trusting deployments/testnet.json or its author. The VkRegistered event carries only the vk_id, not the key hash — observers must re-run the script after any admin action.

Open pool on Stellar Lab

• The server already cross-checks commitment.root() on-chain before treating an indexer response as current.
• The browser still builds Merkle paths from served leaves. It does not yet recompute the Poseidon root and compare it with the on-chain root. Until that check ships, clients depend on the indexer for correct path construction, not only availability.
• Deposit and unshield require require_auth on the transparent Stellar account. Private transfer does not: the proof binds the state transition, so a relayer can submit. This repository does not operate a production relayer. Direct submission exposes the submitter (CAP-0015 fee-bump is the intended cover).