Use cases

Paraloom is a privacy primitive — shielded SOL transfers + private WASM compute settled on Solana. This page is a sober look at what that primitive enables, what it doesn't, and what the gap looks like between "the primitive supports it" and "you can run it on mainnet today."

Reality check. The privacy layer is working on devnet. Compute is alpha. SPL tokens, NFTs, DEX integrations, cross-chain — none of those are built into paraloom-core today. Where this page mentions them, it's about what becomes possible on top of paraloom, not what ships out of the box.

What's actually shipped

Everything below assumes those primitives are wired through to whatever app sits on top.

Use cases that fit the primitive today

Private SOL payments

The most direct use of the privacy layer. Concrete shape:

• A sender deposits SOL into the shielded pool from a public wallet.
• A recipient receives a shielded note (out-of-band — e.g., encrypted message).
• The recipient withdraws to any Solana address they control.

What this gets you: on-chain unlinkability between sender deposit and recipient withdrawal. What it does not get you: hiding the fact that some sender deposited and some recipient withdrew. Privacy at the boundary is necessarily public.

Suitable for: payroll, vendor payments, donations, anything where the parties are known to each other but their relationship shouldn't be public.

paraloom wallet deposit  --amount 1   --note ./alice.note --network devnet
# share recipient address out-of-band
paraloom wallet transfer --amount 0.4 --recipient <bob-shielded-pk> --note ./alice.note
paraloom wallet withdraw --amount 0.4 --recipient <bob-public-sol>  --note ./bob.note

Confidential compute (alpha)

Run a WASM program on encrypted inputs, with BFT agreement on the output hash, and an AES-encrypted result delivered only to the requester.

Concrete fit: aggregations over private inputs where each contributor wants their input hidden but the aggregate result revealed (or revealed only to a designated party). Examples that map cleanly:

• Privacy-preserving polls or voting tallies (each ballot is a private input)
• Cross-party benchmark computations (each party contributes encrypted metrics; aggregate revealed)
• Confidential auditing (auditor learns the answer; the auditee's raw data isn't exposed)

What's missing: output-notes that re-enter the shielded pool. Until that lands, results land at the requester only — fine for many use cases, but a gap for compositional flows.

Use cases that the primitive enables but doesn't ship

These need application-layer work on top of paraloom-core. They're plausible because the privacy primitive supports them, not because they exist today.

Private DEX trade settlement

The pattern: a user deposits to the shielded pool, signals an intent (privately), and a separate component routes the swap on public Solana DEXs and returns the proceeds via a shielded withdrawal.

What needs to be built: an intent-mediation component that translates shielded intents into public DEX transactions without leaking the link. This is non-trivial — front-running resistance depends on the intent layer, not the privacy layer.

Status in paraloom-core today: the privacy primitive is sufficient; the intent layer is not built.

Stealth token launches

A launch where dev allocation, buyer addresses, and purchase amounts aren't publicly visible. The privacy layer can hold positions; the launch contract logic (bonding curve, distribution rules, vesting) is application-layer.

What needs to be built: a launch contract that uses paraloom's primitives instead of public on-chain accounting. Possible; not shipped.

Private NFT ownership

Same shape as private SOL — but with NFT semantics on top of the shielded pool. Requires SPL/NFT support in the privacy layer (currently SOL-only). Not shipped.

Confidential DAO operations

Treasury allocations, grant disbursement, strategic purchases held privately. The privacy primitive supports the cash-flow side; on-chain governance integration is application-layer.

Use cases that don't fit the primitive

Stating these honestly so nobody builds against the wrong thing:

Truly anonymous identity / "no link to me at all"

Privacy ≠ anonymity. Paraloom hides on-chain links between deposits and withdrawals. It does not hide:

• Network-level metadata (IPs, timing) — use Tor / VPN if that matters
• Off-chain correlations (KYC at exchanges before deposit, etc.)
• Statistical fingerprints (unique amounts, unusual timing patterns)

If your threat model includes a global passive adversary correlating off-chain identity, paraloom is one tool among several — not a complete solution.

Hiding the existence of activity

The shielded pool reveals that some deposits and some withdrawals are happening — that's part of how the BFT cohort works. Hiding the existence of activity is a different (much harder) problem.

Compliance-friendly out of the box

Regulatory requirements vary; paraloom doesn't ship view-keys, viewing keys, or selective disclosure today. If your use case requires showing a regulator what happened, the primitives to build that exist (proofs of ownership, ceremony transcripts), but they're not pre-wired.

What to read next

• Privacy layer — what's hidden and what isn't, in detail
• Compute layer — alpha status, what's wired and what's pending
• Vision — the longer arc: where this primitive is heading
• Developer guide — what you can build today, given the missing SDK

If you're considering building on top of paraloom and aren't sure whether the primitive fits your case, the fastest way to find out is to model it in a single sentence: "The on-chain link between [X] and [Y] should be hidden; [Z] can be public." If that sentence is true and Z covers everything else you need, paraloom fits. If Z keeps growing, you might need a different tool.