A non-custodial suite for trading and privacy-oriented transfer on Solana.

Wallet control, routed execution and portfolio records, with a privacy pool between them. Every privacy claim Helix makes is conditional, specific to a mechanism, and explicit about what it does not cover. It starts with the fact that trading at a public venue is visible whether or not you shield around it.

How value moves What shielding does not do Client portal

The Helix dashboard in the prototype: total portfolio across all wallets, with Spot, Perpetuals, Shielded and Wallets summaries beneath. Figures are illustrative.

Prototype · illustrative figures · nothing shown is live

Design decisions: 18 of 18 recorded and settled
Deployment chain: Solana
Pool asset at first release: USDC only one pool
Proof system: Groth16 ceremony still to run

The suite

How the suite fits together

Each part is a function of the same suite, not a separate brand. They share one wallet layer, one policy surface and one set of records, so the boundaries between them are defined rather than assumed.

[ 01. ] Segment

Wallets that carry their own provenance

Wallets

Owned, burner and watched wallets, each carrying its provenance. Keys are generated on the device and are never held by Helix.

Core

The Wallets view in the prototype: owned, burner and watched wallets with a linkage warning. Figures are illustrative.

A fresh withdrawal set of three unfunded destination wallets, role: privacy exit, provenance: shielded-origin.

[ 02. ] Shield

Move value through the pool, and see what an observer sees

Shielded Transfer

The privacy-oriented workflow for moving value into and out of a Helix privacy pool. The pool is the mechanism underneath; Shielded Transfer is the workflow above it.

Core

The Shielded Transfer view in the prototype: the six-stage path with what an observer sees at each stage. Figures are illustrative.

Plausible-source estimate: the number of deposits that could account for the selected amount, and how an exact-balance withdrawal would narrow it.

[ 03. ] Trade

Routed execution, with the venue named on every order

Spot

Routed spot execution on Solana, with route quality, price impact and fee components shown separately rather than blended into one number.

Core

Perpetuals

Venue-routed derivatives. Helix does not operate a perpetuals venue; it routes to third-party venues and names which one carried each order.

Core

OTC

Request-for-quote execution away from the public order book. It reduces public order-book footprint and reveals intent to the dealers quoted.

Core

The Spot view in the prototype: market context, execution route and a spot ticket. Figures are illustrative.

A spot ticket: side, pay asset, source wallet context, amount, expected receive and maximum slippage.

[ 04. ] Observe

Signals, watched wallets and records that say where basis breaks

Discovery & Tracking

Asset signals and wallet observation. Signals are heuristics for research, and are never a safety certification for an asset.

Supporting

Portfolio & Records

Position, cost-basis and export records segmented by wallet. Shielded transfer deliberately breaks basis continuity, and the records say where.

Supporting

Yield

Deferred. A yield layer is not part of the baseline build and is not offered. It is listed here so that its absence is explicit.

Deferred

The Tracking view in the prototype: watched wallets and what each watch reports. Figures are illustrative.

A row of discovery cards with signal scores and stage labels.

Prototype · illustrative figures · nothing shown is live

How it works

The whole path, and what is visible at each stage

The privacy pool sits in the middle of a longer sequence. Everything before it and everything after it is ordinary, visible on-chain activity. The table below sets out each stage and what is visible at it.

Fund external wallet → Wallet A

USDC arrives from a wallet or exchange you already use. Helix reads the address and asks that wallet to sign; it never holds the key.

An observer sees Everything. The source, the amount, the time, and that Wallet A belongs to whoever controls the source.

Shield Wallet A → pool

Wallet A deposits into the pool. A commitment is written on-chain; the note that lets you spend it is created on your device and stays there.

An observer sees That Wallet A deposited, and how much. Not where the value will go afterwards.

Wait readiness window

Deposits accumulate behind yours. Helix does not describe a position as ready before the set of deposits it could plausibly have come from is worth entering.

An observer sees Pool growth. This stage is where most of the privacy is actually earned, and it is the stage users most want to skip.

Withdraw pool → Wallet B

A proof generated on your device spends the note to a fresh wallet. A relayer submits the transaction, so Wallet B needs no prior funding of its own. The withdrawal also grants it a small, fixed amount of SOL so it can transact afterwards.

