How Afi Protocol Uses ZK Proofs for Reserves

[greesmaster]

How Afi Protocol Uses Zero-Knowledge Proofs to Verify Reserves

Tokenized real-world assets create a basic transparency challenge. Their supply is visible on a blockchain, but the reserves supporting them may be distributed across custodians, financial accounts, investment positions, or other systems that cannot be made fully public.

Users still need evidence that the reserves exist and that their combined value is sufficient to support the relevant on-chain liabilities. Publishing every individual balance is not always appropriate. Detailed records can reveal account structures, custodian allocations, counterparties, internal treasury movements, and commercially sensitive information.

Afi Protocol uses zero-knowledge proofs to resolve this conflict. Its verification architecture can prove that private reserve values add up to a disclosed total without publishing the value of each individual position.

The public receives a mathematically verifiable result, while the underlying breakdown remains hidden behind cryptographic commitments. This allows Afi Protocol to provide meaningful transparency without requiring issuers to expose their complete financial infrastructure.

The result is not absolute secrecy and not unrestricted disclosure. It is selective verification: users can confirm the financial statement that matters while private inputs remain confidential.

Why Reserve Verification Requires Privacy

A tokenized asset may be backed by a single reserve account, but institutional structures are often more complex.

An issuer may hold assets through several custodians. Reserves may include cash, short-duration financial instruments, tokenized positions, commodities, or assets deployed across multiple strategies. Liabilities may also be divided among different contracts, networks, redemption queues, or user accounts.

A complete reserve breakdown could reveal:

The amount held with each custodian;

Internal allocation strategies;

Banking and settlement relationships;

Concentrated counterparty exposure;

Treasury movements;

Individual client or account balances;

Commercially sensitive portfolio decisions;

Security-relevant information about asset locations.

Some of this information may be useful to professional auditors under confidentiality agreements. It does not necessarily need to be published permanently on a public blockchain.

At the same time, users should not be expected to accept a reserve total simply because the issuer reports it.

A statement such as “the product holds $200 million in reserves” creates several questions. Were the individual balances actually included? Were they added correctly? Was one balance counted twice? Were liabilities calculated using the same reporting period? Was the displayed total changed after the underlying records were processed?

Zero-knowledge proofs help answer the mathematical part of these questions without disclosing each private value.

What a Zero-Knowledge Proof Means

A zero-knowledge proof allows one party, commonly called the prover, to demonstrate that a statement is true without revealing the private information used to establish it.

In the context of reserve verification, the statement may be:

The private reserve balances included in this dataset sum to the publicly disclosed reserve total.

The private information consists of the individual balances. The public output consists of the total and the proof.

A verifier does not need to see every reserve entry. It checks the proof using a verification key and determines whether the required mathematical rules were satisfied.

This is different from asking users to trust a server response. A conventional API could return any number chosen by its operator. A valid zero-knowledge proof demonstrates that the public result is consistent with private inputs processed according to a predefined circuit.

The circuit is the mathematical program defining what must be proven. It specifies the relationships that must hold between private inputs and public outputs.

For Afi Protocol, zero-knowledge proofs form one part of a broader system that also includes data commitments, Merkle trees, isolated computation, hardware attestation, and independent validation.

The Difference Between Private Inputs and Public Signals

Understanding Afi Protocol’s ZK model requires separating private inputs from public signals.

Private inputs

Private inputs are the underlying values that should not be revealed publicly. These may include individual reserve balances or separate liability amounts.

For example, an issuer could have reserves distributed as follows:

A private amount with Custodian A;

A private amount with Custodian B;

A private amount in another eligible position.

The exact values can remain hidden.

Public signals

Public signals are values that the proof intentionally exposes. In reserve verification, the public signal may be the total reserves calculated from all eligible private balances.

The proof confirms that the hidden inputs genuinely produce this public total.

The same principle can be applied to liabilities. Individual obligations can remain private while the aggregate liability figure becomes public and verifiable.

