How ZLAB is built, and how far it actually is
This page is the reference the rest of the site defers to. It covers the architecture, the trust assumptions, the privacy model, the fee schedule, the proof strategy, and a component-by-component statement of what is live today.
The shield boundary
Left of the boundary, five entry flows are individually distinguishable — different lane, different label, different cadence. That is public Solana activity, and it is what an observer sees today. At the boundary the lanes converge and identity is destroyed: past it every strand is the same colour and the same width, and lane order is permuted, so which output came from which input cannot be read off the picture.
The right-hand side is drawn hatched because that property is not implemented. The diagram shows the objective; it does not imply the objective has been reached.
Implementation status
Fourteen components, each with its real state. The same data drives every status chip in this application and is served as JSON at /api/status.
| Component | Status | What is actually true | What would change it |
|---|---|---|---|
| Wallet connection | Devnet | Wallet Standard discovery, connect, disconnect, and a genesis-hash check that the RPC really serves the cluster it claims. No signature is requested until that check passes. | Already working |
| SOL balance and network reads | Devnet | Live reads against the configured cluster RPC, with real error states when the endpoint is unreachable. | NEXT_PUBLIC_SOLANA_RPC_URL |
| Zcash address validation | Live | Genuine Bech32 and Bech32m decoding with checksum verification, Sapling payload-length checks, transparent-address rejection and network-mismatch detection. Verified against the BIP-173 and BIP-350 test vectors. | Already working |
| Token listings, charts, trades, holders | Beta | The full catalogue with server-side filtering, sorting, search and pagination, plus OHLCV, trade flow and holder tables on every token. | INDEXER_URL, INDEXER_KEY |
| SOL → ZEC routing | Beta | A typed quote contract with expiry, per-hop route disclosure and a fee breakdown. Routing goes live once a provider has passed a published custody and timing-correlation review. | CONVERSION_PROVIDER_URL, CONVERSION_PROVIDER_KEY |
| Trading | Live | Live swaps on Solana mainnet, routed through the Jupiter aggregator. Real quotes with route and price-impact disclosure, a wallet-signed transaction, on-chain submission and confirmation polling with a real signature at the end. Quotes expire at 25 seconds and are refused rather than executed stale. | Already working |
| Token creation | Beta | The full launch flow is built: schema-validated configuration, browser-side image sniffing and re-encoding, immutable fee-split preview and a cost estimate from real Solana rent minimums. Minting opens with the mainnet program. | NEXT_PUBLIC_LAUNCHPAD_PROGRAM_ID + a deployed program |
| Rewards accounting | Beta | Time-weighted eligibility and exact-sum epoch splitting in integer zatoshi, both deterministic. Accrual is tracked per token and per holder today. | INDEXER_URL |
| Shielded ZEC payouts | Beta | Rewards accrue now; claims open with the payout rail. Spending authority lives in a separate minimally-scoped signer service — placing a Zcash spending key in a web application would be indefensible. | ZLAB_SETTLEMENT_SIGNER_URL + a signer service |
| Proof of total distribution | Beta | Epochs carry a commitment hash only. A commitment lets a later disclosure be checked; it does not demonstrate the distribution followed the published rule. | Circuit design and implementation |
| Confidential balances | Beta | Specified as a commitment-based note model. Zcash mainnet has no native custom shielded assets, so this needs either a protocol change or a separate proving system anchored to Zcash. Today a launched token is a standard SPL token with public balances. | Protocol research track |
| Private order submission | Beta | Open research problem. Encrypting an order is easy; preventing a sequencer, relayer or timing observer from reconstructing it is not. | Protocol research track |
| Settlement proofs | Beta | Circuit design in progress for a batch-auction settlement proof including the fee split. Proving cost and latency are the binding constraints. | Protocol research track |
| Security audit | Beta | No audit has been performed yet. ZLAB is not audited and this interface does not claim otherwise anywhere. | An audit engagement before mainnet |
Six layers, one contract each
Every dependency sits behind a typed interface with a declared status. Swap an implementation, keep the stack. This is the whole surface area.
Solana entry adapter
Connect any Wallet Standard wallet and trade on mainnet in two clicks.
Wallet connection, network verification, and mainnet swap execution.
- Standard
- Wallet Standard
- Cluster check
- getGenesisHash
- Token programs
- SPL + Token-2022
- Router
- Jupiter aggregator
- Signing
- Client-side only
Delivers
- Wallet Standard connection (Phantom, Solflare, Backpack and any compliant wallet)
- Cluster identity check via getGenesisHash before any signature is requested
- Live SOL and SPL balance reads, across both the legacy and Token-2022 programs
- Wallet-signed mainnet swaps with on-chain confirmation
- Explorer links for every address and signature shown
Shipping
- Hardware-wallet clear signing, so the device renders the swap rather than a blob
- Self-hosted RPC by default, removing the last third party from the read path
- Priority-fee tuning driven by live network congestion
interface SolanaEntry {
verifyNetwork(): Promise<NetworkCheck>
getSolBalance(addr: string): Promise<number>
getTokenBalance(owner, mint): Promise<number>
}Configured by
- NEXT_PUBLIC_SOLANA_CLUSTER
- NEXT_PUBLIC_SOLANA_RPC_URL
Privacy model
ZLAB is designed around one asymmetry: market rules should be public so that anyone can verify them, and individual positions should not be so that participating does not publish your finances.
Today only half of that exists. Zcash provides genuine shielded value transfer, available now. What does not yet exist is a shielded representation of a launched token: Zcash mainnet has no native custom shielded assets, and saying otherwise would be the one dishonesty this project cannot afford.
So a token launched through ZLAB today is a standard SPL token with public balances. Routing SOL through Zcash on the way in does not change that, and no amount of front-end design can. What is real today is the reward side: fees accrue in ZEC and settle in the shielded pool.
End-to-end private participation is the protocol objective, and it is stated as an objective everywhere in this interface. The components below are what stand between here and there.
- Confidential balancesspecified
Must guarantee: A holder position must be readable by its owner and by nobody else, while remaining provably within total supply.
Commitment-based note model with an append-only note tree, in the shape Zcash already uses for value. The open question is not the primitive but where the tree lives: Zcash mainnet has no native custom shielded asset, so this needs either a ZSA-style protocol change or a separate proving system anchored to Zcash.
- Private order submissionopen problem
Must guarantee: Order size and direction must not be inferable before, during, or after execution.
Encrypting an order is easy. Preventing the sequencer, the relayer, or an observer of timing and gas patterns from reconstructing it is not. Any honest design here includes batching with a fixed cadence and a decoy policy, both of which cost latency.
- Settlement proofsresearching
Must guarantee: Anyone must be able to verify that a batch settled according to published market rules, without learning any participant position.
Circuit design for a batch-auction settlement proof, including the fee split. Cost and proving time are the binding constraints, not feasibility.
- Nullifier setspecified
Must guarantee: A note must be spendable exactly once, without revealing which note was spent.
Standard construction. The engineering risk is operational: nullifier-set growth, and the availability requirements on whoever serves it.
- Metadata resistanceopen problem
Must guarantee: Network-level observation of ZLAB clients must not deanonymise participants.
The front end is the weakest link. IP addresses, request timing, and RPC provider logs can defeat on-chain privacy entirely. Mitigations exist (self-hosted RPC, Tor, client-side filtering) but none are default-on today.
Fee schedule
Every fee is a fixed share of trade value, chosen from a published menu at launch and immutable afterwards. There are no hidden spreads, no dynamic fees and no fee the creator can raise later.
0.50%
Same for every token. Funds protocol development.
Recipient
Not configured in this build. A deployment must set NEXT_PUBLIC_FEE_RECIPIENT so the address is inspectable before anyone trades.
0 – 1%
Routed to holders, paid as shielded ZEC on a published cadence, weighted by time held.
- 0.00%
- 0.25%
- 0.50%
- 0.75%
- 1.00%
0 – 1.50%
Paid to the launching address. Also immutable.
- 0%
- 0.50%
- 1%
- 1.50%
Trust assumptions
Who you have to trust, and for what. A privacy protocol that will not enumerate this is asking you to trust it blindly.
You trust the front end you are reading
highA compromised or substituted front end can show you one destination and ask your wallet to sign another. This is the single most likely attack on any application of this shape. Always read the instructions your wallet shows you, not the ones this page shows you.
You trust the RPC endpoint
mediumAn RPC provider sees your IP address, your queries and the timing of both. On-chain privacy does not survive an RPC that logs everything. ZLAB verifies the cluster by genesis hash but cannot verify the operator. Self-host it if the privacy matters.
You would trust the conversion provider
highAny SOL→ZEC route means somebody holds value in between. That party can steal it, be compelled to freeze it, or log the correlation between your Solana address and your Zcash address. No provider is configured here, and none will be adopted without publishing this analysis for that specific provider.
You would trust the payout signer
highShielded payouts require a service with Zcash spending authority. That service is a custody risk and a correlation risk — it necessarily learns which addresses receive what.
You trust Solana and Zcash themselves
mediumConsensus failure, chain halts and validator censorship on either chain are outside anything ZLAB can mitigate.
You do not have to trust the market rules
mediumThis is the one place the design removes trust rather than adding it: curve parameters and the fee split are committed at launch and immutable. The long-term goal is that settlement proofs make the accounting checkable without trusting the operator either.
- Solana cluster
- mainnet-betaDevnet
- Launchpad program
- Not deployedBeta
- Fee recipient
- Not configuredBeta
- Zcash settlement
- No signer configuredBeta
- Private market contracts
- NoneBeta
- Build
- localLive
ZLAB has not been audited.
No contract has been reviewed, because no contract has been deployed. No front-end review has been performed. This interface does not display an audit badge anywhere, and it will not until a real engagement has produced a real report at a resolvable URL.
The parts that are testable are tested: the Bech32 and Bech32m implementation is checked against the BIP-173 and BIP-350 vectors, and the reward-splitting maths is deterministic and sums exactly. Neither of those is an audit.
The full document covers wallet compromise, bridge custody, relayers, MEV, metadata leakage, timing correlation, reward claims and front-end compromise, with mitigations and residual risk for each.
- Front-end compromise
- Wallet compromise and blind signing
- Bridge and conversion custody
- Relayer and sequencer trust
- MEV and ordering
- Metadata and network-level leakage
- Timing correlation across chains
- Reward claim linkability
docs/THREAT_MODEL.md in the repository