How Data Travels From a Custodian to an Afi Protocol Smart Contract
Tokenized assets depend on two separate information systems. The blockchain records token supply, wallet balances, transfers, and smart contract activity. The underlying reserves, however, may remain inside custody accounts, banking platforms, fund administration systems, or institutional portfolio records.
Afi Protocol connects these environments through a structured Proof-of-Reserve process.
Reserve and liability information is submitted through an authenticated data channel, validated by a relay server, transferred into a hardware-isolated execution environment, converted into cryptographic commitments, and used to generate zero-knowledge proofs and a hardware attestation. The resulting proof package can then be independently validated before verified totals are written to a smart contract.
The smart contract does not receive confidential custody records. It receives cryptographic evidence and public outputs proving that the approved calculations were completed.
In simplified form, the path is:
Custodian data → authenticated request → relay validation → isolated computation → commitments and proofs → independent verification → smart contract update.
This architecture allows Afi Protocol to publish verifiable reserve information without placing issuers’ complete financial records on a public blockchain.
Why Custodian Data Cannot Be Sent Directly On-Chain
A custodian may hold the records needed to confirm an issuer’s reserves. These records can show balances, asset positions, account ownership, valuations, settlement activity, and other information relevant to backing.
Sending the complete dataset directly to a blockchain would create several problems.
First, public blockchains are transparent. Information written on-chain can usually be inspected permanently by anyone. Institutional records may contain account identifiers, counterparties, individual asset positions, internal strategies, and commercially sensitive details.
Second, smart contracts cannot interpret arbitrary financial documents. They require standardized, machine-readable values and predefined calculation rules.
Third, on-chain storage can be expensive. Publishing every position and supporting record would be inefficient when the contract may only need verified reserve and liability totals.
Fourth, raw data does not prove its own integrity. A smart contract needs evidence that the values were processed by the expected code and were not modified during the verification process.
Afi Protocol therefore separates private inputs from public outputs. Detailed data is processed off-chain inside a protected environment, while cryptographic proofs allow the result to be checked on-chain.
The Main Participants in the Data Path
Understanding the process is easier when the roles are separated.
The custodian or authorized data source
The original reserve information may come from a custodian, issuer, administrator, financial institution, asset manager, or another approved source. This participant has access to the underlying records.
A custodian is particularly important because it can confirm assets held on behalf of the issuer or supporting legal structure. However, not every verification must rely on a single custodian. Some products may require information from several systems.
The protocol submitting the request
An issuer or integrated protocol prepares reserve and liability data in the format expected by Afi Protocol. It sends the verification request through the designated API.
The submitted information may contain individual values rather than only a self-reported total. This allows the proof-generation system to calculate the total independently.
The relay server
The relay server receives the request, authenticates it, applies rate limits, checks its structure, and forwards it to the protected execution environment.
Its role is intentionally limited. It manages communication but does not perform the sensitive cryptographic calculation.
The Secure Proof Node environment
Sensitive computation occurs inside an AWS Nitro Enclave used by Afi Protocol’s proof-generation system. The enclave is isolated from the ordinary host environment.
Inside it, the approved code processes the inputs, creates commitments, calculates totals, generates zero-knowledge proofs, and produces a hardware-backed attestation.
Independent verifiers
A protocol, auditor, backend service, user interface, or browser can validate the resulting proof package. Verification does not require unrestricted access to the original reserve breakdown.
The smart contract
After the required checks pass, verified totals and relevant proof outputs can be submitted to an EVM-compatible smart contract. The contract validates the zero-knowledge proofs, updates its state, and can emit events for other applications.
Step 1: Reserve and Liability Data Is Collected
The journey begins with information from the systems that record the underlying assets.
Reserve data may describe:
-
Cash held in authorized accounts
-
Custodied securities
-
Tokenized financial positions
-
Commodities or commodity-linked claims
-
Fund interests
-
Credit assets
-
Other eligible backing
Liability data represents the claims that must be supported. Depending on the product, this can include outstanding token supply or another defined set of obligations.
The verification scope must specify which records count. A Proof-of-Reserve calculation is only meaningful when the system clearly defines eligible reserves and included liabilities.
The data also needs consistent formatting. Values may need to be normalized into the same currency unit and represented as integers rather than floating-point numbers. This prevents rounding ambiguity during proof verification.
For dollar-denominated totals, Afi Protocol can represent values in minor units with fixed precision. The same integer value is then used across the protected computation, hardware attestation, and zero-knowledge proofs.
Step 2: The Request Is Sent Through an Authenticated API
The protocol sends reserve and liability data to the Afi Protocol relay server through an API request.
Authentication is necessary because the proof-generation system must distinguish approved sources from unauthorized submissions. Without it, an unknown participant could attempt to generate an apparently legitimate proof from fabricated values.
The request also needs identifiers and metadata that connect it to the correct feed and verification event. These can include:
-
Feed identifier
-
Proof identifier
-
Verification timestamp
-
Reserve entries
-
Liability entries
-
Optional reference to the previous proof
-
Other integration-specific information
An API request does not itself establish that the source records are economically accurate. Authentication shows that the submission came through the expected channel. The reliability of the custodian and upstream data system remains part of the broader trust model.
Step 3: The Relay Server Validates the Request
The relay server performs initial operational checks before forwarding the data.
Its functions include authentication, rate limiting, and request validation. It can reject malformed, unauthorized, incomplete, or improperly structured submissions before they reach the proof generator.
This separation is important for security.
The relay server is exposed to network requests, so it must handle ordinary communication risks. The isolated proof environment should not be directly exposed in the same way.
At the same time, the relay is not trusted with the sensitive calculation. It does not determine the verified totals or generate the core cryptographic evidence.
Keeping the relay relatively simple reduces the amount of code and infrastructure that must handle confidential computation.
Step 4: Data Enters the Hardware-Isolated Environment
After validation, the relay forwards the request into an AWS Nitro Enclave through a secure communication channel.
The enclave is separated from the standard host environment. Its design restricts ordinary administrative access, external networking, and direct inspection of the computation.
This isolation serves two purposes.
First, it protects financial data. The host operator should not be able to read confidential reserve positions simply because it manages the surrounding infrastructure.
Second, it protects execution integrity. The enclave can later attest to the exact code and system image used to process the request.
The data is not sent into the enclave merely for storage. It is used to execute an approved verification program and produce a limited set of outputs.
Step 5: Every Data Point Becomes a Cryptographic Commitment
Inside the enclave, Afi Protocol creates cryptographic commitments for the individual reserve and liability values.
A commitment works like a sealed fingerprint of a value. It binds the proof to that value without requiring the value itself to be disclosed publicly.
These field commitments are organized into a Merkle Tree. Repeated hashing combines all leaves into a single Merkle root representing the complete dataset.
If any committed field is altered, removed, or replaced, the resulting root changes.
This gives the verification process a strong integrity property. The reserve total, liability total, hardware attestation, and zero-knowledge proofs can all be bound to the same underlying dataset.
The Merkle root does not prove that a custodian’s original statement was truthful. It proves that the data used during the calculation remains cryptographically consistent throughout the proof package.
Step 6: Reserve and Liability Totals Are Calculated
The enclave independently calculates total reserves and total liabilities from the submitted values.
This is stronger than accepting a single total claimed by the issuer. The system can verify that the individual hidden values genuinely produce the public aggregate.
The calculation follows the approved logic encoded in the proof generator. Depending on the integration, that logic may define:
-
Which fields are reserves
-
Which fields are liabilities
-
How values are normalized
-
Which entries are included
-
How totals are calculated
-
How previous proofs are linked
-
Which public outputs are permitted
A calculation can be cryptographically correct but economically incomplete if important liabilities were omitted before submission. Clear verification scope and reliable source integrations therefore remain essential.
Step 7: Three Zero-Knowledge Proofs Are Generated
Afi Protocol generates separate Groth16 zero-knowledge proofs rather than relying on one undifferentiated proof.
Merkle root proof
This proves that the Merkle root was calculated correctly from the individual field commitments.
It establishes that every committed data point contributed to the final dataset fingerprint.
Reserves proof
This proves that the hidden individual reserve values sum to the published reserve total.
The verifier can confirm the total without learning the complete distribution of assets among custodians or accounts.
Liabilities proof
This proves that the hidden liability values sum to the published liability total.
Separating the proofs gives integrators flexibility. A smart contract may focus on total reserves and liabilities, while an auditor may also examine the integrity of the underlying commitment structure.
Groth16 proofs remain compact even when they represent many private values. This makes them suitable for EVM verification, where transaction size and computational cost matter.
Step 8: The Enclave Produces a Hardware Attestation
The isolated environment also creates a hardware-signed attestation.
This attestation answers a different question from the zero-knowledge proofs.
Zero-knowledge proofs show that the mathematics is correct. The hardware attestation helps establish that the expected code ran inside a genuine protected environment and produced the stated values.
The attestation includes measurements identifying the enclave image, kernel, and application code. Verifiers can compare these measurements with the expected configuration.
Afi Protocol also binds the Merkle root and calculated totals into the hardware-signed output. This means the attestation refers to those specific results rather than merely confirming that some application ran inside an enclave.
The hardware and mathematical proof systems are designed to be checked separately. Full verification requires them to agree.
Step 9: A Self-Contained Proof Payload Is Returned
The enclave’s output is assembled into a Proof Payload and returned through the API response.
This JSON payload contains the information required to verify the reserve result independently. Its sections can include:
-
Version and metadata
-
Feed and proof identifiers
-
Timestamp
-
Verified reserve total
-
Verified liability total
-
Merkle root and field commitments
-
Hardware attestation document
-
Certificate chain
-
Code measurements
-
Groth16 proofs
-
Zero-knowledge verification keys
-
Verification context
The payload is designed to be self-contained. A verifier does not need to contact Afi Protocol each time it checks the result or retrieve essential verification material from an external service.
This reduces dependency on a live API and allows verification in different environments, including a backend, browser, offline system, or blockchain contract.
Step 10: The Hardware Attestation Is Validated
Before relying on the result, a verifier can validate the TEE attestation off-chain.
The process checks the certificate chain from the enclave’s certificate to the embedded AWS Nitro root certificate. It also verifies the signature and compares the enclave measurements with the expected code configuration.
The verifier then confirms that the attestation binds the correct:
-
Reserve total
-
Liability total
-
Merkle root
-
Verification metadata
If the signature is invalid, the certificate chain is broken, or the code measurements do not match, the hardware verification should fail.
TEE attestation uses a signature format that is not natively efficient to verify through standard EVM functionality. It is therefore generally validated off-chain by protocols, auditors, or users.
Step 11: The Zero-Knowledge Proofs Are Validated
The Groth16 proofs can be checked independently using the verification keys contained in the payload.
Each proof must match its public signals.
The reserves proof must confirm the published reserve total. The liabilities proof must confirm the published liability total. The Merkle proof must confirm the committed dataset root.
A critical cross-check then compares the values verified by the zero-knowledge system with those sealed by the hardware attestation.
All values must match exactly.
This prevents an attacker from combining a valid hardware attestation generated from one dataset with a valid zero-knowledge proof generated from another.
If the totals or Merkle roots differ, the complete proof package must be rejected.
Step 12: Proofs Are Submitted to the Smart Contract
After the required checks, the zero-knowledge proofs and public outputs can be submitted to an EVM-compatible verifier contract.
The smart contract performs mathematical verification through Solidity verifier logic generated for the relevant circuits. It checks the Groth16 proofs and confirms that their public signals match the reserve and liability totals being submitted.
When all checks pass, the contract can update its on-chain state with the newly verified information.
That state may include:
-
Latest verified reserves
-
Latest verified liabilities
-
Collateralization status
-
Proof identifier
-
Verification timestamp
-
Current Merkle root
-
Previous-root relationship
The contract can also emit an event. Other contracts, indexers, dashboards, and risk systems can respond to the verified update.
No raw custody records are published during this process. Only proof data and approved public outputs reach the blockchain.
Step 13: The On-Chain Result Becomes Actionable
Once the verified totals are stored on-chain, they can support more than a public dashboard.
A Proof-of-Reserve vault may use them to calculate minting capacity. A protocol may require reserves to remain above liabilities before allowing additional issuance. Another application could monitor the timestamp and reject stale reserve information.
Depending on the integration, verified data may support:
-
Issuance caps
-
Collateral limits
-
Solvency checks
-
Risk warnings
-
Vault controls
-
Exposure restrictions
-
Public reserve dashboards
-
Automated protocol responses
The smart contract follows the rules encoded by the integrating protocol. Afi Protocol supplies verifiable data, but each application determines how that data affects its own state and user actions.
Time-Series Chaining and Continuous Verification
A new proof can reference the previous proof’s Merkle root. The system combines the previous and current roots to create a chained value included in the new proof.
This creates an ordered verification history.
A participant cannot quietly remove, reorder, or replace an intermediate reserve state without breaking the chain. A missing proof also becomes detectable.
Time-series chaining helps distinguish continuous solvency monitoring from isolated snapshots. The market can verify not only that the latest result is valid, but also that it follows the expected sequence of prior attestations.
The cadence may be hourly, daily, connected to rebalancing, or defined by another integration-specific schedule. “Continuous” does not necessarily mean every second. It means verification is repeated through an auditable series rather than performed only once.
Key Benefits of the Afi Protocol Data Path
The architecture offers several important advantages.
Private custodian data remains outside public smart contract storage. Independent calculations reduce dependence on issuer-reported totals. Merkle commitments preserve dataset integrity. Zero-knowledge proofs validate hidden sums. Hardware attestations confirm the execution environment and approved code. Cross-checking ensures both proof systems describe the same information.
The self-contained Proof Payload also reduces dependency on Afi Protocol after generation. A protocol can retain the payload and verify it independently.
Finally, EVM-compatible proofs make the result composable. Once verified totals are published on-chain, other applications can reference them using ordinary smart contract logic.
Risks and Important Limitations
This data path improves verification but does not eliminate every source of risk.
The first limitation is the original data source. Cryptography cannot prove that a custodian’s real-world record is truthful if the source itself supplies false information.
The second is data completeness. A mathematically valid proof can still be misleading if important liabilities or asset restrictions were excluded from the verification scope.
Valuation risk also remains. Less liquid assets may depend on models or periodic valuations rather than continuously observable prices.
Technical vulnerabilities may affect API integrations, relay infrastructure, enclave implementations, proof circuits, verification keys, or smart contracts.
Legal enforceability is another separate issue. Verified reserves may exist while token holders’ rights depend on contractual structure, jurisdiction, bankruptcy rules, and creditor priority.
Proof-of-Reserve should therefore complement custody reviews, audits, legal analysis, valuation controls, redemption planning, and smart contract security.
Why This Matters for Project X and HyperEVM
Project X provides swap and liquidity functionality within the HyperEVM ecosystem. Afi Protocol should not be described as directly integrated with Project X unless such an integration is officially confirmed.
The relevance is infrastructural.
If a reserve-backed asset enters a Project X liquidity pool, on-chain balances and trading volume do not reveal how its off-chain backing was verified. A clear proof path from custodian data to an EVM contract can give users and protocols stronger evidence about the asset behind the market.
For HyperEVM, EVM-compatible zero-knowledge verification is particularly relevant. Proof outputs can be checked by smart contracts and transformed into risk controls without exposing institutional records.
As assets become composable across swaps, vaults, lending systems, and liquidity strategies, a reliable data path helps prevent unverifiable reserve claims from spreading through the ecosystem.
FAQ
Where does Afi Protocol reserve data originate?
It can originate from authorized custodians, issuers, administrators, financial institutions, asset managers, or other approved systems holding the relevant reserve and liability records.
Does the relay server calculate the reserve total?
No. It handles authentication, rate limiting, and request validation. Sensitive calculation and proof generation occur inside the isolated enclave.
Why does Afi Protocol use an AWS Nitro Enclave?
The enclave protects confidential inputs and provides hardware-backed evidence that the expected code processed the data.
What is included in the Proof Payload?
It contains metadata, verified totals, Merkle commitments, zero-knowledge proofs, a TEE attestation, certificates, and verification keys needed for independent checking.
Which information reaches the smart contract?
The contract receives zero-knowledge proofs and approved public outputs such as verified totals and proof metadata. It does not need the issuer’s complete custody records.
How are incorrect proofs rejected?
Hardware signatures, code measurements, Groth16 proofs, public signals, Merkle roots, and totals are checked. A mismatch between the proof systems causes verification to fail.
Can the result be verified without trusting Afi Protocol’s website?
Yes. The proof package is structured to contain the necessary verification context, allowing independent checks through software, a browser, or compatible smart contracts.
Follow the Evidence, Not Just the Published Total
A reserve figure becomes substantially more useful when its complete verification path can be examined.
Afi Protocol takes information from authorized custody and financial systems, validates the request, processes the data inside an isolated environment, creates cryptographic commitments, generates separate proofs for reserves, liabilities, and data integrity, and binds the result to a hardware attestation.
Independent verification then confirms that every layer refers to the same dataset. Only after these checks can verified totals be published to an EVM smart contract and used by on-chain applications.
Before relying on any reserve-backed asset, examine where its data originates, how inputs are authenticated, what the proof covers, whether the latest attestation is current, and how the receiving smart contract responds to the verified result.
For issuers and protocols, Afi Protocol provides a framework for turning confidential custodian records into independently verifiable on-chain financial information.