Shielded Pool
The GoDark shielded pool is the collateral privacy layer for the exchange. It lets users deposit USDC, trade against private collateral commitments, and withdraw through ephemeral recipient addresses without publishing a readable per-user balance or trade history on-chain.
The design gives evaluators two things to inspect:
- Public token custody — real SPL tokens live on Solana in aggregate vault accounts controlled by program-derived authorities.
- Private accounting — user balances and trade state are represented as shielded notes in a compressed commitment tree.
What It Provides
The shielded pool is designed around four goals:
| Goal | What it means |
|---|---|
| Collateral privacy | Deposits become private note commitments before trading. Public observers do not see a per-user balance ledger. |
| Private settlement | Trades update private notes rather than publishing readable price, size, direction, or counterparty data. |
| Programmatic custody controls | Token movement is gated by Solana programs, proof checks, and program-derived authorities rather than operator discretion. |
| Evaluator visibility | Public events and aggregate balances allow third parties to monitor solvency and activity without seeing user-level trading data. |
Mental Model: Public Tokens, Private Notes
There are two ledgers:
- Public Solana ledger — SPL token balances. Public movement happens when funds enter the pool or leave it.
- Private note ledger — opaque commitments and nullifiers. Trading, transfers, and settlement mutate this private state without moving SPL tokens for every match.
When a user deposits USDC into their Dynamic wallet, GoDark automatically shields the collateral for trading. The visible deposit is converted into a private note commitment inside the shielded pool. From that point forward, the trading layer works with commitments, not a readable per-user balance account.
Technologies Used
The shielded-pool stack uses standard privacy and Solana primitives where possible, with custom circuits only where the exchange-specific settlement logic requires them.
| Layer | Technology | How GoDark uses it |
|---|---|---|
| Base chain | Solana | Final settlement, SPL token custody, public transaction ordering, and program execution. |
| Token custody | SPL Token accounts + Program Derived Addresses (PDAs) | Deposited collateral is held in aggregate program-controlled vault accounts rather than operator wallets. |
| Compressed private state | Light Protocol | Stores shielded note leaves and enforces commitment/nullifier uniqueness in compressed state. |
| Note commitments | Poseidon commitments | Represents private collateral notes using hash commitments over note fields such as asset, amount, owner key, and randomness. |
| Nullifiers | Poseidon nullifiers | Marks a private note as spent without revealing the original commitment owner or note contents. |
| ZK proving system | Groth16 over the BN254 scalar field | Verifies shield, transfer, settlement, and ghost-withdrawal transitions with compact on-chain proofs. |
| Circuit families | Shield, transfer, match, and withdraw circuits | Enforce ownership, conservation of value, valid note spends, and valid output creation for each operation type. |
| Private matching | MPC committee using Shamir-style secret sharing | Matches encrypted order flow without any single node seeing the complete orderbook or user order. |
| Batch authorization | Threshold signing | Requires committee quorum approval before settlement batches are submitted on-chain. |
| Withdrawal privacy | Ephemeral recipient addresses | Ghost withdrawals release funds to fresh recipient addresses designed to reduce public linkability to the user's Dynamic wallet. |
The docs intentionally describe these technologies at the integration and invariant level. Circuit source, verifier-key operations, deployment keys, and exploit-specific audit details are not published in public docs.
Fund Flow
| Phase | Public token movement | Private state change |
|---|---|---|
| Deposit | USDC enters the pooled vault from the user's wallet flow. | A one-time deposit authorization is created. |
| Shield | No additional token movement. | A private note commitment is added to the commitment tree. |
| Trade or transfer | No SPL movement. | Existing notes are nullified and new commitments are created. |
| Withdraw | USDC leaves the pooled vault to an ephemeral recipient address. | A private note is consumed by publishing its nullifier. |
This separation is the core privacy property: tokens move publicly at the edges, while the middle of the lifecycle is private-ledger arithmetic.
What Observers Can and Cannot See
| Operation | Publicly observable | Hidden from observers |
|---|---|---|
| Deposit | A token deposit occurred into the pool flow. | The future commitment that deposit becomes after shielding. |
| Shield | An opaque commitment was appended. | Owner, amount, and note randomness. |
| Trade / transfer | Nullifiers and new commitments were emitted. | Trade size, price, direction, ownership, and counterparty mapping. |
| Ghost withdraw | A fresh recipient address receives tokens from the pool. | The user's identity, prior note history, trading path, and source commitment. |
The pool does not claim that public token movements disappear. Deposits and withdrawals still settle on Solana. The privacy guarantee is unlinkability: by default, withdrawals use fresh ephemeral recipient addresses so observers can see that funds left the aggregate pool, but should not be able to trace that output back to the user's Dynamic wallet, prior note history, trading path, or counterparties.
Conservation and Solvency
For each supported mint, the pool is built around a simple solvency invariant:
Aggregate SPL in the pooled vault equals the sum of all unspent private notes for that mint.
The system enforces this through layered checks:
- No shield without deposit — a deposit authorization can be consumed only once.
- No double-spend — spending a note publishes a nullifier; the same nullifier cannot be inserted twice.
- No duplicate output note — output commitments must be unique in the compressed state layer.
- No wrong-recipient release — withdrawals bind the released tokens to the ephemeral recipient proven by the withdrawal flow.
- No trade-side token movement — matching changes private note state; it does not move SPL tokens per fill.
Third-party evaluators can reason about the public aggregate vault balance, emitted commitment/nullifier events, and the private-note accounting model without needing access to user-level trading data.
Security Controls
The shielded pool uses defence in depth rather than relying on a single control:
| Layer | Purpose |
|---|---|
| Proof verification | State transitions require proof-backed ownership, arithmetic, and conservation checks. |
| Commitment and nullifier uniqueness | The compressed state layer prevents duplicate commitments and repeated spends. |
| Program-bound custody | Vault release paths are bound to the shielded-pool program and PDA-signed authorities. |
| Circuit and version binding | Proofs are scoped to a specific operation type and protocol version. |
| Operational kill switches | Deposits, withdrawals, transfers, matching, and sponsored withdrawals can be paused independently. |
| Monitoring and event hygiene | Public events are minimized, and monitoring tracks pool health, activity, and anonymity-set conditions. |
These controls are deliberately independent. A failure in one layer should not silently bypass custody, proof validity, uniqueness, and operational response controls at the same time.
Audit and Operational Posture
GoDark has run an internal shielded-pool security review covering proof flow, custody boundaries, event privacy, operational controls, and off-chain logging. The highest-risk remediation work has been prioritized around fund safety, privacy leakage, and production-deployment guardrails.
Public-facing posture:
- Security-sensitive controls are staged through testnet validation before production rollout.
- Operational authorities are designed to move toward multisig and timelocked governance.
- Public events are intentionally minimal so indexers can monitor pool state without reconstructing user graphs.
- Future cryptographic upgrades are planned as coordinated migrations rather than piecemeal changes that could split verifier, circuit, and state assumptions.
Disclosure Boundary
This page intentionally describes the model, invariants, and trust boundaries without publishing every internal implementation detail. GoDark does not expose full exploit narratives, deployment keys, verifier-key operational procedures, or low-level circuit internals in public docs.
For adjacent context, see Deposit Funds, Settlement, Privacy & Encryption, and MPC Committee Architecture.