Afi Protocol can therefore disclose the numbers required to evaluate reserve coverage without revealing the full financial breakdown behind them.

How Afi Protocol Generates ZK Reserve Proofs

Afi Protocol’s custom verification flow processes reserve and liability data inside a hardware-isolated environment. The system creates commitments for the individual data points, calculates aggregate totals, constructs a Merkle structure, and generates separate zero-knowledge proofs.

The process can be understood in several stages.

1. Reserve and Liability Data Enters the Verification Process

An integrated protocol provides the relevant reserve and liability data through the verification flow.

Reserve entries represent the assets supporting the tokenized product. Liability entries represent the obligations those assets are expected to cover.

The data must follow predefined rules. The integration should determine which reserves are eligible, which liabilities must be included, how values are represented, and what reporting time applies.

Zero-knowledge technology cannot decide whether an asset is economically suitable as collateral. It proves the calculation defined by the circuit. The quality of the verification therefore begins with the quality of the data policy.

2. Each Individual Value Receives a Cryptographic Commitment

Afi Protocol creates cryptographic commitments for the individual reserve and liability data points.

A commitment acts like a sealed digital representation of a value. It binds the system to that value without publicly revealing it.

Two properties are especially important.

First, the commitment is hiding. An observer should not be able to determine the original balance merely by viewing its commitment.

Second, the commitment is binding. The party creating it should not be able to replace the original balance with a different value while claiming that the commitment remained unchanged.

This allows the system to work with a fixed private dataset. The values remain confidential, but they cannot be silently modified after being committed.

3. Commitments Are Organized Into a Merkle Tree

The individual commitments are combined into a Merkle tree.

A Merkle tree repeatedly hashes pairs of data until it produces one final value known as the Merkle root. This root functions as a cryptographic fingerprint of the complete committed dataset.

If one reserve value changes, its commitment changes. That modification affects the hashes above it and ultimately produces a different Merkle root.

The root therefore binds the final proof to the specific dataset used in the calculation.

This is important because a reserve total alone does not describe which entries contributed to it. The Merkle structure creates a verifiable relationship between the private components and the final dataset fingerprint.

It can also support selective disclosure. An authorized auditor may examine a particular entry and verify that it belongs to the committed dataset without requiring every other private balance to be revealed.

4. Private Balances Are Summed Inside the ZK Circuit

The proof circuit checks that the individual private balances add up to the public total.

Suppose an issuer has several eligible reserve positions. The circuit receives these amounts as private inputs and performs the required addition.

The resulting aggregate is exposed as a public signal.

The verifier can confirm that some valid set of committed private values produced the disclosed total. It does not learn how the total is distributed among the positions.

A public reserve figure of $200 million could represent two custodians, multiple accounts, or a larger set of eligible assets. The proof establishes that the hidden amounts sum to $200 million without displaying the balance held in each location.

The same process is performed for liabilities. Private liability entries are summed, and their total is made public.

Once both totals are available, users or applications can evaluate reserve coverage:

Verified reserves ÷ verified liabilities

The ZK proof confirms the arithmetic behind the disclosed totals. It does not, by itself, determine what ratio should be considered acceptable for a particular product.

Why Afi Protocol Uses Separate ZK Proofs

Afi Protocol’s described custom attestation structure uses three separate Groth16 proofs rather than one combined proof.

These are:

A Merkle root proof;

A reserve-sum proof;

A liability-sum proof.

Each proof establishes a different property.

Merkle root proof

This proof confirms that the Merkle root was correctly derived from the underlying data commitments.

It establishes the integrity of the committed dataset. Individual values cannot be added, removed, or changed without affecting the root.

Reserve-sum proof

This proof confirms that the private reserve values sum to the publicly disclosed reserve total.

It reveals the aggregate amount but not the individual balances.

Liability-sum proof

This proof performs the equivalent calculation for liabilities. It confirms that hidden liability values produce the disclosed public liability total.

