PLabs

We build privacy

1. pERC20: EIP-8287-Draft-

[PLabs @_PLabs]

Excited to share our research proposal, HIP-6: Dark Pool on Hyperliquid, for @HyperliquidX 👇 (https://t.co/ye1YzfPlsD)

The problem isn't transparency itself — most flow trades fine on a lit book. It's size. A large order on an open book moves price against itself and invites front-running, so institutions route block flow off-exchange (40%+ of US equity volume). On-chain that pain is worse: orders, balances, and counterparties stay public forever. Today there's nowhere on-chain to execute size privately.

HIP-6 reproduces a TradFi dark pool, natively on-chain: • Encrypted RFQ to a self-chosen LP set — nothing public pre-trade • Settled at the Hyperliquid lit reference price (read from HyperCore) • No order book, no matcher, no price discovery → no AMM slippage • Non-custodial, atomic settlement on HyperEVM

And a dark pool isn't a mixer — it's private to the public, transparent to the regulator: • Clean-entry via ZK association proofs (Privacy Pools) • Traceable through escrowed viewing keys • Enforced by deny-spend freezes — funds are never seized • Selective disclosure on demand

Why Hyperliquid? Replicating this needs all three at once: a high-quality on-chain reference price (HIP-1), an EVM for shielded state (HyperEVM), and deep TVL to recycle into liquidity. HL is the only place that has all three.

The result: institutions trade size confidentially, LPs put idle TVL to work, and Hyperliquid opens a new lane of institutional block flow — without cannibalizing existing volume.

Looking forward to all feeadbacks @chameleon_jeff @HyperliquidX @HyperFND @Sterling_hl

[PLabs @_PLabs]

1/1 We then had Opus 4.8 check two live privacy protocols — @RAILGUN_Project and @0xprivacypools — for whether they use Circom/circomlib correctly.

Verdict: both are safe. Range checks use Num2Bits with safe bit-widths, selectors are binary-constrained, and they rely on the field-IO EdDSAPoseidonVerifier rather than the legacy bit-IO path.

The takeaway: the bug classes Opus surfaces are the kind that audit firms and tooling already catch — funded projects that paid for audits are in good shape.

But if you're a project without the budget for an external audit, take a close look. These footguns are exactly where under-audited circuits bleed funds. 🔒

[PLabs @_PLabs]

🔒 circomlib is safe — but if you build on it, mind your funds.

Inspired by Opus 4.8's stunning catch of the @Zcash inflation bug, we had it audit Circomlib — the circuit library behind nearly every ZK privacy project (Including us): https://t.co/VnLFHrPDvY

Verdict: Circomlib itself is safe. Opus found no directly exploitable bug.

But it pushes critical safety preconditions (subgroup checks, canonical bit uniqueness, input ranges, binary selectors) onto the caller. Misuse them and you risk double-spends, minting, or signature forgery — i.e. real funds.

Full audit report below👇
https://t.co/KNHhkhiWON

Devs, check your circuits against it. Opus even shipped runnable PoCs proving the dangers are real, not theoretical.

[PLabs @_PLabs]

Draft: https://t.co/yMK4a3z6gq

[PLabs @_PLabs]

@cz_binance: "...If you want to trade privately, you could use @Aster_DEX..."

@notthreadguy: "Why couldn't @chameleon_jeff and @HyperliquidX just add Dark Pool privacy functionality..."

@cz_binance: "I would say they should..."

Glad to see the sentiment that "DEXs should have kind of Dark Pool functionality." We are cooking @HYPERDailyTK . 🔥

[吴说区块链 @wublockchain12]

CZ 谈 Aster 需要做什么才能超越 Hyperliquid (历史视频)

币安创始人赵长鹏（CZ）@cz_binance 在 2025 年 10 月 11 日接受 threadguy 频道采访时，被问及 Aster 需要怎么做才能超越 Hyperliquid 时，CZ 表示二者并非简单竞争关系，而是面向不同应用场景。

Hyperliquid 更适合“公开交易、所有人可见”，而 Aster 在隐私和原生资产充值上更开放，不只是仅限 BNB 链的 Perp DEX。CZ 指出，两者均为近两年的新产品，未来格局仍未确��，甚至可能被后来者取代，“不过做第二名反而能避开很多坑”。

来源：threadguy

[PLabs @_PLabs]

@brian_armstrong What about the "confidential payment" on @base?

[PLabs @_PLabs]

Privacy101: Understand @Zcash Orchard - How your money stays private？
---

Previous in this series:
Ch 1 — Orchard key components: https://t.co/DI5IszIreL
Ch 2 — How does the user receive tokens with IVK?: https://t.co/ChiJxnDJaj
Ch 3 — How does user disclose transaction details with OVK?: https://t.co/aadpcAnCKN

A shielded balance is not an account balance — it is a bag of notes. Each note is a private coin with its own commitment on chain. This chapter: what is inside a note, what the chain sees, and how regulators link a spent nullifier back to the note commitment that created it.

1. What is inside a note?

Orchard note (private): (d, pkd, v, ρ, ψ, rcm) — recipient address, value in zatoshi, nullifier randomness, commitment trapdoor (§3.2).

2. What the chain sees

Same note, two public fingerprints — no plaintext:

Tx1 (output): cmx — note created.

Tx2 (input, later): nf — note spent.

C_enc carries encrypted data for the recipient; observers still cannot read d, v, or memo, and cannot link cmx to nf.

3. Linking nf to cmx — regulator with FVK

On chain, cmx (Tx1) and nf (Tx2) are unlinkable. IVK or OVK alone cannot bridge them — the link needs nk, which lives inside Full Viewing Key (ak, nk, rivk). FVK still cannot spend (no ask).

Step 1 — Find the note. Trial-decrypt every Action's C_enc with ivk. One decrypts → plaintext (d, v, rseed, memo); that Action is Tx1.

Step 2 — Rebuild and verify. Take ρ and cmx from the Tx1 Action (public), expand rseed → ψ, rcm, compute cm = NoteCommit(...), and check cm = cmx.

Step 3 — Recompute the nullifier. nf' = Extract_P( [F_nk(ρ) + ψ mod p]·G + cm ). All four inputs needed: nk, ρ, ψ, cm.

Step 4 — Match the spend. Scan every Action's nullifier for nf'. When it appears as the nf of Tx2, that transaction spent this note — cmx (Tx1) and nf (Tx2) are now linked.

FVK also derives ovk for outgoing audit (Ch3). Share FVK only under compliance duty — it exposes full incoming + outgoing history and spend linkage.

[PLabs @_PLabs]

https://t.co/lfqhpWsPGx

[PLabs @_PLabs]

Congratulations! With @mert's comprehensive understanding of the Zcash protocol, bringing it to @solana is absolutely the right call.

[Helius @Helius]

Big Solana news:

The Light Protocol team is joining Helius to help build Solana's most complete ZK privacy layer.

Private payments, markets, and finance -- at Solana scale.

Fully composable, fully onchain, fully open-source.

[PLabs @_PLabs]

@arc TEE is g00d, but ZK-based privacy is the end game.

[PLabs @_PLabs]

@DaveStrategist Welcome this great feature on HL, Sir?
https://t.co/GeGI5zQcsp

[PLabs @_PLabs]

Excited to share our research proposal, HIP-6: Dark Pool on Hyperliquid, for @HyperliquidX 👇 (https://t.co/ye1YzfPlsD)

The problem isn't transparency itself — most flow trades fine on a lit book. It's size. A large order on an open book moves price against itself and invites front-running, so institutions route block flow off-exchange (40%+ of US equity volume). On-chain that pain is worse: orders, balances, and counterparties stay public forever. Today there's nowhere on-chain to execute size privately.

HIP-6 reproduces a TradFi dark pool, natively on-chain: • Encrypted RFQ to a self-chosen LP set — nothing public pre-trade • Settled at the Hyperliquid lit reference price (read from HyperCore) • No order book, no matcher, no price discovery → no AMM slippage • Non-custodial, atomic settlement on HyperEVM

And a dark pool isn't a mixer — it's private to the public, transparent to the regulator: • Clean-entry via ZK association proofs (Privacy Pools) • Traceable through escrowed viewing keys • Enforced by deny-spend freezes — funds are never seized • Selective disclosure on demand

Why Hyperliquid? Replicating this needs all three at once: a high-quality on-chain reference price (HIP-1), an EVM for shielded state (HyperEVM), and deep TVL to recycle into liquidity. HL is the only place that has all three.

The result: institutions trade size confidentially, LPs put idle TVL to work, and Hyperliquid opens a new lane of institutional block flow — without cannibalizing existing volume.

Looking forward to all feeadbacks @chameleon_jeff @HyperliquidX @HyperFND @Sterling_hl

[PLabs @_PLabs]

Thanks to @paradigm and @HyperliquidPC for pushing this forward. If FinCEN adopts the proposal to recognize smart contract-level compliance mechanisms, developers will finally have real regulatory certainty — a critical foundation for building compliant onchain applications.

This matters just as much for the privacy space: privacy isn't the opposite of compliance. Onchain privacy use cases need compliance frameworks too. This direction also lays the groundwork for how privacy applications can be designed with compliance in mind.

[Hyperliquid Policy Center @HyperliquidPC]

https://t.co/gZX4O8GZgi

[PLabs @_PLabs]

@decodejar @SuiNetwork That's why they call it "confidential". @SuiNetwork

The difference between "private" and "confidential" is as follows:

[PLabs @_PLabs]

@BarrySilbert @HarrisPoll Finance privacy must be regulator-friendly, so Zcash satisfies that requirement, right?

[PLabs @_PLabs]

https://t.co/lfqhpWsPGx

[PLabs @_PLabs]

STRK20 on ZKVM
pERC20 on EVM

privacy is the future.

[Starknet (Privacy Arc) @Starknet]

Privacy finally found the right frequency.

[STRK20] is live on Starknet.

🧵

[PLabs @_PLabs]

Privacy101 — How Private Money Works？
---
Chapter 2 — How does the user receive tokens with IVK? (§4.2.3, §4.20.2, §4.22 in https://t.co/0HXOVpApn6)

1. Derive shielded addresses — receive fund
IVK = (dk, ivk). Together they generate one-time shielded addresses — pre-make a batch or create one when needed. Share an address with a payer; one IVK still scans and decrypts them all.

2. Block scan — view
A sender pays you in an Orchard Action. You never get a normal on-chain credit. Each Action publicly carries epk, C_enc, and cmx; the plaintext stays inside C_enc. Your wallet scans every block, every Action. No spending key — only ivk to try decryption. (nk checks spent later.)

3. Trial decryption — is this note mine?
You do not match addresses first. For each Action: ivk + epk → shared secret → decrypt C_enc.
❎Fail → skip.
✅Succeed → rebuild note commitment, check it equals cmx.
✅Pass → your note (value, memo, d).

4. Keep IVK secret
IVK never appears on chain. Anyone with IVK (+ nk) can see all your incoming payments — amounts, memos, timing. They cannot spend (no ask) or see outgoing payments (need ovk). Share IVK only with parties you trust to scan for you.

👉Next: How does user disclose transaction details with OVK?

[PLabs @_PLabs]

Privacy101 — How Private Money Works？

Privacy is becoming foundational infrastructure for blockchains. More projects are looking at the @Zcash protocol — still the strongest privacy design we have — as their reference. But the spec is dense. This series walks through it from §3.1, focusing on Orchard.
---

Chapter 1 — Orchard key components (§3.1 in https://t.co/0HXOVpApn6)

1 . Spending key (sk)
The root private key. Ultimate control over the account — backup this to recover everything.

2. ask / ak (spend authorizing key / validating key)
Derived from sk. ask is re-randomized into a one-time key pair (rsk, rk) used solely for each spendAuthSig.

Core purpose: a delegated prover may need private data (e.g. ak, nk) to build the proof — enough to view incoming notes — but cannot spend the user's notes without ask, which only the user holds to derive rsk and sign.

3. Full viewing key (ak, nk, rivk)
Derived from sk. From it you can derive the keys to view incoming and outgoing shielded activity. Does not let you spend.

nk (nullifier deriving key)
Computed from nk and the note contents — one note, one nf, spend once. Zcash's June 2026 Orchard attack broke exactly this rule: https://t.co/os9tRrpSlc

rivk
Derived from sk. Commit_ivk randomness — used with (ak, nk) to derive ivk, dk, and ovk.

4. Incoming viewing key (dk, ivk)
Decrypts incoming note ciphertexts.

5. Outgoing viewing key (ovk)
Decrypts outgoing payment details — what you sent, to whom, how much. Useful for compliance and audit: view your own sends without spend authority.

6. Shielded payment address (d, pkd)
What you share to receive funds. Users can generate many unlinkable shielded addresses to improve anonymity, while reusing the same viewing keys to scan and decrypt them all.

👉Next: How does the IVK work?

[PLabs @_PLabs]

@EliBenSasson Who control OVK for users? Sir

[PLabs @_PLabs]

Privacy101 — How Private Money Works？

Privacy is becoming foundational infrastructure for blockchains. More projects are looking at the @Zcash protocol — still the strongest privacy design we have — as their reference. But the spec is dense. This series walks through it from §3.1, focusing on Orchard.
---

Chapter 1 — Orchard key components (§3.1 in https://t.co/0HXOVpApn6)

1 . Spending key (sk)
The root private key. Ultimate control over the account — backup this to recover everything.

2. ask / ak (spend authorizing key / validating key)
Derived from sk. ask is re-randomized into a one-time key pair (rsk, rk) used solely for each spendAuthSig.

Core purpose: a delegated prover may need private data (e.g. ak, nk) to build the proof — enough to view incoming notes — but cannot spend the user's notes without ask, which only the user holds to derive rsk and sign.

3. Full viewing key (ak, nk, rivk)
Derived from sk. From it you can derive the keys to view incoming and outgoing shielded activity. Does not let you spend.

nk (nullifier deriving key)
Computed from nk and the note contents — one note, one nf, spend once. Zcash's June 2026 Orchard attack broke exactly this rule: https://t.co/os9tRrpSlc

rivk
Derived from sk. Commit_ivk randomness — used with (ak, nk) to derive ivk, dk, and ovk.

4. Incoming viewing key (dk, ivk)
Decrypts incoming note ciphertexts.

5. Outgoing viewing key (ovk)
Decrypts outgoing payment details — what you sent, to whom, how much. Useful for compliance and audit: view your own sends without spend authority.

6. Shielded payment address (d, pkd)
What you share to receive funds. Users can generate many unlinkable shielded addresses to improve anonymity, while reusing the same viewing keys to scan and decrypt them all.

👉Next: How does the IVK work?

[zooko🛡🦓🦓🦓 ⓩ @zooko]

https://t.co/v7BiOdzU9E

[PLabs @_PLabs]

Big week 🌂☂️🍆🍇🐙

[Solana @solana]

Big week ♠️♥️♣️♦️

[PLabs @_PLabs]

@zayn4pf ✅