An exchange can lose control of its application without its treasury having to lose control of its funds. That is the security boundary ZKGuard is designed to create: access to a website, an operator session or an orchestration server must not, by itself, become authority to move institutional assets.
We built ZKGuard's security architecture around one principle: proof before fund movement. The architecture separates the system that requests a transfer from the people who authorize it, the computation that verifies policy and the signing controls that can release it. Each boundary answers a different question. None can safely stand in for the others.
The ambition is not another green approval badge. It is a fund-movement process in which a compromised application cannot simply claim that the checks passed, change the destination after approval or bypass the policy through a second signing route.
Where DNA Protocol's zkPrivacy fits
The organizing idea behind zkPrivacy is straightforward: a verifier should receive the evidence needed for a decision, without automatically receiving every sensitive input behind it. ZKGuard applies that idea to a particularly consequential decision: whether an institution should authorize movement of its assets.
An institution may need to establish that an approver belongs to an authorized group, that a destination belongs to an approved set, or that a transfer satisfies a private operational rule. Publishing the entire approval directory, counterparty list and internal policy manual is not the only way to make those conditions verifiable. A suitably constructed zero-knowledge proof can establish a precisely defined relationship while keeping selected witness data undisclosed to the verifier.
There are three distinct jobs in the ZKGuard architecture:
- zkPrivacy supplies the design principle: disclose the necessary conclusion and bind it to the right statement, rather than centralize unnecessary private evidence.
- ZKGuard supplies the authorization design: connect policy commitments, independent approvals, proof verification and the custody decision for a particular request.
- The XRP Ledger supplies transaction authorization and settlement: the resulting transaction must satisfy the account's actual signing rules and receive a validated outcome.
DNA Protocol's zkProof interface describes supported proof verification separately from Testnet anchor confirmation. Its Transparency interface distinguishes public ledger data, package structure and the limits of an inspection. ZKGuard carries that same evidence-first discipline into its security architecture. A matching hash is not automatically a valid proof; a valid proof is not automatically permission to sign; a submitted transaction is not automatically settled.
These are related product principles, not a claim that the services already share a production custody backend. A proof accepted by an identity workflow must not automatically authorize a treasury payment. The program, statement, policy and execution context have to match the specific use case.
The authorization pipeline
ZKGuard's architecture separates six responsibilities so that no application response silently becomes the final authority over funds.
1. Define an institution-owned policy
The policy identifies allowed assets and destinations, required approval roles, spending constraints, permitted transaction types and exceptional procedures. A versioned commitment identifies the exact policy being applied. The institution must control who can approve a policy change, when that change takes effect and which signers accept it.
2. Construct one unambiguous request
The request describes the intended operation in a canonical, machine-verifiable format. Amounts, asset identities, addresses, destination tags, network context, expiry and the policy version cannot be left as editable presentation fields. Human-readable review and the bytes ultimately signed must refer to the same action.
3. Obtain genuinely independent approvals
Approvers review the request through controls that do not all depend on the compromised application. Their approval evidence must bind to the request, not merely to a login session or a generic instruction to release funds. Different usernames on the same compromised device are not independent security boundaries.
4. Prove the policy decision
The prover evaluates the authorized statement using the required private witness. Its output must connect the request, policy, approvals and accepted state. The prover is not granted permission to choose a weaker policy or silently substitute another request.
5. Verify at the signing boundary
The signing side independently verifies the proof, interprets its authenticated outputs and checks them against the transaction it is being asked to sign. A positive result from the exchange's own server is insufficient. Missing evidence, an unknown program, stale state or a mismatched transaction must stop this path.
6. Submit and reconcile
Only the permitted signing combination releases the transaction. Its identifier, authorization evidence and resulting ledger outcome then become part of the operational record. Failed, expired and uncertain submissions remain distinct from successful settlement.
This separation is the central benefit. The application can organize work without holding unilateral authority over the treasury. The institution can examine the policy and signing boundaries instead of trusting a single hosted service to behave correctly.
What the proof actually proves
A useful authorization proof does not say, "this exchange is secure." It establishes a much narrower statement: the approved policy program accepted this request against specified commitments and state, using witness material that satisfies the program's constraints.
Public inputs and private witness
The verifier needs enough authenticated information to identify what was proved. In this architecture, that includes the request commitment, policy version, relevant state commitment, validity window, permitted action and proof-program identity. The private witness can contain approval evidence, membership paths and policy details that do not need to be disclosed to every verifier.
Membership checks require a trustworthy reference. Proving that a destination belongs to a list is meaningless if the attacker can choose the list. Likewise, a valid approval signature is not enough if the signing identity is not authorized for that role under the accepted policy. Commitments must therefore be authenticated by the institution's governance process and pinned by the verification boundary.
The program must check distinct approvers and required roles, not simply count signature objects. It must reject duplicate evidence, wrong-domain approvals, invalid encodings and expired authorization. Arithmetic must be bounded: an overflowing sum or an incorrectly scaled asset amount must never turn a failed limit check into a pass.
Verify the program, not just a proof-shaped object
Established proof systems provide implementation foundations, but they do not supply the application's policy automatically. For example, RISC Zero's zkVM documentation describes proofs of program execution. Its receipt API requires the verifier to supply the expected program image identifier and exposes authenticated public outputs. That illustrates the distinction between a mathematically valid proof and a proof of the particular program an institution trusts.
RISC Zero is an example of an existing implementation category, not a statement that ZKGuard currently runs that stack. A selected circuit or zkVM must have a reviewed version, pinned verification material, an appropriate privacy configuration and a documented upgrade process. A prover-supplied label such as "approved version" cannot be its own authority.
Even after cryptographic verification succeeds, the application must inspect the proved result. A valid proof of a program that returned "deny" is not an authorization. Neither is a successful proof for a different request. Verification must establish both computational validity and the exact authorized meaning of the output.
Binding approval to one transaction
The most important object in the workflow is not the dashboard's transfer summary. It is the relationship between the request that was approved and the transaction that can actually execute.
A robust request envelope needs an application domain and version, institution and account identity, ledger context, transaction type, exact asset identity, amount semantics, destination and tag, fee constraints, policy commitment, nonce and expiry. Domain separation prevents approval evidence intended for one workflow from being interpreted as authorization in another.
For an issued asset, a ticker alone is not an identity. The currency and issuer must be bound together. For XRP, the implementation must handle the ledger's native units without rounding away meaningful value. A friendly display such as "25,000 units" is useful for illustration; production signing requires the exact encoded asset and amount.
The XRPL common-fields reference defines transaction ordering and expiry fields, including Sequence, TicketSequence and LastLedgerSequence. It also specifies that NetworkID is omitted on Mainnet and other low-ID networks. An application-level network domain is therefore not permission to insert an invalid field into a Mainnet transaction. Network isolation, key separation and cross-network replay testing remain necessary.
Freeze intent before signatures exist
Every signer must reconstruct and review the same final transaction semantics. If a coordinator changes the destination, currency issuer, fee or another authorized field after approval, the original evidence must no longer authorize signing. Use the ledger's established serialization and signing conventions, not a home-grown JSON-string hash that changes with whitespace or key order.
Some fields may become available only near signing time. The design must make that explicit. Either approve the final transaction, or approve narrowly specified constraints and require the signer to prove that the final transaction satisfies them. Quietly auto-filling an unrestricted field after authorization creates a gap between human intent and executable behavior.
Treat payment semantics precisely
An amount label is not a complete description of every XRPL payment. Cross-currency paths, send limits, delivery limits and partial-payment flags affect the operation's meaning. The partial-payments documentation explains why integrations must reconcile the actual delivered amount from metadata rather than crediting the requested amount blindly. The sender's spending exposure and recipient's receipt are different policy questions.
The integration should accept only explicitly supported transaction forms and reject unfamiliar fields or combinations until they have been reviewed. New ledger features are not automatically safe because an SDK knows how to serialize them.
A compromised-exchange walkthrough
Consider an illustrative treasury replenishment policy: two independent approval roles, an approved operational destination and a per-transfer ceiling. The values are examples, not recommended financial limits. The following outcomes describe the architecture's acceptance criteria, not a report of a live attack blocked by the public workspace.
The attacker controls the application server
The attacker can alter the displayed request, submit arbitrary jobs and return a forged "policy passed" response. They try to replace the operational destination with an address they control.
The independent approval path must display and authorize the actual destination and asset. The prover must evaluate the request against an institution-approved policy commitment. The signing boundary must verify those commitments and compare the authorized request with the transaction it will sign. An unapproved destination or substituted request should fail before a qualifying signature set can be assembled.
This is why an isolated verification boundary matters. If the signer trusts the application's boolean response, the attacker has already reached the authority it was supposed to constrain.
The attacker steals one approval credential
A stolen credential must not manufacture a second independent approval, satisfy a different role or authorize a policy update on its own. Deduplication, role checks, revocation and organizational separation all matter. Thresholds must be designed for the stated compromise assumptions rather than selected because a small number is convenient.
If the attacker acquires an entire authorizing quorum or another unrestricted spending key, the assumption is different. A ZK proof does not make compromised authorized parties honest. The architecture must name that residual risk instead of stretching a single-server-compromise property into a promise against every attack.
The attacker attacks the controls instead of the payment
Changing the policy root, enrolling a new approver, replacing a verifier or weakening a signer list can be as consequential as submitting a malicious payment. Those operations need their own authorization and audit requirements. A tightly checked payment path with an unrestricted administrator console is not a tightly controlled treasury.
The useful claim is specific: compromise of the exchange's application layer alone must be insufficient to authorize a protected transfer, provided the independent signing and governance boundaries remain intact. That is a property to demonstrate through adversarial testing, not a slogan to assume.
State, replay and concurrent requests
Authorization has a lifetime. A request that was valid yesterday may be invalid after an approver is revoked, a policy is replaced, a destination is removed or a spending allowance is consumed.
The verification boundary needs an authenticated, current view of the policy epoch and relevant state. It must not accept whichever historical commitment a malicious prover finds convenient. State checkpoints need an identified authority, rollback protection and a defined rule for advancement. An unauthenticated database row cannot become trusted merely because its hash appears in a proof.
One approval must not become many transfers
A request nonce identifies a single authorization attempt within its intended domain. Once used, it must not authorize another transaction. The implementation needs an atomic transition from eligible request to reserved or consumed authorization, with recovery rules for failures. The exact sequence depends on the signing model, but a crash or timeout must not restore a previously usable permission accidentally.
Expiry must be checked at the point that matters. The institution's policy expiry and the transaction's ledger expiry are related but different checks. Once a valid transaction has been signed, a later dashboard cancellation does not erase those signatures. The design must limit that exposure and distinguish unsigned cancellation from an unresolved signed transaction.
Proving a limit is not the same as managing a budget
Suppose a daily allowance is 50,000 illustrative units and two concurrent requests each seek 30,000. Each request can pass an isolated per-request calculation while their combined total exceeds the allowance. A proof cannot solve that race if both requests are allowed to rely on the same stale budget state.
The custody system needs consistent reservations or another reviewed state-transition mechanism across every path that spends against the limit. It must reconcile pending, validated, failed and expired operations before releasing reserved capacity. Reservations cannot simply disappear when a process restarts.
This is a systems-engineering problem as well as a cryptographic one. The proof establishes a statement about the state it was given; the surrounding authorization system must establish that this is the state the institution is entitled to use now.
Recovery, upgrades and policy changes
Recovery is part of the security model, not an exception to it. A secret override that can move funds without the normal controls becomes another route an attacker can target.
The ZKGuard design calls for institution-controlled recovery authority, independently approved recovery destinations and a documented process for outages, key loss and verifier incidents. Recovery must remain usable without handing a hosted service unilateral power over funds. Its trust assumptions and emergency access must be explicit.
A delay is only as strong as the component enforcing it. A timer in a dashboard is not a ledger-enforced restriction. If a signing quorum can bypass a custody-layer delay by producing a different valid transaction, the deployment cannot describe that delay as an unconditional on-chain guarantee.
Governance changes can alter the protection model
XRPL's SignerListSet transaction can replace an account's signing configuration, while AccountSet changes account settings. The same care applied to payments must therefore extend to operations that change who can authorize payments. A successful signer rotation is not complete until the resulting ledger state is verified.
Proof-program upgrades create a similar obligation. Approving a new circuit, program identifier or verification key changes which statements the system will accept. The review must consider pending authorizations, old policy versions, downgrade attempts and the conditions under which the previous verifier remains permitted.
Rollback is not automatically a safe recovery strategy. Restoring an older database or software image can revive revoked approvers, consumed nonces or weaker policy definitions. A recovery drill must test those scenarios, not merely show that a process can start again.
The governing principle is continuity of authority: recovery and upgrades may restore service, but they must not silently transfer control away from the institution or remove the safeguards on which its protection depends.
What privacy protects, and what it does not
The privacy objective is selective disclosure, not invisibility. A verifier may need to know that the required approval conditions were satisfied without receiving the full approval roster, complete allowlist or every internal policy value.
That does not mean every participant is blind. The component generating a proof generally needs access to its witness. RISC Zero's security model, for example, explicitly distinguishes privacy from the verifier from access by the prover. The institution must decide where private evidence is processed and which operators can access it. Sending witness data to a remote prover is a data-sharing decision, not something zero knowledge automatically makes harmless.
Private approval membership also differs from the ledger's visible signing information. Ordinary public XRPL transactions expose information that can include account identities, amounts, timing and signatures. A private business-policy proof must not be presented as making that settlement confidential.
Commitments require care too. Hashing a predictable value does not necessarily hide it from guessing. Low-entropy policy inputs may need a properly designed hiding commitment rather than an unsalted public hash. Public outputs and error messages should be minimized so repeated queries do not reveal more than the intended decision.
Appropriate cryptography does not remove the need for access control, retention limits and incident handling. Private witnesses and signing secrets should not appear in diagnostics, analytics, exports or support screenshots. The proof pipeline should receive the evidence it needs, not the institution's private signing keys.
The practical benefit of zkPrivacy is a narrower information footprint: fewer parties need the raw evidence to check a decision. That benefit must be evaluated alongside the actual prover, verifier, logs and ledger data, rather than inferred from the presence of the letters "ZK."
How the architecture helps institutions
Exchanges: contain the blast radius
Separating application access from spending authority can limit what a compromised web or orchestration layer is capable of doing. The architectural target is to prevent an application compromise from becoming a direct route to a protected treasury account. It does not replace customer-account security, deposit accounting or controls over funds outside that account.
An exchange still needs sound handling of withdrawals, balances and settlement. Proof-based treasury authorization cannot repair an unrelated accounting bug after a customer has been incorrectly credited. The value is a stronger boundary at the movement of protected assets, not a substitute for the rest of the exchange's controls.
Custodians: make the authorization decision inspectable
A custodian needs to understand not only which keys signed, but which request, policy and approvals those keys were meant to represent. Linking the evidence to a precise transaction supports later review without forcing every reviewer to receive all underlying private inputs.
The audit record should distinguish the policy decision, proof-verification result, signing event, submission and final ledger result. These records answer different questions. Treating them as one generic "success" event hides the point where a failure actually occurred.
Institutional treasuries: preserve control while delegating operations
Operations teams can prepare requests while separate authority approves policy and releases signatures. That separation can support operational automation without giving the automation service unrestricted control over assets. The institution retains responsibility for the policy, the signing configuration and exceptional procedures.
The design also creates a concrete basis for procurement and integration review. Instead of asking whether a product is "secure," an institution can ask which compromised components it tolerates, which parties can authorize a transfer, how policy changes are controlled and what evidence demonstrates those properties.
Reviewers: separate evidence from assertion
A well-designed evidence package makes a narrow claim independently checkable. It does not automatically establish regulatory compliance, identity, solvency or the absence of every possible attack. Those conclusions require their own facts and assessment. Keeping the claim narrow makes the evidence more useful, not less valuable.
Evidence that makes protection credible
An architecture becomes a dependable control only when its implementation and operating procedures demonstrate the intended behavior. The important evidence is not simply that a valid request can complete. It is that the wrong requests cannot find another route through.
Cryptographic and policy tests
Tests must reject altered proofs, wrong program identifiers, substituted public outputs, unapproved policy commitments, duplicate approvers and stale authorization. They must exercise arithmetic boundaries, asset precision, invalid encodings and conflicting interpretations of a request. Development shortcuts and mock verification must be impossible to enable silently in a production signing path.
Custody and failure tests
Treat the coordinator as hostile: change destinations after approval, forge its success response, replay a request and call signing interfaces directly. Attempt policy downgrades, key changes and recovery flows. Partition services, interrupt proof generation and restart components between reservation and submission. The required outcome is either an authorized transition or a safe refusal, not an accidental bypass.
A review also needs the actual account configuration and a map of every authority path. The term "non-custodial" cannot substitute for examining who controls signing keys, recovery access, verifier upgrades and delegated permissions.
Settlement reconciliation
XRPL's reliable transaction submission guidance distinguishes a provisional submission response from the authoritative result in a validated ledger. ZKGuard's integration requirements preserve that distinction. An uncertain result must be reconciled before another attempt could create a duplicate financial action.
The retained evidence should link the authorized request to the submitted transaction hash, validation result and relevant execution metadata. A transaction that failed, expired or remains unresolved must not be reported as completed merely because a signing or network call returned successfully.
Performance and operational evidence
An institutional integration needs measured proof-generation time, verification latency, signing throughput, resource limits and recovery behavior under its actual policy workload. A benchmark for a different program does not establish these properties. Nor does an audit of a cryptographic dependency automatically audit the surrounding custody integration.
Independent review should cover the complete chain: policy interpretation, proof construction, verifier configuration, signing isolation, ledger integration and recovery. Findings need remediation and retesting. The resulting claim should name the tested scope and assumptions, with no universal promise that every type of hack is impossible.
A stronger boundary for institutional funds
ZKGuard's architectural contribution is the connection between private verification and enforceable authority. zkPrivacy provides the principle of proving what matters without exposing everything. ZKGuard organizes that principle around one transaction, one policy context and a custody boundary that must respect the result.
The design is valuable precisely because it asks harder questions than whether a user is logged in or a signature is syntactically valid. Was the right request approved? Under the right policy? By the right independent authorities? Against current state? Can any other key, administrator or recovery route bypass that decision?
For institutions and exchanges, the objective is a clear separation between operating the system and controlling the funds. That is the standard the implementation must meet and the evidence must demonstrate.
Proof before movement. Private evidence where possible. Institutional authority where it matters.
Explore the ZKGuard policy workspace, review its published security boundaries, or examine DNA Protocol's zkProof and Transparency interfaces for the related evidence-first approach. Use fictional inputs in the policy illustration; do not enter treasury information or wallet secrets.
Cover artwork generated with Kling Image 3.0 Omni. Conceptual illustration, not a depiction of deployed custody infrastructure. Technical sources and public product scope checked on 30 October 2026.