A guide to Darkpool.

Start here

Availability, the privacy model and your first steps.

Darkpool is an Ethereum privacy wallet in prelaunch. The software has local and fork-test coverage; public deposits and transfers are not open. Begin with verified launch status, then read the privacy boundaries before using a future deployment.

1. Check the official domain and published release status.
2. Understand the difference between your public Ethereum wallet and shielded notes.
3. Read the recovery guide and prepare an offline seed backup.
4. When a verified deployment is available, follow its supported-network and custody-limit instructions.

Shield, send & withdraw

Understand the three core movements of a shielded balance.

Shield

A public deposit creates encrypted notes in the pool. Your depositing address, asset, amount and transaction time are visible. Supported assets and custody caps depend on the actual deployment.

Send privately

A Darkpool receive address begins with dp1. It identifies the receiving keys used for encrypted notes; it is not a regular Ethereum address. Check the destination before generating a proof. Private note ownership and transfer amounts are hidden by the design, while pool activity, fees and timing remain observable.

Withdraw

A withdrawal pays an ordinary Ethereum address. The recipient and amount become public. Relayed submission can pay gas from the supported quoted flow. Direct submission needs a gas-funded wallet and exposes that submitter.

Before signing, review the asset, amount, destination, fees and submission method. After submission, use the transaction journal to reconcile the existing operation rather than creating a different one merely because a request timed out.

Keys, backups & recovery

Restore access and understand what an encrypted backup preserves.

The seed is the spending authority

Your 24-word seed derives the wallet’s keys and fresh trading wallets. Keep it offline. A support agent, relayer or website form never needs it. A lost seed cannot be reset by a project administrator.

Keep an encrypted backup

An encrypted export preserves wallet state and local records in addition to the seed. Keep the backup password separately and verify your recovery process in a safe environment before relying on it. Browser storage is not a durable backup.

When services are unavailable

Recovery needs the correct network, chain history, deployment information and proof artifacts. The design retains direct submission for supported pool exits if the relay cannot be used. Direct actions require gas and reveal the submitting wallet. A working seed does not make a malicious recovery interface safe.

Payments & invoices

Payment requests, receipts, batches and scheduled workflows.

These modules are in testing. They are not activated simply because the interface or a local test exists.

Request and review a payment

Invoice links and QR codes encode payment details. Check the network, pool, token, amount, recipient and expiry. A checksum can detect accidental changes; it does not authenticate the merchant. Link holders can read the request.

Reconcile locally

The invoice book and matching workflow are local to the wallet. Review the received note and payment evidence before marking an invoice paid. Keep encrypted backups of important records.

Pay a group

Batch payouts accept reviewed recipient lists. Public funding exposes the group funding amount; larger jobs can require multiple atomic bundles. Public holder opt-ins associate a wallet with its submitted receiving address.

Schedule a withdrawal

A schedule is a submission workflow, not an unconditional guarantee of execution at a precise time. Network state, available notes, quote validity and recent-root validity matter. Hosted storage and restart handling need release verification.

Fresh wallets & trading

How a shielded balance connects to public market activity.

Ghost Buy

The implemented flow uses shielded ETH to fund a Stockereum purchase and sends the acquired token to a fresh wallet derived from your seed. The fresh wallet, token balance and trade are public.

Ghost Sell

The implemented flow uses sponsored delegated execution to sell from that wallet and re-shield the guaranteed proceeds. Better-than-minimum execution can leave recoverable surplus. Sponsored gas is not a promise of hidden network metadata.

Shielded swaps

The swap implementation returns the quoted output to notes. The public market leg can reveal asset, pool, amount, fee and timing. Review the exact quote and supported route, and do not interpret “shielded” as a confidential market execution.

Selective disclosure

Choose the narrowest useful scope when sharing private records.

Viewing exports and receipts are designed to disclose information without transferring spending authority. They remain sensitive files.

• All-pools viewing key: can reveal existing and future notes across pools and networks using the same receive key. It cannot be restricted by changing a label in the file.
• Pool snapshot: discloses selected observed notes at a checkpoint and can follow their later spends. It does not decrypt new notes that were not included.
• One-payment receipt: shares a narrower payment record with its verification material. A public signature can identify its signer.

Shared copies cannot be revoked. A viewing file can omit notes or contain incomplete history; it is not automatically proof of a complete balance or accounting record. Start with the smallest scope that meets your purpose.

Privacy & observable data

Know what the chain, providers and other participants can see.

A shielded pool reduces direct disclosure of note ownership and private transfer relationships. It does not erase public deposits, withdrawals or trades.

• Boundary transactions expose public addresses, asset, amount and time.
• Pool observers see commitments, nullifiers, transaction timing and public fees.
• RPC and relayer providers can observe connection and request metadata.
• Distinctive amounts, address reuse, timing and limited pool activity can enable correlation.
• A compromised browser, extension or device can expose keys and plaintext activity.

Understand these limits before deciding whether a particular workflow meets your privacy needs. The whitepaper describes the system’s scope; the privacy model goes into the remaining attack surfaces.

For developers

Source, artifacts, integration scope and contribution direction.

The corresponding source archive includes the browser, protocol packages, contracts, build scripts and dependency notices for the published release. Source availability is not an endorsement of unaudited production integration.

1. Read the architecture and its trust boundaries.
2. Use the exact release’s artifact and deployment information.
3. Develop against an isolated test environment; never treat fork addresses as production contracts.
4. Preserve recipient, quote, deadline and operation bindings when integrating.
5. Document public data and recovery behavior in your own interface.

A stable public SDK, integration examples and compatibility commitments are part of the future roadmap. Association-set work is research-only and does not alter the active proof system.