An observer sees That some deposit was spent to Wallet B. The pool is designed to make identifying which one expensive.

Trade Wallet B → venue

Wallet B funds a trading venue. The trading itself is ordinary trading, conducted at a third-party venue under that venue's own rules.

An observer sees Every trade, in full, attributable to Wallet B. A venue is transparent regardless of how the wallet funding it was created.

Re-shield venue → pool → Wallet C

Proceeds return to the pool and later exit to a third wallet, separating the trading history from where the value comes to rest.

An observer sees A deposit from Wallet B, and later a withdrawal to Wallet C. Not that the two are the same person.

Four behaviours undo this. Withdrawing a round number, or the exact amount you deposited, narrows the candidate set to a handful. Withdrawing minutes after depositing narrows it further. Sending Wallet B and Wallet C to the same place later re-links them. And funding Wallet B directly from Wallet A at any point collapses the whole path. The product warns about each of these before you commit. It cannot prevent them.

The boundary

Shielding does not make trading private

The flow sounds as though it wraps the trading. It does not. Trading happens at a public venue and is attributable there, whether you shield before it, after it, or both. What shielding conceals is which deposit a withdrawal came from. That is a narrower and more useful claim than the one people expect.

We state this because the broader claim would be inaccurate. The scope of every other claim on this site is set out on the same basis.

What Helix claims

Reduced direct linkage between the wallet that funded value and the wallet that later holds or trades it.
Withdrawal to a fresh wallet without that wallet needing to be funded from a linked source first.
Amounts inside the pool are concealed while value remains in it.
Keys and proving material stay on your device, because there is no server that could hold them.
Every claim above is conditional on timing, destination reuse and your own downstream behaviour.

What Helix does not claim

That your trading is private. It is recorded per address at the venue and is attributable.
That a withdrawal cannot be linked to a deposit. A pool raises the cost of that inference; it does not eliminate it.
That network-level metadata is concealed by the pool. Routing and submission are separate problems handled separately.
That any flow, user or withdrawal is compliant. Helix supports compliance-compatible controls where an environment provides them; that is a different statement.
That deleting the application removes anything from a public chain. It does not.

Execution

Helix operates the transfer and routes the trading

Helix runs the privacy pool and the client. It does not run a trading venue. Orders go to third-party venues, and the venue that carried an order is named wherever that order appears. Each venue is listed below with the property that matters most: whether it can be funded from the pool without leaving Solana, and what it can see.

Venues Helix routes to, what each is used for, whether it sits on the shielded funding path, and what it records
Venue	Used for	Shielded funding path	What the venue records
Jupiter	Spot routing on Solana	On path	Every swap, per address, publicly and permanently.
Aster	Perpetuals	On path	Every order and position, attributable to the trading account.
Hyperliquid	Perpetuals	Off path	Every order and position. It settles outside Solana, so it is funded transparently from a linked wallet and no privacy claim attaches to it at all.

“On path” is not a privacy claim about the venue. It means only that the venue can be funded from the pool without the value leaving Solana first. The venue still sees your orders, your sizes and your timing in full, and records them against the address that traded. Helix holds order-placement authority at these venues and never withdrawal authority, so a compromised venue key can lose money through bad trades but cannot move funds off the account.

Where this stands

Nothing is deployed yet

Helix is in specification and review. The design decisions below are settled and recorded. The code that would implement them is not written, not audited and not deployed, and this site will say so until each of those changes.

The reason to publish at this stage is that the commitments on the trust and recovery pages are only worth anything if they are made before there is money at stake.

Design decisions: 18 of 18 recorded and settled
Deployment chain: Solana
Pool asset at first release: USDC only, one pool
Proof system: Groth16, with a circuit-specific ceremony still to run
Specifications: Eight published as drafts, pending cryptographic and security review
Independent security review: Not started
Trusted-setup ceremony: Not run
Protocol deployment: None. No addresses exist to publish
Independent-recovery test: Not yet performed

A first release will open with a deliberately low exposure cap that rises on a fixed schedule, because an unreviewed deployment holding a large balance is a worse failure than a small one. The schedule is set in the program at deployment and cannot be raised by anyone afterwards.

“An exit path documented only on a site we operate is not an exit path.” Helix Exit Path Specification · HXS-SPC-007 §7

What we publish, and why now The trust model