Shielded pool on Groth16 proofs
A deposit becomes a commitment; a withdrawal proves ownership of some commitment without revealing which one. The link between sender and receiver is gone.
Engineering · built by the Foothold AI Collective
Stablecoin payments where the amount is hidden, the chain cannot link sender to receiver, and the sender decides who may see the details. I grant access, not permission.
tidex6 is an open-source framework, written in Rust, that adds privacy to stablecoin payments. Transactions are private by default: the amount is sealed, and nothing on chain connects the sender to the receiver.
Privacy here is not secrecy from everyone. The sender can hand a viewing key to someone they trust, such as an accountant, an auditor or a family member. They can read the history, but they cannot spend or freeze anything. That is disclosure by consent, and it is what makes private payments usable by businesses that answer to auditors. The Foothold AI Collective built it the same way we build everything: Rust end to end, cryptography that can be checked, every claim verifiable on chain.
A deposit becomes a commitment; a withdrawal proves ownership of some commitment without revealing which one. The link between sender and receiver is gone.
On Solana mainnet the wUSDC and wUSDT pools keep payment amounts confidential inside the pool with Token-2022 Confidential Transfers. The next pool version, on USDG, runs on devnet.
The recipient is never handed a note. They find payments meant for them by scanning the chain with their own secret.
Payment details travel in an ML-KEM-768 encrypted envelope, readable only by the people the sender chooses: the recipient and, optionally, an auditor.
The proof is generated in the user's tab through WebAssembly in about two seconds on a typical machine. The secret never leaves the device.
The same circuit and verifying key run on Solana, on EVM chains through a Solidity verifier, and on Arc, Circle's chain, where gas is paid in USDC.
An MCP server lets AI agents send and receive private payments through the same rails.
The bytecode of the verifier program on Solana matches its source code, confirmed on verify.osec.io.
Its upgrade authority has been renounced, so nobody, including us, can change it.
Every spent note leaves a per-nullifier record on chain; the same note cannot be spent twice.
The recipient is bound into the proof, so a copied withdrawal cannot redirect the funds.
Anyone with a wallet can contribute in the browser, one contribution per wallet, and the randomness never leaves the tab. The transcript is publicly verifiable. The verifying key currently on chain comes from a single-contributor development setup; it is replaced when the public ceremony closes.
Status: development stage. tidex6 has not yet been independently audited, and we do not recommend it for real funds.
Zero-knowledge circuits, on-chain verifiers and confidential token flows fail in ways ordinary tests do not catch: a missing constraint, a verifier that accepts more than it should, a public input nobody checks. We know these failure modes because we design around them in our own system. This is the kind of system our security team reviews.
The web app.
The public trusted-setup ceremony and its transcript.
On GitHub, under MIT or Apache-2.0.
CSDD31Zm…V7jrsJhcdAYTRKmF8…FMhcPcUQGPYpwyM…53VCWPz2
Give Atlant a task
Building something with zero-knowledge proofs or confidential tokens?
Get it reviewed →