01Define the policy
The institution commits approved destinations, approval groups, spending limits and execution delays.
DNA PROTOCOL / ZK PRIVACY / ZKGUARD
Prove authorization.
Enforce treasury controls.
Privacy-preserving treasury authorization.
Built for institutions and exchanges.
AUTHORIZATION ENGINE / CONCEPT
INSTITUTIONS & EXCHANGESPRIVATE AUTHORIZATIONCUSTODY ENFORCEMENTNO RETAIL ACCESS
INSTITUTIONAL POLICY WORKSPACE
DESIGN PREVIEW v0.1Evaluate a treasury policy
Explore a fictional replenishment request.
Illustration only. No ZK proof is generated, no wallet is connected, and no funds move.
Example policy: At least 2 approvals, an approved destination and a maximum of 50,000 units per transfer. These are demonstration values, not recommended institutional limits.
Browser-local calculation. Do not enter real treasury information.
THE PROPOSED ARCHITECTURE
From policy to protected execution.
0102Authorize independently
Institution-controlled signers approve the exact asset, amount, destination and execution context.
03Prove the conditions
The proposed prover demonstrates private policy membership and authorization without exposing its witness.
04Enforce at custody
A compatible custody adapter must reject transfers that fail verification. A bypassable API is not protection.
EXPLICIT TRUST BOUNDARIES
Security is enforced. Not assumed.
Our server is not your signing authority.
The intended design keeps authorization keys with the institution. Compromising ZKGuard's backend alone must not authorize a protected transfer.
This property requires correct custody integration, independent approvals and no unilateral vendor override.
Private approvals. Explicit public data.
ZK verification can conceal selected approval memberships and policy inputs. Ordinary public-chain transfers can still reveal addresses, amounts and timing.
ZKGuard is not a confidential-transfer system or proof of institutional solvency.
No promise of unhackable funds.
Compromised signing quorums, faulty circuits, custody bugs and underlying chain failures remain risks. Funds outside the enforced path are not protected.
No independent audit or production fund protection is available in this preview.
Recovery without a vendor backdoor.
The proposed recovery path uses institution-controlled approvals, delays and preauthorized destinations. It must work without our hosted service.
Recovery is a security-sensitive path that requires its own implementation and review.
DELIVERY GATES
Evidence before exposure.
Product design
Institutional scope, trust boundaries and browser-local policy illustration.
Testnet prototype
Real proof generation, transaction binding and a single-chain custody enforcement path.
Independent review
Circuit and contract audits, remediation, adversarial testing and recovery drills.
Institutional pilot
Limited exposure only after review, explicit risk acceptance and validated operational controls.
Institutional questions.
Who is ZKGuard for?
Exchanges, custodians and institutional treasury operators. There is no retail wallet, consumer investment product or public deposit service.
Does the example generate a zero-knowledge proof?
No. It evaluates three fictional policy conditions locally in your browser. The prover, verifier and custody integration remain planned engineering work.
Can an existing custody system bypass the proof?
If any signing or execution route bypasses proof enforcement, that route is outside the protection model. Every adapter must be assessed independently before integration claims are made.
Where does ZKGuard fit within DNA Protocol?
ZKGuard is a separate institutional product under ZK Privacy. This preview does not change any existing DNA Protocol service.