Hold balances, pay and settle on Robinhood Chain — and choose exactly what anyone else gets to see.
Robinhood
Testnet scope
Bonding curve → Uniswap v4
Nothing on mainnet
Public addresses are pseudonymous, not private. The moment one is linked to a person, a business, a social profile, an exchange account or an app, its activity can be analysed continuously — and permanently.
Nothing above requires a subpoena, an exploit, or a leak. It is the ledger working exactly as designed — and it is permanent.
A merchant
A subscription platform
An auditor
Transparent ledgers leak commercial strategy
Supplier payments · Payroll values · Customer relationships · Treasury rebalancing · Acquisition activity · Pricing arrangements · Operating costs.
Businesses need verifiable settlement and controlled disclosure at the same time.
Privacy must become an invisible product capability, not a specialist workflow. Existing privacy systems ask users to absorb complex concepts, fragmented liquidity, manual key management and unfamiliar transaction flows.
Privacy is not the absence of proof.
Privacy is control over disclosure.
A transaction should be verifiable without automatically publishing every underlying detail. Public blockchains made finance verifiable. ZKhood makes transparency a choice.
The network must verify that protected transactions follow protocol rules, that assets are not created from nothing, and that value cannot be spent twice.
Users choose public or protected interactions. Not every use case belongs in the same privacy model.
Prove a required fact, or share a limited record, without exposing everything else.
Privacy should never require handing assets to a centralised intermediary.
The interface speaks in Protect, Send, Pay, Prove and Share Access. Nobody should need to understand nullifiers to send money.
Primarily breaks transaction links
Creates programmable protected accounts
Deposit and withdraw
Hold, transfer, pay, prove and disclose
Limited application logic
SDK for wallets, payroll, membership and commerce
Difficult business auditability
Scoped view access and disclosure proofs
Privacy as a single transaction
Privacy as an account and application capability
A supported asset enters protected state, moves, settles and — when you decide it should — becomes readable to exactly one viewer. The network verifies every step without seeing the amounts behind it.
A supported asset moves from a standard EVM wallet into protected state. The contract records an encrypted commitment instead of a readable per-user balance.
The protected account holds value behind cryptographic commitments. Ownership and correctness stay verifiable to the network; the amounts do not.
The sender's wallet generates a validity proof locally and submits it with an encrypted output. The contract verifies and updates protected state without ever seeing the amount.
A proof answers one question and stops. It does not hand over the record the answer was derived from.
A view key grants a named viewer a scoped, expiring window into protected history — and nothing outside that window.
Value returns to a public address against a validity proof. This step is deliberately the least private one in the system, and the interface says so.
A view key is not an on/off switch for your history. It is a scope — an account, an asset, a period, a category, a ceiling — with an expiry attached. Toggle one and the preview rewrites itself.
WHAT THE VIEWER WILL LEARN
REMAINS PROTECTED
Access ends after 7 days and can be revoked before then. Revocation stops future reads; it cannot un-see what was already read.
A proof answers a question and stops. A view key opens a window and closes it. Neither hands over the ledger — and neither is a promise that the rest of your behaviour, your device, or your withdrawal pattern stays private.
The long-term objective is broader than launching a privacy coin. Each component is labelled with the stage it has actually reached — none of them is deployed.
Zero-knowledge privacy infrastructure
Verifier contracts, protected-state contracts, encrypted notes and commitments, reached through proof generation and a relayer network.
Public and protected accounts, one interface
A public balance you can read and a protected balance only you can read, side by side, with a single set of verbs.
Private consumer and merchant payments
A merchant receives a valid payment and a settlement receipt. It never inspects the customer's wallet history to get there.
Selective-disclosure credentials
Proof-based access without unnecessary identity exposure. The application receives the claim, not the record behind it.
Confidential payroll and treasury
Privacy controls sized for teams: who can spend, who can approve, who can see, and for how long.
Privacy components for developers
Add protected balances and disclosure to an application without building proof infrastructure from the ground up.
Utility and coordination token
Coordinates the network's service providers. It does not gate access to your own wallet.
An application adds protected balances and disclosure through the SDK without standing up proving infrastructure. Secure defaults, explicit permissions, typed transaction states, visible proof progress, recoverable failures — and no hidden data collection.
UNRESOLVEDThis illustrates the intended developer experience. It is not a finalised SDK interface.
const account = await zkhood.createProtectedAccount();
await account.protect({
asset: USDG_ADDRESS,
amount: "100"
});
await account.privateTransfer({
recipient: recipientPrivacyAddress,
asset: USDG_ADDRESS,
amount: "25"
});An EVM-compatible Arbitrum Layer-2 settling to Ethereum, using ETH for gas. Solidity, Foundry and Hardhat work unmodified, and native account abstraction removes most of the onboarding friction a privacy wallet would otherwise inherit.
| Property | Mainnet | Testnet · in scope |
|---|---|---|
| Chain ID | 4663 | 46630 |
| Gas token | ETH | ETH |
| Public RPC | rpc.mainnet.chain.robinhood.com | rpc.testnet.chain.robinhood.com |
| Explorer | robinhoodchain.blockscout.com | explorer.testnet.chain.robinhood.com |
VERIFYNetwork values and canonical asset contracts change. Verify every setting against current official Robinhood Chain documentation before deployment.
Support is introduced in stages, and each addition has to clear the same gate.
STAGE 1 · INITIAL
STAGE 2 · EXPANSION
EVERY ASSET MUST CLEAR
Canonical contract verification · Decimal and transfer-behaviour review · Risk classification · Liquidity and exit considerations · Monitoring · Clear status in the interface.
Users
Hold protected balances, pay, generate proofs, control disclosures.
Applications
Integrate privacy modules into commerce, membership, payroll, governance.
Relayers
Submit transactions and improve usability — never taking custody.
Provers
Provide proof-generation capacity where delegated proving is supported.
Auditors
Review contracts, circuits, cryptographic assumptions and wallet behaviour.
Governance
Coordinate parameters, supported modules and upgrades under defined limits.
pons is the launch protocol native to Robinhood Chain. It never takes custody: creating, buying, selling and claiming fees are each a transaction your own wallet signs. ZKH would use pons v2, where a launch opens on a bonding curve and graduates into a permanently locked Uniswap v4 pool.
The creator sets name, symbol, image, description and links, and pays the launch fee. The entire supply mints straight to the curve — nobody, creator included, holds a bag set aside before trading opens.
Anyone can buy and sell. Price is derived from how much supply has been bought, not set by anyone. The curve always takes the other side, so you are never waiting on liquidity.
Once the curve sells out it closes, and everything it collected — plus the supply held back for exactly this purpose — is handed over to build the pool. Anyone can push a stalled launch forward.
A Uniswap v4 pool is created and its liquidity is locked permanently. There is no unlock button and no privileged wallet — not the creator's, and not pons'.
Price against supply sold, before graduation
Illustrative. Drawn from the constant-product formula, not from live market data.
Opening buy tax, first five seconds
Applies to buys only. Sells are never taxed by it, and what it collects flows back into the launch.
Snipe protection
A buy tax opens at 99% and decays exponentially to zero across five seconds — near 25% at one second, around 3% at two. Sells are never taxed by it, and what it collects flows back into the launch.
Fees
A standard trading fee split between pons, the creator and the optional buyback, plus a capped creator tax fixed at creation. Both are immutable for the life of the launch and charged on the quote leg — never in the launch token.
Buybacks
Optional, funded from the creator's own share. Bought-back supply is locked and vests linearly over five years on a weighted clock, never burned and never released as a lump sum.
Creator controls
After launch a creator can change only two things: where their fees are paid, and whether buybacks run. No mint, no freeze, no blacklist, no post-launch tax.
FOR INTEGRATORS
Curve maths alone overstates what a buy returns while the snipe tax is decaying. A quote engine must read currentSnipeTaxBps(recipient) from the curve and apply it — and note it keys on the recipient of the tokens, not the sender.
Chain 4663
Or an approved pair token
Minted entirely to the curve
Charged by the hook, not the pool
Paid at creation
Default v1 threshold
Graduation confirms a threshold was reached. It is not a quality signal, and it guarantees nothing about future liquidity, price, or your ability to exit. Names and symbols can be copied — any token claiming to be ZKH today is not ours. Verify the address against this site before signing anything.
Users should be able to pay fees in supported assets wherever possible, while protocol economics route transparently in the background.
FEE ROUTING
A user or application pays a fee
in a supported asset wherever possible
Protocol fee router
Relayer compensation
Transaction submission and availability
Prover compensation
Proof-generation capacity
Protocol treasury
Audits, infrastructure, grants
Optional token burn
Only if governance enables it
REVENUE, KEPT SEPARATE
Protocol fees
→ Relayers, provers and protocol treasury
Commercial product revenue
→ Development, infrastructure, support and audits
This is the gate, not a date. A token that ships before its product has nothing to coordinate.
If you read any of these on a site claiming to be ZKhood, it is not ZKhood.
Revenue would come from usage — protocol fees, merchant fees, business subscriptions, developer plans, delegated proving, enterprise integrations — not from token appreciation.
Nothing here has shipped. The order matters more than the dates: proofs before payments, audits before mainnet, product before token.
MVP · IN SCOPE
12 ITEMSMVP · OUT OF SCOPE
7 ITEMSThe list on the right is the more useful one. Anything a privacy project refuses to do in its first release tells you more than anything it promises to.
Privacy protocols expand both cryptographic and application risk. Security is treated as a continuous system, not a milestone.
No external audit has been published. Treat every claim on this site as unverified until one is.
Cryptographic implementation error
Specialist audits, test vectors, formal review
Metadata leakage
Threat modelling, private indexing, relayer design
Poor wallet recovery
Multiple recovery options and clear backup UX
Smart-contract exploit
Minimal contracts, limits, audits, monitoring
Regulatory restrictions
Legal review, scoped releases, geographic controls where required
Misuse narrative
Clear acceptable-use positioning and controlled disclosure tools
Low privacy set
Progressive asset support and honest privacy indicators
Slow proof generation
Benchmarking, optimised circuits, optional delegated proving
Fake ZKhood interfaces
Signed releases, verified domains, wallet warnings
Premature token speculation
Delay ZKH until product utility exists
PRODUCT METRICS
PROTOCOL METRICS
ECOSYSTEM METRICS
Security and reliability are more important than transaction volume during early phases.
No. A mixer breaks transaction links between a deposit and a withdrawal. ZKhood creates programmable protected accounts that can hold, transfer, pay, prove and disclose — and it ships the disclosure tooling a mixer has no reason to build.