How is this different from a mixer like Tornado?

Mixers provide blanket anonymity and break AML/MiCA obligations, which rules them out for regulated entities. Neti keeps trades private from the market while preserving selective, regulator-facing disclosure — privacy with auditability, not anonymity.

ZK Privacy for EVM DEXs with Selective Disclosure

Q: Does this fragment liquidity?

No. There are no separate shielded pools to bootstrap; private trades execute through your existing public AMM liquidity, so composability with the rest of DeFi is preserved.

Add a zero-knowledge privacy layer to your existing EVM DEX. Protect wallet relationships, private balances, and post-trade strategy data while retaining access to public liquidity and controlled visibility for compliance and audit workflows.

Book a ZK privacy architecture call See the demo

Neti Shielded Trading Proxy: a ZK-SNARK privacy layer for compliant shielded trading on EVM DEXs

What Neti’s Shielded Trading Proxy is

Neti’s Shielded Trading Proxy is a zero-knowledge proof privacy layer for existing EVM DEXs. It uses client-side proof generation, relayed execution, proxy-to-router integration, stealth settlement, and selective disclosure to reduce the public link between institutional traders and their on-chain activity.

Why institutional capital keeps bypassing public DEXs

Public EVMs are transparent by design. For a fund or desk, that transparency is a structural blocker: balances, positions, and trade timing are visible on-chain the moment they act. That exposes alpha, invites copy-trading, and turns every hedge into a public signal.

Public execution exposes alpha

Large wallets and institutional traders do not want their balances, positions, and trading patterns visible on-chain.

Anonymous privacy is not institution-ready

Classic mixers are not a viable path for regulated entities operating under AML and MiCA constraints.

DEXs lose high-value order flow

When privacy is missing, serious flow moves to OTC desks, internalized routes, or private arrangements instead of public liquidity venues.

Full private trading infrastructure is too invasive

Most protocols do not want to redesign the whole AMM or create separate shielded pools that split liquidity.

What Neti's Shielded Trading Proxy is

Neti's Shielded Trading Proxy is a non-invasive ZK-SNARK privacy layer that sits in front of your existing DEX. Institutions execute private trades through your existing public AMM liquidity, no new chain, no shielded pool to bootstrap, no liquidity fragmentation. Confidential data can be selectively revealed to a compliance officer or auditor through a multisig view key, so privacy and MiCA/AML auditability coexist.

Integrate zero knowledge proof privacy without rebuilding the protocol

The proxy acts as a standard smart contract caller, which reduces implementation friction and avoids unnecessary re-audits of the AMM core.

Stay private without becoming non-compliant

Multisig view keys enable selective disclosure for specific fund flows when required by compliance or audit processes.

Use existing liquidity

No empty shielded pools. No fragmented execution layer. Trades route through your existing AMM order books.

How Neti's approach compares to the alternatives

Approach	Separate chain/migration	Privacy tech	Private from operator	Regulator-ready (selective disclosure)	Touches core AMM
Neti Shielded Trading Proxy	No, layer on your existing EVM	Pure ZK-SNARK + selective disclosure	Yes	Yes, multisig view key	No
Ready ZK libraries (Railgun)	No (closest in architecture)	ZK, retail-user oriented	Partial	No clear compliance/view-key story	No
Privacy L2 (Aztec)	Yes, you move to their L2	ZK (Noir)	N/A	Limited	N/A
FHE layer (Zama)	Confidentiality layer	FHE (flexible, slower today)	Varies	Emerging	Product-only
Private permissioned chain (ZKsync Prividium)	Yes, migrate to a separate chain	ZK proofs to L1	No, operator sees all txns	Yes	N/A
Mixers (Tornado-style)	No	Anonymity set	Yes	No, breaks AML/MiCA	No

How shielded execution works, step by step

Intent (Oﬀ-chain ZK)

