STELX
Architecture

A shielded pool, built on proven parts.

Deposit once and your balance leaves the public ledger. From then on your holdings and your payments are yours alone, and the pool proves every rule it enforces rather than asking you to trust an operator. Below is exactly how, including what it does not hide.

STATUS: LIVE ON ROBINHOOD CHAIN TESTNET, CHAIN 46630. 50 TESTS. THREE ADVERSARIAL REVIEWS. NOT YET AUDITED. NOT ON MAINNET.
The note

Your balance is a set of secrets, not an entry in a ledger

A deposit creates a note. The chain stores only a Poseidon commitment to its four fields, added as a leaf to a Merkle tree. The fields themselves never appear on chain.

publicKeyPoseidon of your spending key. Derived from your seed, never published.
tokenThe asset the note holds, as a field element.
valueThe amount. Range-checked in-circuit so a proof cannot mint value.
blindingFresh randomness. Two notes of equal value are still distinct commitments.

Spending a note means proving, in zero knowledge, that you know the secrets behind a commitment somewhere in the tree, without revealing which one. That proof is a Groth16 proof over BN254, roughly ten and a half thousand constraints, generated in your browser. Your spending key never leaves the device.

The broadcaster problem

Someone else pays your gas, and still cannot touch anything

Paying gas from your own wallet would undo the privacy you just bought: the gas payer is public. So a broadcaster submits for you and is paid from inside the pool. That makes the broadcaster the obvious place to cheat, which is why every field it could tamper with is hashed into one value the proof commits to.

extAmountHow much enters or leaves the pool. Signed, and range-checked both ways.
recipientWhere a withdrawal lands. Rejected if it is zero or the pool itself.
broadcasterWho may submit this proof. Nobody else's submission verifies.
feeWhat the broadcaster is paid, from inside the pool.
chainidBinds the proof to one chain. No cross-chain replay.
address(this)Binds it to this deployment. No substitution.

A broadcaster that changes the recipient, skims the amount or inflates its own fee produces a transaction that fails verification. The worst it can do is refuse to submit, at which point you use another one.

Guarantees the system enforces, not promises we make

Value cannot be minted. Inputs plus the public amount must equal outputs, and the public amount is range-checked in-circuit, not only in the contract.
A note cannot be spent twice. Each spend publishes a nullifier derived from the spending key and the leaf index; the contract rejects a repeat.
A broadcaster cannot alter what it submits. Recipient, amount and fee are hashed into a single field element the proof commits to, so one changed byte fails verification.
Every historical root is accepted. Roots are kept in a mapping rather than a ring buffer, so a burst of cheap deposits cannot invalidate a proof you are still building.
A full tree never locks funds. Outputs that cannot be inserted are emitted as an event rather than reverting, so withdrawals keep working.
Your balance is recoverable from a seed and chain data alone. No server holds anything needed to find your notes.
50 tests: 30 against the contract, 20 across the client, the broadcaster and an end-to-end run on a local chain. Proof integration tests generate real proofs rather than mocking the verifier.

What's hidden. What isn't.

The pool hides the middle, not the edges. Money entering and leaving is public, and always will be: that is how a pool on a public chain works.

Hidden
Your balance in the pool, and every note that makes it up
Who you pay privately, and how much
Which of the pool's deposits funded a given private send
Stays public
Every deposit: the amount, and the wallet it came from
Every withdrawal: the amount, and the address it lands on
The timing of both, and the broadcaster fee
Known weaknesses

Written down before anyone finds them

Single-party trusted setupThe proving key came from a ceremony with one participant. Whoever ran it could forge proofs. This is disqualifying for real money and is why the pool is testnet-only until a proper ceremony runs.
Amount correlationDeposits and withdrawals are both public. Withdraw what you deposited and the two link by arithmetic. Fixed denominations would fix this and are not built yet.
A small pool hides littlePrivacy comes from the crowd. Today the crowd is small, so timing and amounts link most deposits to most withdrawals. This improves only with users.
GATED

Testnet only. Nothing goes near mainnet until the circuit, the contract and the agreement between them have been independently audited, and until the trusted setup is redone as a multi-party ceremony. Do not put real money in this.

Open the walletBack to home