Separating the proofs makes the system more modular. A smart contract may focus on the reserve and liability totals when evaluating collateralization. An auditor may place greater emphasis on the Merkle root and the integrity of the committed dataset.

The proofs can be verified independently, but the complete verification process expects them to agree with the same underlying state.

Why Groth16 Is Suitable for On-Chain Verification

Afi Protocol uses Groth16 proofs in its custom proof flow.

Groth16 is a zero-knowledge proof system known for producing compact proofs and relatively efficient verification. The proof size does not grow proportionally with the number of private balances included in the calculation.

This property matters for blockchains because on-chain computation is limited and costly. Publishing every balance and asking a smart contract to repeat the entire calculation would reduce privacy and increase execution requirements.

Instead, the computationally intensive proof generation occurs outside the blockchain. The smart contract performs the smaller verification operation.

Afi Protocol’s proofs use a curve supported by EVM verification infrastructure. Solidity verifier contracts can check the proofs and confirm that their public signals match the claimed totals.

This makes the resulting reserve intelligence usable by EVM-compatible applications, rather than limiting it to a static off-chain report.

How Afi Protocol Prevents Proofs From Being Mixed

A valid ZK proof establishes that a mathematical relationship is correct. Afi Protocol also needs to demonstrate that the proof corresponds to the same data processed inside its isolated execution environment.

Its architecture addresses this through cross-checking between the ZK proofs and the hardware attestation.

The isolated environment calculates the reserve total, liability total, and Merkle root. These values are bound into the hardware-signed attestation.

The ZK system independently proves the same public values.

During verification, the system checks that:

The hardware-attested reserve total matches the ZK reserve signal;

The hardware-attested liability total matches the ZK liability signal;

The hardware-attested Merkle root matches the root confirmed by the ZK proof.

If any values differ, the combined proof is rejected.

This prevents someone from taking a valid hardware attestation produced from one dataset and combining it with valid ZK proofs produced from another.

The two verification mechanisms cover different risks. The hardware attestation provides evidence about the execution environment and code. The zero-knowledge proofs provide mathematical evidence about the hidden values and public totals.

What Users Can Verify Without Seeing Individual Balances

A valid Afi Protocol proof can allow users or applications to verify several important facts.

They can confirm that the private reserve entries sum to the published reserve amount.

They can confirm that the private liability entries sum to the published liability amount.

They can confirm that the individual data commitments were included in the Merkle root used by the proof.

They can confirm that the ZK proofs have not been altered without invalidating verification.

They can also compare reserves and liabilities to evaluate the reported coverage ratio.

This provides more assurance than a simple issuer statement while avoiding the need to make every financial position public.

Users still need clarity about what the inputs represent. A mathematically correct total is useful only when the reserve eligibility and liability rules are economically meaningful.

Key Benefits of ZK-Based Reserve Verification

Confidentiality for Issuers

Individual account and custodian balances can remain private. This reduces unnecessary exposure of financial and operational data.

Verifiable Aggregate Figures

Users do not have to accept the aggregate totals solely on trust. The ZK proofs demonstrate that the hidden inputs produce the public results.

Efficient On-Chain Use

Compact Groth16 proofs can be checked by EVM-compatible smart contracts without publishing or processing the entire private dataset on-chain.

Reduced Data Exposure

Only information required for public analysis needs to be revealed. Sensitive source records do not become permanently available on a public ledger.

Support for Selective Disclosure

Cryptographic commitments and Merkle structures can allow a specific entry to be checked by an authorized party without exposing the full reserve composition.

Better DeFi Integration

Verified totals can become inputs for dashboards, collateral assessments, exposure limits, minting controls, or other application-specific risk systems.

Risks and Important Limitations

Zero-knowledge proofs verify calculations, not every aspect of financial reality.

The first limitation is source-data integrity. A correct proof based on incomplete or inaccurate inputs can still produce a misleading result. Reliable custodians, data providers, issuer controls, and reconciliation procedures remain necessary.

