A note the chain cannot read.

Note model

Each balance is a note. The note commits to an amount, an asset id, the owner’s public key, and a random blinding value. The commitment goes into a Poseidon tree. When the note is spent, the transaction reveals a nullifier derived from the note and its position. The nullifier prevents a second spend. It does not point at the commitment.

commitment = Poseidon(amount, asset id, public key, blinding)
public key = Poseidon(private key)
nullifier  = Poseidon(commitment, position, Poseidon(private key, commitment, position))

Both pools share this circuit. The Solana program accepts SOL and listed tokens on the original SPL Token program. The Ethereum and Base contract accepts ETH and listed ERC-20 tokens. One asset moves per transaction. Up to two notes come in, and two notes go out.

The tree only grows. Depth 26 gives 67,108,864 slots in each pool, shared by every asset in that pool. A shield and a spend each use two slots, so a pool holds about 33.5 million of those operations. When the tree is full, deposits stop. Withdrawals of whole notes still work. The contract accepts a recent window of roots: the last 1,000 on Ethereum and Base, and the last 256 on Solana.

Shield

Shielding is the honest edge of the system. You deposit from a normal wallet. The chain records the asset, the amount, and the wallet that paid. Every shield from that wallet can be associated with it. The pool’s contribution at this step is forward privacy of the note itself: a one-time key means later notes are not linked together merely because they share a key.

Each asset keeps its own books. One asset cannot be used to pay a withdrawal of another. Deposits have a minimum, a maximum, and a cap on how much of that asset the pool may hold. An admin can turn deposits off for an asset, or pause all new deposits inside a window whose end date is fixed at deployment. An accepted deposit cannot be frozen, reversed, or revoked by the pool.

Private send

A private send is the step that needs a proof. Your browser builds a Groth16 proof with snarkjs over the circom circuit, on the BN254 curve. The proof shows that the notes you spend are in the tree, that you know the key, that the nullifiers are correct, and that the new notes conserve value for that asset. It does not reveal which notes, how much, or which asset.

Proving took 2 to 5 seconds in tests on a 2-core machine. A phone or an older laptop can take longer. The current design has one relayer, which submits these transactions without adding its own fee, inside a rate limit. If that relayer is unavailable, the send still belongs to you — you need a client and a way to submit.

Nothing in this step crosses to NEAR, and nothing in it is the confidential routing DarkSwap requests from NEAR Intents. Confidential routing hides processing inside a provider boundary. A private send is a proof.

Unshield

Unshielding pays a public address. The withdrawal is visible. The relayer can submit it so the destination does not need gas for that transaction. For a token, the relayer only does this when it has a price. Otherwise you submit from your own wallet, which pays the gas and is recorded as the sender.

The relayer’s fee is taken from the withdrawal. It is not the protocol fee. The protocol fee, in tests, is charged on shield and on unshield only.

Keys

The spending key is derived from one secret. That secret can come from a wallet signature over a fixed message, or from a 24-word restore. After you unlock, the page holds the key in memory. It is not written to storage. It is dropped when you lock, or after 30 minutes idle.

While the key is in memory, the page can spend your notes. A compromised page, or a look-alike domain that obtains the signature or the words, can spend them too. Check the address before you sign. A standalone recovery client is part of the design and is not built yet. If the site is down, the contracts can still be used by anyone who has the words, a client, and gas.

Fees

In tests the protocol fee is 0.5% when you shield and 0.5% when you unshield. Private sends are free of that fee. An admin can change the rate. The contract refuses a rate above 1%. The admin cannot change the fee recipient.

Fees never sit inside a note and never make an existing note worth more. They accumulate in the pool. Anyone can sweep them, and the sweep can pay only the recipient fixed when the pool was deployed. Because that address cannot be changed later, it has to be the right contract before deployment. Contracts that would forward those fees onward are proposed, not written.

ZKDARK is the Solana token. Swap it on PumpSwap. The Solana chart is on DexScreener. It is not DarkSwap’s $DARK token, and a balance of either ticker is not a claim on these fees.

Trust

For what happens inside the pool, you do not trust ZK Darkpool to keep a balance honest. You trust the proof, the circuit, and the keys produced by the ceremony. You do trust operators for everything around that proof.

Two internal reviews, one of the circuit and one of the pools, reported no path to steal, mint, double-spend, or redirect a payout. The pool review found two ways to freeze funds. Both were fixed, and each fix has a test. That is not an independent audit, and the source is not published yet. Parts of the implementation build on GPL-3.0 code, so the licence has to be decided before release.

The reference lists capacities, admin powers, and the gates in front of mainnet. The design source is DarkSwap whitepaper v0.4.