The user's device generates a ZK proof of intent and derives a stealth address. Keys never leave the client (client-side proving via a WASM SDK).

Who needs ZK privacy for EVM DeFi

This is for teams that operate on public chains and need privacy with compliance, not instead of it:

EVM DEXs and perp DEXs (Tier-1 and L2)

trying to attract institutional or larger-trader flow without forcing public exposure.

Cross-border and B2B payment fintechs

already on-chain (e.g. USDC on an L2) who accidentally exposed supplier volumes, margins, or client relationships, and need bank-grade discretion without breaking the Travel Rule.

Institutional desks, funds, and treasuries

that cannot show rebalancing, positions, or LP exposures in real time.

Privacy isn't a technical checkbox, it's how you unlock flow you currently lose:

Attract larger traders

without forcing public exposure.

Protect strategies

running an AMM or perpetual DEX on an L2

Expand toward institutional participants

without abandoning compliance.

Turn privacy into a differentiator

that pulls institutional capital onto your venue instead of a competitor's.

Why teams choose Neti for ZK privacy

Four differences that matter to an engineer who's afraid of two things, breaking their audited core and breaking the law:

No separate chain

Privacy is added on the public EVM you already use. Zero liquidity fragmentation, full DeFi composability preserved.

Pure ZK, not hardware

Security comes from mathematics, not trust in a chip vendor (as with TEE/SGX-based approaches, which have a documented vulnerability history).

Privacy with auditability

Selective disclosure reconciles user privacy with regulatory readiness - no "all public or nothing."

Two paths: product and delivery

A ready SDK/API for fast integration, plus full custom delivery for complex builds. Pure-product vendors can't offer the second path.

See the Zero Knowledge Proof Trading Flow in Practice

We can walk your team through the architecture, privacy model, and integration logic behind the Shielded Trading Proxy, including ZK-SNARK proof generation, relayed execution, DEX router integration, and selective disclosure.

FAQs

No. The proxy acts as a standard smart-contract caller and routes through your existing DEX router, so your core AMM needs zero modifications and no re-audit. Integration is deployed as a proxy layer plus a frontend SDK (or via API).

No. There are no separate shielded pools to bootstrap, private trades execute through your existing public AMM liquidity, so composability with the rest of DeFi is preserved.

Yes, by design. Transactions are private to the market but not anonymous: a compliance officer can use a multisig view key to selectively decrypt specific fund flows for CASP/AML auditors. It's built for "compliant with regulators — not hiding too much," not for evasion. (This is a technical architecture, not legal advice; your compliance team confirms fit for your jurisdiction.)

Mixers provide blanket anonymity and break AML/MiCA obligations, which rules them out for regulated entities. Neti's approach keeps trades private from the market while preserving selective, regulator-facing disclosure, privacy with auditability, not anonymity.

Railgun targets individual users and has no clear multisig-view-key compliance path; Aztec requires moving to a separate privacy L2. Neti adds privacy on the public chain you already use, keeps trades private even from the operator, and is built for institutions that need auditability.

The architecture uses client-side ZK proving and relayer-based execution to avoid the scaling bottlenecks seen in some existing ZK privacy tools. The right answer for your specific throughput is validated in a scoped PoC before any production commitment.

It removes the public pre-trade signal that most front-running depends on by shielding intent and execution. It is a privacy layer, not a blanket MEV-elimination guarantee; the exact protection profile is defined against your venue's design.

Shielded execution for institutional order flow on an existing EVM DEX, private balances and positions, existing liquidity, and selective disclosure for compliance — delivered as a PoC first, then hardened for production.

Tell Us What You Need to Build

We work with banks, payment companies and fintechs on payment systems, digital assets and custom software. In a free 30-minute call, an engineer looks at your problem, the risks and the best next step. If we are not the right fit, we will tell you directly.

ZK Privacy for EVM DEXs with Selective Disclosure

What Neti’s Shielded Trading Proxy is