Does Light Protocol provide transfer privacy?

No. Light Protocol compresses account state to reduce rent and storage cost. A compressed token transfer still has a public sender and a public recipient on-chain — the compression is about how the account is stored, not about hiding who sent what to whom. SolMask's deposit/withdraw cycle is what unlinks sender from recipient.

Does SolMask use state compression?

No. SolMask writes regular Solana accounts. The note commitments live in a Merkle tree the program maintains directly, and the per-asset vault is a regular SPL token account. The two designs solve different problems and have no shared dependency.

Can I use both together?

In principle yes — a future integration could deposit a Light-compressed token into a SolMask pool and withdraw to a fresh address, gaining both rent savings on the source side and unlinkability on the destination side. No such integration ships today. The two protocols target different lifecycle stages: Light optimises storage cost, SolMask optimises the visibility of a transfer.

Which is cheaper to use?

Per-transaction Light is dramatically cheaper for high-volume issuance (the whole point is to skip rent). SolMask deposits are free; the fee is charged on withdrawal — a 23 bps fee in the withdrawn asset plus a flat 0.003 SOL per recipient — which pays for the on-chain Groth16 verifier and the withdraw submission. They're not substitutes; comparing the fees directly is a category error.

Are the underlying ZK proofs the same?

Both use ZK proofs, but for opposite purposes. Light uses validity proofs to attest that a state transition is consistent without re-executing it. SolMask uses a Groth16 membership-and-spend proof to attest that the spender knows a secret committed to the Merkle tree without revealing which leaf. The proof systems and circuits are not interchangeable.

SolMask vs Light Protocol

Transfer privacy vs state compression. Same cryptographic family, different problem.

SolMask and Light Protocol both ship as "ZK on Solana," and that surface-level overlap is usually where the confusion starts. They share a mathematical toolkit — zero-knowledge proofs, Poseidon hashing, Merkle trees — but they solve genuinely different problems and a project can need one, the other, both, or neither. Picking based on a feature checklist will almost always lead you to the wrong answer; picking based on which problem you have will lead you to the right one in about thirty seconds.

This page is structured to make that thirty-second decision easy. The first two sections define what each protocol actually does in technical terms. The third section is a side-by-side table on the dimensions that matter architecturally. The fourth is decision guidance for the common situations. The FAQ at the end addresses the recurring "wait, but…" questions we get.

What each does

SolMask is transfer privacy. A user deposits SOL, USDC, or USDT into a per-asset vault and receives a note — a local secret whose Poseidon commitment is added to the per-asset Merkle tree on-chain. Later, the user (or a delegate) generates a Groth16 proof that attests "I know the secret behind some leaf of this tree, and the following nullifier is its first use," without revealing which leaf. The program verifies the proof, marks the nullifier as spent, and pays out from the vault to the recipient address embedded in the proof's public inputs. The on-chain footprint is a deposit from wallet A and an unrelated withdraw to wallet B, separated by however long the user waited.

Light Protocol is state compression. Solana account rent is non-trivial for high-cardinality state — millions of NFTs, fan tokens, loyalty points, ledger entries. Light moves the canonical state into a Merkle tree off-chain and stores only the tree root on-chain. When a compressed account changes, the prover supplies the new state plus a ZK validity proof showing the transition is consistent with the previous root; the on-chain program verifies the proof and updates the root. The economic benefit is dramatic: storing a million compressed token accounts costs roughly the same on-chain as storing one. The privacy property, however, is unchanged from a regular Solana transfer — the sender, the recipient, and the amount are all in the proven state transition. Anyone replaying the off-chain tree can see exactly who sent what to whom.

Side-by-side

	SolMask	Light Protocol
Purpose	Unlink sender from recipient for SOL/SPL transfers.	Reduce on-chain rent and storage cost for high-cardinality state.
Privacy property	Sender ↔ recipient unlinkability within an anonymity set of co-depositors.	None added. Transfers remain publicly attributable.
Asset coverage	SOL, USDC, USDT today; SPL tokens generally as pools are deployed.	Any compressed account type — tokens, NFTs, arbitrary program state.
Compliance posture	Structural: an on-chain banlist registry blocks deposits from listed wallets at the program boundary.	Same as plain Solana — application layer decides.
Trust model	Trusted setup ceremony for the withdraw circuit; users trust the off-chain note backup they hold.	Trusted indexers serve the off-chain tree; on-chain proof verifies updates.
Setup overhead	Connect wallet, deposit, wait, withdraw. No SDK required for end users.	Application-level integration — projects opt their state model into compression.
Audience	End users moving funds privately; applications wanting unlinkable payouts.	Application developers shipping high-cardinality state cheaply.

When to use which

Use SolMask when the goal is to break the link between a known sender and a recipient. Common cases: paying a contributor whose identity should not be tied to your treasury, moving funds off an exchange-attributed wallet to a fresh wallet for personal use, distributing payouts to recipients whose addresses should not co-cluster with the payer. SolMask does not reduce your storage cost or speed up anything; it changes the on-chain graph.

Use Light Protocol when you are shipping a product whose economics fall over because of per-account rent — a loyalty-points system with a million holders, an NFT collection with per-token state, a ledger with one entry per transaction. Light does not hide any of that data, it just makes it economically feasible to store on-chain. If you also need privacy on those transfers, you would layer SolMask (or a similar transfer-privacy primitive) on top of the user-facing movement, not into the storage substrate.

Use neither when standard Solana accounts suit the workload. Most applications do. Adding either protocol imposes complexity that should be justified by an actual constraint you are hitting — either privacy or storage cost — not added speculatively.

FAQ

Does Light Protocol provide transfer privacy?: No. Light Protocol compresses account state to reduce rent and storage cost. A compressed token transfer still has a public sender and a public recipient on-chain — the compression is about how the account is stored, not about hiding who sent what to whom. SolMask's deposit/withdraw cycle is what unlinks sender from recipient.
Does SolMask use state compression?: No. SolMask writes regular Solana accounts. The note commitments live in a Merkle tree the program maintains directly, and the per-asset vault is a regular SPL token account. The two designs solve different problems and have no shared dependency.
Can I use both together?: In principle yes — a future integration could deposit a Light-compressed token into a SolMask pool and withdraw to a fresh address, gaining both rent savings on the source side and unlinkability on the destination side. No such integration ships today. The two protocols target different lifecycle stages: Light optimises storage cost, SolMask optimises the visibility of a transfer.
Which is cheaper to use?: Per-transaction Light is dramatically cheaper for high-volume issuance (the whole point is to skip rent). SolMask deposits are free; the fee is charged on withdrawal — a 23 bps fee in the withdrawn asset plus a flat 0.003 SOL per recipient — which pays for the on-chain Groth16 verifier and the withdraw submission. They're not substitutes; comparing the fees directly is a category error.
Are the underlying ZK proofs the same?: Both use ZK proofs, but for opposite purposes. Light uses validity proofs to attest that a state transition is consistent without re-executing it. SolMask uses a Groth16 membership-and-spend proof to attest that the spender knows a secret committed to the Merkle tree without revealing which leaf. The proof systems and circuits are not interchangeable.