Frequently Asked Questions

Zero-knowledge proof privacy solutions use cryptographic proofs to verify that a transaction or action is valid without revealing the underlying confidential information. In blockchain applications, they can help protect balances, transaction relationships and sensitive business activity while preserving on-chain verifiability.

Neti designs ZK privacy layers for financial and blockchain systems that need confidentiality without giving up auditability or access to existing public infrastructure.

Public blockchains expose transaction data by default, including wallet activity, balances and interactions between addresses. Zero-knowledge proofs allow a system to confirm that predefined conditions have been met without publishing all the data used to prove them.

This makes it possible to reduce wallet tracing, protect sensitive transaction flows and limit the exposure of trading or financial activity while retaining cryptographic verification.

The user creates a transaction or trading intent and generates a ZK-SNARK proof on their device. A relayer submits the anonymized payload and pays the gas fee, reducing the risk of linking execution to the user’s funding wallet.

The Neti proxy contract then interacts with the existing DEX router, and the resulting assets can be settled to a one-time address. Where an authorized review is required, selected information can be disclosed through the configured view-key mechanism.

Depending on the implementation, the ZK privacy layer can protect private balances, participant relationships and the direct connection between a source wallet, shielded activity and a settlement address.

The public blockchain may still show that assets entered or exited a privacy contract. The objective is not to make the blockchain invisible, but to prevent observers from easily reconstructing the private transaction path and associating it with a specific user or strategy.

No. Neti’s current approach is designed to add blockchain privacy to the EVM infrastructure the client already uses.

A DEX or financial application can retain its existing network, contracts, users, integrations and liquidity instead of migrating to a separate privacy-first blockchain. The current implementation is EVM-based, while parts of the underlying cryptographic architecture can be adapted to other environments.

No. The Shielded Trading Proxy is designed to use the DEX’s existing public liquidity rather than creating a separate shielded pool that must build liquidity independently.

The proxy acts as an additional execution and privacy layer while routing trades through the existing AMM infrastructure. This allows the DEX to introduce privacy-sensitive flows without splitting its liquidity between separate markets.

The architecture is designed so that the proxy behaves like a standard smart-contract caller interacting with the existing DEX router. This means the core AMM logic does not necessarily need to be rebuilt.

The new proxy contracts, ZK circuits, relayer, SDK and integration boundaries still require implementation-specific testing and security review. The advantage is a reduced scope of change, not the elimination of security work.

Selective disclosure allows specifically authorized information to be revealed without exposing all private activity in the system.

For example, an institution may need to disclose a defined transaction path or information connected to a particular user during an audit or compliance review. A scoped view key can provide access to that information without making the complete privacy pool or every user’s activity public.

View-key governance is defined for each implementation. Access can be assigned to designated compliance, audit or governance participants and protected through multisig or threshold authorization.

The architecture can be designed so that no single party has unrestricted access to all private activity. The exact model should define who can authorize disclosure, what information can be accessed and whether the key applies to a user, transaction path or specific period.

The system can be designed so that neither Neti nor the DEX operator has default access to confidential user information.

Private data is processed through client-side proof generation and can only be disclosed according to the agreed key-governance model. The final visibility rules depend on the implementation, including who holds disclosure rights and how access is authorized.

Zero-knowledge technology can support compliance-aware privacy, but it does not make an entire platform automatically compliant.

Neti combines privacy with selective disclosure so that designated information can remain available for audit, investigation or regulatory workflows. The final compliance position also depends on the client’s KYC and AML controls, transaction-monitoring processes, key governance, operating model and jurisdiction.

A traditional mixer is primarily designed to break public transaction links and may not provide controlled visibility for regulated entities.

Neti’s approach is designed around institutional privacy with selective disclosure. It allows confidential flows to remain private by default while preserving a governed mechanism for reviewing specific activity when required. The goal is controlled blockchain data privacy, not unrestricted anonymity.

Not completely in the current Shielded Trading Proxy model.

The solution is primarily designed to reduce wallet tracing, balance exposure, post-trade strategy leakage and copy-trading. Because execution ultimately interacts with public DEX infrastructure, some transaction-ordering and MEV risks may remain.

Full pre-trade protection would require deeper changes to areas such as mempool visibility, transaction ordering or the blockchain execution environment.

Yes. ZK privacy can be applied to stablecoin transfers, payment infrastructure, treasury flows and other financial systems where public balances and transaction relationships create operational or confidentiality risks.

Potential applications include neobank transfers, institutional settlement, corporate treasury operations and privacy-sensitive cross-border payments. The architecture must be adapted to the client’s ledger, wallet, custody and compliance model.

In the current architecture, ZK proofs are generated on the user’s device through a ZK-aware wallet or application. Private keys and confidential inputs do not need to be sent to the DEX or an external proving service.

The proof is then verified by the relevant smart contract, allowing the blockchain to confirm that the operation is valid without learning the private values used to create it.

A ZK-SNARK is a compact cryptographic proof that allows one party to prove that a statement is true without revealing the private information behind it.

In Neti’s privacy architecture, ZK-SNARKs can be used to prove ownership, balance sufficiency or the validity of a shielded operation. The blockchain verifies the proof rather than receiving the confidential inputs themselves.

Neti currently follows a hybrid model.

The Shielded Trading Proxy is being developed toward an API and SDK integration path for clients that need a faster implementation. Neti also provides custom ZK delivery covering discovery, architecture, circuit development, smart contracts, wallet or frontend integration, deployment and production support.

This allows a client to choose between a more standardized integration and a solution adapted to complex privacy, compliance or protocol requirements.