Stream Zero.
Stream Zero is a privacy-preserving salary streaming protocol built for Stellar Soroban and submitted for the Stellar Hacks: Real-World ZK competition. It eliminates the transparency paradox of on-chain payroll by allowing employers to lock funds under a cryptographic commitment while employees vest salary by the second and claim funds with Groth16 zk-SNARKs—keeping employee identities, salary rates, and total vesting amounts hidden while executing verification directly on-chain using Stellar Protocol 25 BN254 host functions.
- Role
- Protocol Architect · Zero-Knowledge & Smart Contract Engineer
- Domain
- Zero-Knowledge Proofs · Stellar Soroban · BN254 Host Functions · Groth16 · In-Browser Proving
System at a glance
What the system does
On-chain Groth16 / BN254 verification
In-browser WebAssembly SNARK proving
Poseidon cryptographic commitments
Front-running & double-spend nullifiers
Architecture flow
From intent to verified state.
- 01
An employer locks USDC into the Stream Zero Soroban vault, publishing only a 32-byte Poseidon commitment of terms.
- 02
The employer shares the commitment preimage link privately with the employee, establishing the private credential boundary.
- 03
The employee's browser uses an Arkworks WebAssembly prover to generate a Groth16 SNARK proving valid accrued vesting.
- 04
The proof binds the employee's recipient address and current cumulative withdrawn total into the public inputs.
- 05
Stellar's native BN254 host functions verify the elliptic curve pairing in ~29.1M CPU instructions and transfer USDC.
01 / Cryptographic architecture
Poseidon commitments and Groth16 zk-SNARK circuits
Mathematical guarantees shielding employee compensation without breaking solvency verifiability.
Poseidon commitment scheme
Locks salary rate and stream start timestamp behind an opaque 32-byte hash Poseidon(secret, salary_rate, start_time), revealing zero details on the public ledger.
Groth16 circuit over BN254
Formulates the private statement that the claimant knows the preimage and that elapsed time multiplied by salary rate satisfies requested withdrawals.
Noir canonical specification
The circuit logic is formalized and unit-tested in Noir with Poseidon2, while the production prover executes Groth16 over BN254 to match Stellar's on-chain pairing precompiles.
02 / On-chain verification
Stellar Protocol 25 native BN254 host functions
Executing zk-SNARK pairing checks natively inside Soroban's resource constraints.
Hand-written Soroban verifier
Implements the Groth16 pairing equation in a compact ~10 KB Wasm contract using Stellar's native bn254 host functions (g1_msm, g1_add, pairing_check).
Predictable compute footprint
The complete on-chain claim operation consumes only 29.1M CPU instructions (~29% of Soroban's 100M limit) and 0.40 MB of memory, enabling smooth single-block finality.
Exact byte-layout compatibility
Matches Ethereum-style big-endian G1 and G2 affine point encodings, guaranteeing deterministic cross-platform proof serialization.
03 / In-browser proving
Client-side WebAssembly SNARK generation
Zero backend trust: employees generate cryptographic proofs directly inside their browser.
In-browser Arkworks prover
Compiles the Groth16 proving engine with wasm-pack into a 1.6 MB browser-executable bundle, requiring no backend proving service.
Sub-1.5 second proving latency
Generates complete proofs client-side in ~1.2 seconds, giving employees an immediate, responsive withdrawal experience.
Byte-level consistency verification
Verified through automated integration test suites proving byte-identical proof generation between browser WASM and on-chain verifier fixtures.
04 / Protocol security
Front-running resistance and state-bound nullifiers
Defense-in-depth against transaction replaying and mempool front-running.
Recipient binding
Hashes the recipient's public address into the SNARK's public inputs, preventing mempool observers or MEV bots from redirecting withdrawals.
Cumulative vesting validation
The on-chain contract enforces its own recorded already_withdrawn total as a public input, making replayed or outdated proofs fail verification.
Ledger timestamp enforcement
Requires proof timestamps to be less than or equal to current ledger time, preventing forward-dated claims before work has elapsed.