The second limitation is reserve eligibility. The proof can show that included values add up correctly, but it does not automatically establish that every included asset is liquid, unencumbered, appropriately valued, or legally available to token holders.

The third limitation concerns liabilities. If important obligations are omitted from the private input set, the proof cannot identify them unless the verification design requires their inclusion.

Valuation is another risk. Reserve totals expressed in U.S. dollars may depend on market prices, pricing sources, update frequency, and assumptions about less-liquid assets.

ZK proofs also do not guarantee redemption. Token holders may still face withdrawal periods, legal restrictions, issuer insolvency, custody problems, or insufficient immediate liquidity.

Technical risks remain in the circuits, implementation, proof-generation environment, verifier contracts, and protocol integrations. Audits and independent review are therefore still important.

Afi Protocol’s ZK architecture makes selected reserve claims independently verifiable. It does not turn those claims into a complete guarantee of financial safety.

Why ZK Reserve Proofs Matter for Project X and HyperEVM

Project X provides an environment for trading and liquidity activity within HyperEVM. HyperEVM allows EVM-compatible smart contracts to participate in the broader Hyperliquid ecosystem.

If tokenized real-world assets are used in such applications, protocols may need to evaluate off-chain backing without requiring issuers to publish institutional records.

Afi Protocol’s Groth16 proofs are relevant because they can be verified through EVM-compatible contracts. A HyperEVM application could potentially validate public reserve and liability totals while the underlying position-level data remains confidential.

For Project X, this could support clearer reserve information around RWA-based liquidity markets. Users could assess verified backing alongside price, liquidity depth, and trading activity.

Other HyperEVM applications could potentially use proof results when defining collateral eligibility, minting limits, vault exposure, or attestation freshness requirements.

This is an architectural use case, not a claim of a confirmed direct integration. Project X provides market infrastructure, HyperEVM provides programmable execution, and Afi Protocol provides privacy-preserving financial verification that can be adapted to EVM-based applications.

FAQ

What does a zero-knowledge reserve proof confirm?

It can confirm that private reserve values satisfy a defined calculation, such as summing to a publicly disclosed total, without revealing each individual value.

Why does Afi Protocol hide individual balances?

Detailed balances may reveal confidential custodian relationships, account structures, allocation strategies, or other sensitive financial information that is unnecessary for public reserve analysis.

What information remains public?

The public information can include verified reserve totals, liability totals, a Merkle root, proof metadata, timestamps, and other signals required for verification.

What is a cryptographic commitment?

A commitment binds the prover to a specific private value without revealing that value publicly. Changing the value would produce a different commitment.

Why does Afi Protocol use a Merkle tree?

The Merkle root creates a single cryptographic fingerprint for the complete set of committed reserve and liability data. Any modification to an included entry changes the root.

Can a ZK proof detect false information from a custodian?

Not automatically. The proof verifies the defined calculation over the supplied inputs. The authenticity and completeness of off-chain source data require separate controls.

Can Afi Protocol proofs be used on HyperEVM?

Groth16 proofs designed for EVM verification can technically be checked by compatible verifier contracts. A specific HyperEVM application must still implement and secure the integration.

Verify the Total Without Exposing the Breakdown

Reserve transparency should allow users to test meaningful financial claims. It should not require issuers to publish every account balance, custodian allocation, or confidential portfolio detail.

Afi Protocol uses zero-knowledge proofs to separate these two requirements. Individual values remain private, while cryptographic proofs establish that they produce the disclosed reserve and liability totals.

Before relying on any ZK-based Proof-of-Reserve result, examine the complete verification scope. Determine which assets and liabilities were included, how valuations were produced, when the proof was generated, and what legal or liquidity risks remain outside the circuit.

Zero-knowledge technology can prove that the numbers add up without showing every number. The strength of the final assurance still depends on whether the right data was included and whether the verified statement reflects the real economic structure of the tokenized asset.