Network Details
Here we describe AFI’s Proof Of Reserve Data Verification Network (DVN) designed to provide continuous, cryptographically verifiable, and enforceable collateral assurance for token issuers and real‑world‑asset (RWA) backed protocols. The network combines hardware-based trusted execution, zero-knowledge proofs, and decentralized validation to create an unprecedented standard for RWA transparency.
The system is built around a fundamental principle:
Sensitive financial data must remain under issuer control, while verifiability, liveness, and enforcement are guaranteed externally.
Symbiotic Testnet - https://app.symbiotic.fi/network/0x18d71Ad9e024A7665093219f1308A3A9F113c77c Visit Multipli PoC Dashboard - https://verification.afiprotocol.xyz
Why AFI Exists
Traditional proof-of-reserve solutions suffer from fundamental limitations:
Trust
Rely on auditor reputation
Cryptographic verification via TEE and ZK proofs
Frequency
Periodic snapshots (monthly/quarterly)
Continuous, event-driven attestations
Privacy
Full disclosure or no verification
Zero-knowledge proofs reveal only what's necessary
Enforcement
Off-chain reports with no teeth
On-chain smart contracts enforce collateralization
Liveness
No guarantees on data freshness
Economic incentives ensure continuous operation
Architecture
The AFI Protocol operates as a 6-layer cryptographic verification network, where each layer builds on the previous to create an end-to-end verifiable system.
Layer 1
Issuer Infrastructure
Hardware-isolated proof generation
TEE hardware
Layer 2
Proof Generation
TEE attestation, Merkle trees, ZK proofs
Cryptographic
Layer 3
Protocol API
Proof distribution and generation triggers
Access control
Layer 4
Off-Chain Relay
Bridges proofs to validator network
Authenticated
Layer 5
Shared Security Network
Decentralized verification via Symbiotic
Economic (staking)
Layer 6
On-Chain Enforcement
Smart contract enforcement layer
Blockchain consensus
Layer 1: Issuer Infrastructure
AFI Secure Proof Node
The AFI Secure Proof Node is a self-contained application that runs inside an AWS Nitro Enclave. Nitro Enclaves are isolated virtual machines with no persistent storage, no network access, and no interactive access—even the host EC2 instance cannot see inside. This creates a hardware-enforced trust boundary where sensitive computations happen in complete isolation.
Why AWS Nitro Enclaves
No persistent storage
Secrets cannot be extracted after processing
No network access
Data cannot be exfiltrated
No interactive access
No SSH, no console, no debugging in production
Cryptographic attestation
Hardware proves exactly what code is running
Memory encryption
Data encrypted in RAM
Data Ingestion Sources
The Secure Proof Node supports multiple data ingestion pathways to accommodate different issuer architectures:
Signed Documents
Verifies cryptographic signatures from custodians, auditors, and financial institutions
Signature verification against known public keys
HTTPS APIs (zkTLS)
Cryptographically proves data was fetched from authenticated API sessions
TLS session attestation binds data to source
Native Crypto Feeds
Direct on-chain data via RPC calls
Blockchain consensus guarantees data integrity
Issuer Control Model
AFI provides audited, reproducible binaries that issuers deploy on their own infrastructure. Key properties:
Issuer-operated: AFI has no access to issuer nodes or data
Auditable code: Open-source binaries with reproducible builds
No telemetry: Nodes do not phone home or leak metadata
Configurable sources: Issuers define their own data sources and update frequencies
Trust Boundary
The trust boundary for Layer 1 encompasses only:
The issuer organization (operational security)
AWS Nitro hardware (hardware integrity)
The audited AFI binary (code correctness)
No external party—including AFI—can access raw data or influence computations.
Layer 2: Proof Generation
Three cryptographic mechanisms work in parallel to create verifiable, tamper-proof attestations.
2.1 TEE Attestation
Hardware-backed attestation using the AWS Nitro Secure Module (NSM).
Nitro Secure Module (NSM)
Dedicated hardware security module inside every Nitro Enclave
COSE_Sign1 Format
Standards-based attestation document (RFC 8152)
ECDSA P-384 Signature
Hardware-generated signature that cannot be forged
Certificate Chain
Validates through intermediate CAs to AWS Nitro Root CA
PCR Measurements
Platform Configuration Registers (PCRs) are SHA-384 hashes that cryptographically measure the enclave's configuration:
PCR0
Enclave image file (EIF) hash
The exact binary running inside
PCR1
Linux kernel and boot ramfs hash
Boot environment integrity
PCR2
Application code hash
Application-specific measurements
PCR3
IAM role ARN (if used)
AWS identity binding
PCR4
Instance ID (if used)
Hardware instance binding
PCR8
Signing certificate
Code signing verification
When verifying an attestation, validators compare PCR values against known-good measurements published by the issuer. Any code modification—even a single byte—produces completely different PCR values.
2.2 Merkle Proof Generation
AFI uses a hybrid commitment scheme with dual hash functions, enabling both on-chain verification and efficient ZK circuits.
Keccak256
EVM-native, widely supported
On-chain verification, public auditability
Poseidon
SNARK-friendly, ~8x fewer constraints
Zero-knowledge circuit proofs
Commitment Process
The commitment process transforms raw data into verifiable cryptographic structures:
Step 1: Salt Derivation
Each field receives a unique, deterministic salt derived via HMAC-SHA256. The salt derivation uses the feed identifier and field key as inputs. This ensures identical values in different fields produce different commitments, preventing correlation attacks.
Step 2: Field Commitments
Each value produces two parallel commitments:
Public commitment: Keccak256 hash of value concatenated with salt
ZK commitment: Poseidon hash of value and salt as field elements
Step 3: Merkle Tree Construction
Commitments are arranged as leaves in two parallel Merkle trees (one Keccak256, one Poseidon). The trees support up to 32 leaves with 5 levels of depth. Empty slots are padded with zero values.
Step 4: Timeseries Chaining
The current Merkle root is hashed together with the previous attestation's root, creating a cryptographic chain. This prevents attestation replay and ensures chronological integrity.
2.3 ZK Proof Generation
Zero-knowledge proofs allow validators to verify computations without seeing the underlying data. AFI uses Circom 2.1.6 circuits compiled to Groth16 proofs via SnarkJS.
Merkle Root Proof
Proves the Merkle tree was computed correctly from leaves
Merkle root
All leaf values
Reserves Sum Proof
Proves hidden reserve values sum to a claimed total
Total reserves
Individual values and salts
Liabilities Sum Proof
Proves hidden liability values sum to a claimed total
Total liabilities
Individual values and salts
What ZK Proofs Guarantee
Correctness: The computation was performed correctly
Privacy: Individual values remain hidden
Binding: The prover cannot change values after generating the proof
Succinctness: Proofs are small (~200 bytes) and fast to verify
Trusted Setup
ZK circuits require a one-time trusted setup ceremony that generates proving and verification keys. AFI uses pre-compiled circuits with deterministic trusted setup. The same keys are used across all deployments to ensure proof compatibility.
Layer 3: AFI Protocol API
Central API layer for proof distribution and generation triggers. The API serves as the authenticated interface between issuer infrastructure and the off-chain relay layer.
Functionality
Proof Distribution: Authorized relay nodes fetch the latest cryptographic proofs
Generation Triggers: Issuer systems can trigger on-demand proof generation
Status Monitoring: Operational health and circuit availability checks
Feed Management: Configuration of data feeds and update schedules
Security Model
Access to the API is restricted to authorized participants in the network. Multiple security layers are enforced:
Authentication: API key verification for all requests
Rate Limiting: Protection against abuse and denial-of-service
Transport Security: TLS encryption for all communications
Access Control: Feed-level permissions for relay nodes
Layer 4: Off-Chain Relay Layer
The relay layer bridges proof generation to the Shared Security Network, handling the logistics of proof distribution and validator coordination.
Components
Proof of Reserve Node
Go Application
Fetches proofs, validates structure, manages scheduling
Relay Sidecar
Symbiotic Relay
Routes attestations to SSN, coordinates signing
Data Flow
Polling: The PoR Node continuously monitors the AFI Protocol API for new attestations
Validation: Upon receiving a proof, the node validates structure, signatures, and basic integrity
Routing: Valid proofs are forwarded to the Relay Sidecar
Coordination: The sidecar routes attestations to Symbiotic validators and manages the quorum signing process
Submission: Once quorum is reached, the signed attestation is submitted on-chain
Relay Responsibilities
Fetch new attestations from the protocol API
Validate proof structure and cryptographic integrity
Forward to Symbiotic validators for verification and signing
Coordinate multi-validator signing to achieve quorum
Handle retries, timeouts, and error recovery
Submit finalized attestations to on-chain contracts
Layer 5: Shared Security Network (SSN)
The SSN is AFI's decentralized verification layer, powered by Symbiotic Protocol. This layer provides economic security through restaked assets and cryptographic verification through distributed validators.
What is Symbiotic
Symbiotic is a permissionless, modular restaking protocol that enables networks to bootstrap security from staked assets. Unlike traditional security models that require building a new validator set from scratch, Symbiotic allows protocols to tap into existing staked capital across multiple asset types.
Symbiotic Core Concepts
Restaking
Using already-staked assets to secure additional networks
Vaults
Smart contracts that manage staked collateral and delegate to operators
Operators
Entities that run validation infrastructure and stake capital
Networks
Protocols (like AFI) that consume shared security
Slashing
Penalty mechanism for operator misbehavior
AFI as a Symbiotic Network
AFI registers as a Network in Symbiotic's architecture. This means:
AFI defines the validation rules operators must follow
AFI specifies slashing conditions for misbehavior
Operators opt-in to validate AFI attestations
Staked capital backs the correctness of validations
Symbiotic Architecture for AFI
Vaults
Symbiotic Vaults are the primary coordination layer between stakers and the AFI network. Each vault contains three specialized modules:
Accounting Module
Manages deposits, withdrawals, and stake accounting
Delegation Module
Determines how capital flows to networks and operators
Slashing Module
Enforces penalties according to AFI's slashing rules
Vaults hold collateral that backs operator behavior. If an operator misbehaves (signs conflicting attestations, goes offline, etc.), the vault's slashing module can burn or redistribute their stake.
Operators
Operators are entities that run AFI validation infrastructure. To become an AFI operator:
Register in Symbiotic's OperatorRegistry
Opt-in to the AFI network by calling the network's opt-in method
Meet AFI's minimum stake requirements
Run the AFI validator software
Begin validating attestations and participating in quorum signing
Operators are selected for the active set based on:
Total stake delegated to them
Historical performance and uptime
Reputation score
Slashing Conditions
AFI defines specific slashing conditions that operators agree to when opting in:
Signing invalid attestation
Partial stake slash
Cryptographic proof of invalid signature
Double signing
Major stake slash
Two conflicting signatures from same operator
Extended downtime
Minor stake slash
Missed signing rounds beyond threshold
Collusion
Maximum slash
Evidence of coordinated misbehaviour
Symbiotic supports multiple slashing models:
Instant Slasher: Immediate penalty execution
Veto Slasher: Slashing proposal with resolver review period
Validator Roles in AFI
Committers
Submit proof commitments
First stage is commit to a verification result
Aggregators
Combine multi-source attestations
Correlate proofs across feeds and time periods
Signers
Participate in threshold signing
Final approval via BLS or ECDSA multisig
Quorum Model
AFI uses a 2/3+ threshold for attestation finality:
At least 2/3 of active stake must sign for an attestation to be valid
This provides Byzantine fault tolerance (up to 1/3 malicious operators)
Weighted by stake, not by operator count
What Validators Verify
Validators perform comprehensive verification without accessing confidential data:
TEE Attestation
Verify COSE_Sign1 signature chains to AWS Nitro Root CA
Reject if signature invalid or cert chain broken
PCR Values
Compare against expected enclave measurements
Reject if code measurements don't match
ZK Proofs
Cryptographically verify Groth16 proofs via snarkjs
Reject if proof verification fails
Data Binding
Confirm Merkle root matches user_data in attestation
Reject if roots don't match
Timeseries
Verify chain integrity with previous attestation
Reject if chain is broken or replayed
Freshness
Check attestation timestamp is within acceptable range
Reject if too old
Blind Verification
A critical property of AFI's design: operators verify without seeing data.
Validators prove correctness without accessing:
Raw reserve or liability values
Individual asset breakdowns
Issuer credentials or API responses
Salt values used in commitments
Any personally identifiable information
This is possible because ZK proofs and TEE attestations provide cryptographic guarantees that don't require revealing underlying data.
Economic Security Model
The security of Layer 5 comes from economic incentives:
Staking
Operators lock capital that can be slashed
Slashing
Misbehavior results in financial loss
Rewards
Correct validation earns fees from the network
Reputation
Good operators attract more stake delegation
The total security budget equals the sum of all stake delegated to AFI operators. An attacker would need to corrupt operators controlling >1/3 of total stake to prevent attestation finality, or >2/3 to forge attestations.
Layer 6: On-Chain Enforcement
The final layer converts cryptographic attestations into enforceable on-chain guarantees.
Smart Contracts
ProofOfReserve.sol
Stores verified attestations, tracks collateralization status
Settlement Contract
Verifies SSN quorum signatures, validates threshold
On-Chain Vaults
Enforcement layer that gates protocol operations
Registry Contract
Manages feed configurations and authorized signers
Enforcement Capabilities
Gate Minting
Prevent token minting without valid attestation
No valid attestation or under-collateralized
Supply Caps
Enforce maximum supply based on proven reserves
Reserves below threshold
Operational Restrictions
Trigger protocol safety modes
Collateralization ratio drops
Alert Emission
On-chain events for monitoring systems
Any state change
Emergency Pause
Halt protocol operations
Critical collateralization breach
On-Chain Verification Process
When a signed attestation arrives on-chain:
Signature Verification: Settlement contract verifies that 2/3+ of SSN stake has signed
Freshness Check: Attestation timestamp must be within maximum age threshold
Sequence Validation: Attestation must chain correctly to previous root
State Update: On-chain collateralization state is updated
Event Emission: Events emitted for indexers and monitoring systems
Enforcement Trigger: If under-collateralized, enforcement actions execute
Integration Patterns
Protocols integrate with AFI's on-chain layer in several ways:
Direct Query
Read latest attestation and collateralization status
Modifier Guard
Require valid attestation before sensitive operations
Callback Hook
Receive notifications on attestation updates
Oracle Feed
Consume collateralization ratio as price feed
Cryptographic Binding
The Core Innovation
The Merkle root is embedded as user_data inside the TEE attestation document. This creates an unbreakable cryptographic binding between computed data and hardware attestation.
The TEE attestation document contains:
user_data: The Merkle root (what was computed)
PCR values: Code measurements (what code computed it)
timestamp: When the computation happened
signature: ECDSA P-384 hardware signature
certificate chain: Path to AWS Nitro Root CA
What This Proves
When you verify the hardware signature chains to AWS Root CA, you've cryptographically proven:
Exact Computation: AWS Nitro hardware computed that exact Merkle root
Code Integrity: The code running inside had specific, measurable PCR values
Temporal Binding: The attestation was generated at a specific timestamp
Hardware Authenticity: The attestation came from genuine AWS Nitro hardware
This binding is not a separate signature on the data—the data is literally inside the attestation document that the hardware signs. You cannot have a valid attestation with different data.
Verification Chain
The complete verification chain from raw data to on-chain enforcement:
Raw data enters TEE → Commitments created → Merkle root computed
Merkle root embedded in attestation → NSM signs with hardware key
ZK proofs generated → Prove computation correctness
Attestation exits enclave → Relay fetches and distributes
SSN validators verify → Sign if valid
Quorum reached → Submit to chain
Smart contract verifies → Update state and enforce
At each step, cryptographic guarantees ensure the next step receives authentic, untampered data.
Trust Model -
Trust Assumptions
AWS Nitro TEE
Hardware manufacturer integrity
Complete if AWS is malicious
Cryptographic Primitives
Mathematical soundness
Complete if crypto is broken
Symbiotic SSN
Economic security via staked capital
Degraded if >1/3 stake is malicious
Smart Contracts
Code audits and blockchain consensus
Limited to contract scope
Issuer Operations
Correct data input to enclave
Garbage in, garbage out
What AFI Guarantees
Computation Integrity: The attestation was computed by the claimed code
Data Binding: The Merkle root matches what was computed
Proof Validity: ZK proofs are mathematically correct
Consensus: 2/3+ of economic stake validated the attestation
What AFI Does NOT Guarantee
Data Accuracy: If the issuer feeds incorrect data, the attestation will be incorrect
Operational Security: Issuer must secure their own infrastructure
Smart Contract Bugs: On-chain enforcement depends on correct contract implementation
Public vs Private Information
Public (share freely):
Verification keys for ZK circuits
WASM circuit files
Attestation payloads and proofs
PCR values for verified binaries
On-chain attestation history
Private (never share):
Derived salt values
Raw input data (reserves, liabilities, assets)
API credentials and keys
Enclave configuration secrets
Verification -
Full Verification Flow
Verification proceeds through five sequential stages:
Stage 1: On-Chain Check
Query the ProofOfReserve contract for the latest attestation. Verify the attestation exists and check its age against freshness requirements.
Stage 2: SSN Quorum Verification
Verify that 2/3+ of SSN stake has signed the attestation. Check each signature against the registered operator set and sum stake weights.
Stage 3: Attestation Chain Verification
Parse the COSE_Sign1 attestation document. Verify the ECDSA P-384 signature. Walk the certificate chain from the signing certificate through intermediates to the AWS Nitro Root CA.
Stage 4: ZK Proof Verification
Verify each Groth16 proof using the published verification keys. Check the Merkle root proof, reserves sum proof, and liabilities sum proof.
Stage 5: Data Binding Verification
Confirm the Merkle root in the ZK proofs matches the user_data field in the TEE attestation. Verify timeseries chaining with the previous attestation.
Upon successful completion of all stages, the attestation is verified and collateralization status is confirmed.
Verification Dashboard
Live verification interface available at https://verification.afiprotocol.xyz
Design Objectives
The architecture prioritizes six key objectives:
Confidentiality
ZK proofs and commitments hide raw data
Issuers protect sensitive information
Cryptographic Assurance
TEE attestation and ZK proofs
Machine-verifiable, not reputation-based
Real-time Verification
Event-driven attestations
Minutes, not months
Protocol Enforcement
On-chain smart contracts
Automatic, not manual
Economic Liveness
Symbiotic staking and slashing
Validators economically incentivized
Complementary Integration
Works alongside existing systems
Enhances, doesn't replace
Continuous Attestation
Unlike periodic audit snapshots, AFI operates as an event-driven control system:
Frequency
Monthly or quarterly
Continuous or on-demand
Latency
Weeks to publish
Seconds to minutes
Freshness
Stale by publication
Real-time
Gaps
Unmonitored between audits
Timeseries chaining prevents gaps
Enforcement
Manual review
Automatic on-chain
The continuous model enables:
Real-time risk containment
Immediate response to collateralization changes
Deterministic latency bounds
Cryptographic proof of data freshness
Last updated