# Welcome to AFI

AFI (Artificial Financial Intelligence) builds Proof-of-Reserve infrastructure for Real-World Assets — unlocking institutional-grade yield that’s fully composable in DeFi.

It provides the foundational architecture for transparent, auditable, and composable financial instruments that connect **on-chain liquidity** with **off-chain collateral**.

### **Our Mission**

> **To make every on-chain asset provably backed and productively deployed.**

The future of finance lies in **verified transparency** — where every token, vault, and yield source is cryptographically proven, not just promised. AFI bridges the gap between **Real-World Assets (RWA)** and **DeFi** by providing an auditable foundation for yield generation and collateral verification.

### **Our Vision**

The financial system is shifting toward a world where real-world assets, yield instruments, and institutional capital move on-chain. But this transition cannot scale without **verifiable trust guarantees**.

AFI’s vision is to provide the **standard verification infrastructure** for this new financial era — an infrastructure layer where:

* Every tokenized asset is **backed by provable reserves**, not delayed attestations.
* Every yield-bearing instrument is **solvency-constrained by math**, not belief.
* Every DeFi integration relies on **programmatic assurance**, not counterparty risk.
* Every institution can deploy capital with **audit-grade transparency**, in real time.

> **AFI aims to ensure that the next trillion dollars of tokenized assets are trust-minimized, composable, and cryptographically verifiable.**

By anchoring both off-chain reserves and on-chain supply to a tamper-resistant Proof-of-Reserve framework, AFI creates a financial environment where transparency is default, solvency is enforceable, and tokenized assets can circulate safely across the global on-chain economy.

This is the foundation required for RWAs and DeFi to scale together — not as parallel systems, but as a unified, verifiable financial ecosystem.

***

### **Learn More**

You can explore AFI’s architecture, vault mechanics, and integrations throughout these documentation pages or by visiting the website:\
[**https://www.afiprotocol.xyz**](https://www.afiprotocol.ai)

***

### **Join Our Community**

We welcome feedback, partners, and contributors.

* **X (Twitter):** <https://x.com/afiprotocol_xyz>&#x20;
* **Discord:** <https://discord.gg/afiprotocol>&#x20;
* **Email:** <support@afiprotocol.xyz>


# AFI: The Financial Intelligence Ledger For RWAs

The tokenization of real-world assets has shifted from projection to reality. In the last 18 months alone, the industry has seen:

* **$1B+** of U.S. Treasuries, private credit, and gold-backed tokens migrate on-chain
* **$15B+** in aggregate RWA stablecoin market cap&#x20;
* **Major institutions** such as BlackRock, Franklin Templeton, J.P. Morgan, and Hamilton Lane launching blockchain-based products
* **L2 ecosystems** (Base, Polygon, Blast, Mantle) integrating RWA tokens as primary collateral for lending, swaps, and structured yield

Importantly, this is no longer a USD-only phenomenon. **The Euro is now emerging as a major currency backing tokenized RWAs**, alongside the U.S. dollar — meaning the world’s two largest and most trusted monetary systems are beginning to collateralize the on-chain economy.

RWA is growing in the crypto space, as seen in the DefiLlama chart below, with a TVL of over $16 billion in Nov 2025. And according to leading forecasts (BCG, Chainlink, Alliance Bernstein), **$2.5–$4 trillion** in real-world assets are expected to move on-chain by 2030.

<figure><img src="/files/1WA3J1yeI9y0W5KON97V" alt=""><figcaption></figcaption></figure>

But despite this acceleration, RWA infrastructure suffers from a **fundamental limitation**:

> **On-chain tokens move at blockchain speed.**\
> **Off-chain collateral does not.**

Tokenized gold, treasuries, or credit instruments can be transferred 24/7 on Ethereum, but the *state of the underlying reserve* — the gold held in a vault, the T-bills in custody, the credit positions in an SPV — remains opaque, delayed, and unverifiable in real time.

This creates a structural trust gap:

* Tokens are *liquid*, but reserves are *invisible*.
* Markets are *composable*, but collateral is *not cryptographically provable*.
* Billions in RWAs sit on-chain, but **the market has no deterministic guarantee they are fully backed**.

The next phase of RWA adoption requires an auditable, tamper-resistant, on-chain system of record — a **Financial Intelligence Ledger** — that continuously verifies reserves, enforces supply constraints, and provides market participants with real-time solvency signals.

***

### **How AFI positions itself**

AFI serves as this **Financial Intelligence Ledger for RWAs** by providing:

* **On-chain Proof-of-Reserve vaults** for off-chain assets
* **Deterministic ERC-4626 accounting** for institutional and DeFi integrations
* **Capacity limits** that mathematically restrict circulating supply to verified reserves
* **Open, composable data feeds** that external protocols can trust without intermediaries

AFI transforms RWA tokens from *issuer-dependent claims* into **cryptographically enforced financial instruments**, bridging the gap between off-chain collateral and on-chain liquidity.


# The Problem: A Trust Gap Between On-Chain Tokens and Off-Chain Assets

Most RWA tokens today — whether backed by **gold**, **U.S. Treasuries**, **private credit**, or **cash equivalents** — depend on **centralized attestations**: quarterly audits, PDF reports, custodian certificates, or issuer disclosures.

Despite billions moving on-chain, the underlying collateral still lives in a **black box**.

This creates three structural problems:

***

#### **1. Information Lag — Slow Reporting Hides Fast Risks**

Most issuers publish reserve audits **every 30–90 days**.\
This delay can conceal:

* Insolvency events
* Custodian withdrawal restrictions
* Rapid drawdowns in asset value

In a 24/7 blockchain environment, **monthly reporting is equivalent to no reporting**.

***

#### **2. Opaque Collateral — Users Cannot Verify Reserves in Real Time**

Token holders and DeFi protocols have **no programmatic way** to confirm that:

* Gold is physically stored where issuers claim
* Treasury bills exist at a specific custodian
* Private credit repayments match tokenized balances
* RWA-backed stablecoins are fully collateralized

A token may represent **$100 million of real-world assets**, but on-chain, it functions more like a **promise** than a proof.

***

#### **3. Systemic Fragility — DeFi Cannot Safely Integrate Opaque RWAs**

When DeFi protocols rely on RWA tokens with unverifiable backing:

* Collateral ratios cannot be trustlessly enforced
* Liquidations cannot account for off-chain risks
* Lending markets inherit custodial and issuer solvency risk
* A single undisclosed shortfall can trigger **cross-protocol contagion**

This undermines the “trustless” nature of DeFi and exposes the entire ecosystem to **hidden RWA failures**.

***

#### **The Result: A “Proof of Promise” Economy**

Instead of cryptographic guarantees, RWAs today operate on:

* Issuer assurances
* Quarterly PDFs
* Legal structures
* Human attestations

None of these can be verified by smart contracts or relied on by automated trading systems.

As capital flows increase, this trust gap becomes **the primary barrier** to institutional-scale adoption.

***

#### **The Market Demand: Real-Time, On-Chain Verifiability**

Regulators, issuers, investors, and DeFi protocols are increasingly aligned on a single requirement:

> **RWA tokens must provide continuous, on-chain confirmation of their reserves.**

Without this, RWAs remain incompatible with:

* Automated money markets
* High-velocity arbitrage
* Permissionless risk management like we have on Morpho
* Risk-aware structured products

The next generation of RWA infrastructure must deliver **real-time, programmatic Proof of Reserve** — not quarterly proof of promise.


# The AFI Approach: Proof Of Reserve Network for RWAs

As real-world assets move on-chain, the dominant risk is no longer whether smart contracts execute correctly, but whether the liabilities they issue are actually supported by assets that exist off-chain.

Blockchains can mint tokens in milliseconds. Custodians, vaults, and regulated balance sheets cannot move at that speed. Without an enforceable link between these two domains, tokenized RWAs collapse into the same failure mode that has repeatedly affected both TradFi and DeFi: claims on assets that cannot be independently verified in real time.

AFI’s Proof Of Reserve framework is designed to establish that link.

Instead of publishing balances or relying on periodic attestations, AFI provides a **continuously enforced solvency condition**: whether issued on-chain supply is covered by verified off-chain reserves at the moment of issuance and state change. The output is not a price or valuation, but a solvency predicate — **backed or not backed** — that can be verified on-chain without revealing any underlying financial or custodial data.

***

### **How Reserve Integrity Is Enforced**

Reserve verification begins inside **issuer-controlled confidential execution environments**. Custodians, registries, and regulated counterparties supply signed, time-stamped reserve data through secure channels. This data is processed inside the issuer’s Secure Proof Node, where cryptographic commitments and zero-knowledge proofs are generated over declared properties. Only these proofs and commitments leave the enclave; raw data never does.

The resulting proof artifacts are verified and aggregated by a **decentralized verification network**. Independent operators validate proof correctness, freshness, and enclave integrity, and stake capital to guarantee availability and censorship resistance. Operators never see the underlying data and cannot alter or fabricate proofs; incorrect or withheld participation is economically penalized.

Once verified, collateral state is evaluated across multiple sources and time windows, and enforced directly at the protocol level. On-chain vaults gate minting, enforce dynamic supply caps, and trigger automatic restrictions when reserves are breached. Violations are mechanically prevented, not merely detected.

***

#### **Why This Matters**

This architecture turns reserve assurance from a disclosure problem into an enforcement mechanism. On-chain issuance becomes bounded by off-chain reality. Misreporting becomes expensive. Institutions retain confidentiality while markets gain a verifiable notion of solvency.

AFI’s Proof Of Reserve system does not replace custodians, auditors, or legal enforcement. It adds the missing cryptographic control layer that allows real-world assets to exist on public blockchains with continuous, enforceable guarantees, without reverting to trust in issuers.


# Why the Market Needs It — Now

The RWA market is expanding faster than the infrastructure required to **verify**, **enforce**, and **protect** its collateral.

* By **2026**, more than **$16 billion** in tokenized U.S. Treasuries  will be circulating across Ethereum, Base, Solana, and EVM L2s.
* Over **$10 billion** in private credit is expected to be tokenized by platforms like Centrifuge, Goldfinch, and Maple.
* Gold, metals, carbon credits, and other institutional vaults are projected to exceed **$50 billion** within 3 years.

Yet **less than 5%** of this capital has any form of **on-chain reserve verification**.

But the urgency is even clearer when we examine what just happened in DeFi.

***

#### **The xUSD Failure Exposed a Critical Weakness**

The collapse of **xUSD** showed that even a *fully on-chain* stablecoin can suffer catastrophic failure if its **supply is not cryptographically linked** to verifiable reserves.

<figure><img src="/files/bguMa7KkGiFtGCMeCk3e" alt=""><figcaption></figcaption></figure>

xUSD was transparent, auditable, and algorithmic — yet recursive minting via lending markets  **ballooned supply beyond actual backing**, causing a chain reaction of:

* **Insolvency at the protocol level**, with liabilities dwarfing real assets
* **Contagion across related tokens** such as deUSD and USDX
* **Liquidity drains** across integrated protocols as positions unwound
* A complete **depeg below $0.10**, wiping out user confidence
* And ultimately, over **$93M in user losses**, publicly acknowledged by Stream:\
  👉 [*https://x.com/StreamDefi/status/1985556360507822093*](https://x.com/StreamDefi/status/1985556360507822093)

Even more striking: this happened to an asset that existed **entirely on-chain**, where every mint, borrow, and loop was visible — yet **nothing cryptographically enforced 1:1 reserve integrity**.

This failure underscored a fundamental truth:\
**Transparency is not enough. Without verifiable proof-of-reserves, supply can decouple from reality — and the entire system collapses.**

***

#### **RWA Tokens Are Even More Fragile**

If an on-chain asset like xUSD could collapse from recursive minting, the risk is **10× higher** for real-world assets because:

* Their backing is **off-chain**
* Reserves sit in **custodial blackboxes**
* Proofs are **delayed** (monthly or quarterly audits)
* Issuers can mint against collateral that no one can verify in real time
* DeFi protocols have **zero programmatic visibility** into underlying solvency

With RWAs, there is **no on-chain trail** to detect over-minting, rehypothecation, or reserve shortfalls.

A failure similar to xUSD could go **undetected for months**, until the first major redemption run exposes an off-chain deficit.

***

#### **Why This Matters Today**

DeFi protocols integrating RWAs — lending markets, stables, derivatives, treasuries — need **programmable guarantees**, not PDF reports.

Without **Proof-of-Reserve enforcement**, the ecosystem will continue to face:

* Collateral uncertainty
* Systemic contagion risks
* Higher borrowing spreads due to “trust discounts”
* Reluctance from institutions to deploy capital
* Fragility in liquidity pools and stablecoin markets


# Introduction

### **The Trust Problem in Finance**

Modern finance runs on trust. When a bank says it holds $10 billion in reserves, you trust the bank. When an auditor confirms those numbers, you trust the auditor. When a protocol claims it's fully collateralized, you trust the protocol's dashboard.

But trust breaks. Banks fail. Auditors miss things. Dashboards can show whatever the operator wants them to show. History is full of examples from traditional finance collapses to crypto platform failures, where the numbers on the screen didn't match reality.

The question isn't whether institutions are honest. Most are. The question is: **why should you have to trust at all when technology can provide proof?**

### **A New Approach: Verifiable Proof**

This system replaces trust with verification. Instead of asking "do I trust this entity to report honestly?", it enables anyone to ask "can I verify this myself?"

Every piece of financial data that enters the system goes through a pipeline that produces **cryptographic proof which is a** mathematical evidence that:

* The data was processed by legitimate, untampered software
* The computations (like summing reserves) were done correctly
* No one, not even the system operator could have modified the results
* The numbers haven't been changed since they were produced

This isn't a new idea. Blockchains do something similar for transactions. But this system brings the same level of verifiability to **off-chain financial data** — the real-world numbers that most of DeFi and traditional finance actually depend on.

### **Who Is This For?**

This documentation is for anyone who wants to understand how the system works and why it's secure. You don't need to be a cryptographer or a developer.

* **Protocol users** who want to know their funds are actually backed
* **Institutional partners** evaluating the security model
* **Regulators and auditors** who need to understand the verification process
* **Developers** building integrations (the technical details are in the codebase)

### **What You'll Learn**

This documentation is organized into sections that build on each other:

| Section                                                                                                 | What It Covers                                             |
| ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| [The Data Pipeline](/proof-of-reserve-network/the-data-pipeline)                                        | The complete journey from raw data to verifiable proof     |
| [Trusted Execution Environments](/proof-of-reserve-network/trusted-execution-environments-tee)          | How secure hardware guarantees computation integrity       |
| [Zero-Knowledge Proofs](/proof-of-reserve-network/zero-knowledge-proofs)                                | How math proves correctness without exposing private data  |
| [Merkle Trees, Commitments & Chaining](/proof-of-reserve-network/merkle-trees-commitments-and-chaining) | How data is fingerprinted, organized, and linked over time |
| [Verification](/proof-of-reserve-network/verification)                                                  | How anyone can independently check a proof                 |
| [Security Model](/proof-of-reserve-network/security-model)                                              | The full picture of what's protected and how               |

You can read them in order for the full picture, or jump to any section that interests you.

### **The Core Idea in 30 Seconds**

Private financial data goes into a **secure hardware enclave** — a sealed environment that no one, not even the server operator, can peek into. Inside that enclave, the data is processed, committed, and proven correct using **zero-knowledge proofs**. The hardware itself signs everything, producing an **attestation** that traces back to a trusted certificate authority. The result is a single proof payload that anyone can verify independently, without needing to see the original data.

Two independent guarantees back every proof:

1. **Hardware says it's real** — the secure enclave's signature proves the computation happened in genuine, untampered hardware
2. **Math says it's correct** — zero-knowledge proofs provide mathematical certainty that the computations are right

An attacker would need to break both simultaneously — the hardware and the mathematics — which are completely independent systems.

### **How This Is Different**

Most systems in this space rely on one of these approaches:

| Approach                  | Limitation                        |
| ------------------------- | --------------------------------- |
| Trusted oracles           | You trust the oracle operator     |
| Multi-sig attestation     | You trust the signers             |
| Periodic audits           | Snapshots in time, not continuous |
| On-chain computation only | Limited to data already on-chain  |

This system combines **hardware attestation** and **zero-knowledge proofs** to create continuous, real-time verification of off-chain data without trusting any single party. The proof speaks for itself.

### **A Note on Terminology**

Throughout this documentation, you'll encounter some terms that might be unfamiliar:

* **Attestation** — a signed statement from hardware proving what code ran and what it computed
* **Commitment** — a cryptographic fingerprint of a value that hides it but can be verified later
* **Merkle tree** — a data structure that combines many fingerprints into a single root hash
* **Zero-knowledge proof** — a mathematical proof that something is true without revealing the underlying data
* **Enclave** — an isolated, tamper-proof execution environment within a processor
* **Collateralization** — whether reserves are sufficient to cover liabilities

Don't worry if these don't fully click yet. Each section explains the relevant concepts in detail with analogies and diagrams.


# The Data Pipeline

This section explains the complete journey of data through the system from the moment private financial information enters to the moment a verifiable proof comes out.

### **The Big Picture**

At a high level, the system works like a secure processing factory. Raw financial data goes in one end, and a verifiable proof comes out the other. Along the way, every piece of data is validated, fingerprinted, organized, proven correct, and signed by hardware.

Each step builds on the one before it. There are no shortcuts and no way to skip a step. Let's walk through each one.<br>

<figure><img src="/files/eJJsXne53ffg5A6KN2lv" alt=""><figcaption></figcaption></figure>

### **Step 1: Data Arrives**

The pipeline begins when financial data is submitted — typically reserves held at various custodians and liabilities owed to users. Each record includes:

* **Who** holds it (a custodian or counterparty identifier)
* **What** asset it is
* **How much** (a USD value)
* **When** the value was recorded (a timestamp)

This is the raw, private data. Individual custodian holdings, specific asset breakdowns — information that needs to remain confidential.

### **Step 2: Validation**

Before any cryptographic processing begins, every piece of data goes through strict validation. This is the system's first line of defense against bad data.

**Why validation matters:** The system can only prove that computations were done correctly. It can't know if the input data itself is truthful. But it can catch data that is obviously wrong, stale, or malformed, preventing garbage from being attested.

The validation checks include:

* **Structure** — Does each record have all required fields? Are the types correct?
* **Reasonableness** — Are values within sane bounds? A negative reserve amount or a $999 quadrillion liability would be rejected.
* **Freshness** — Is the data recent? Records older than 12 hours are rejected to prevent stale data from being attested as current. This is important because financial positions change, and a proof should reflect recent reality.
* **Capacity** — Does the data fit within the system's processing limits? The cryptographic circuits have fixed capacities, and the data must fit within them.

If any check fails, the entire request is rejected. There are no partial proofs — either everything is valid, or nothing gets processed.

### **Step 3: Salt Derivation**

Each value needs a unique secret called a **salt** before it can be committed. Think of a salt as a secret ingredient mixed into a fingerprint. It ensures that even if two custodians hold the exact same amount, their fingerprints look completely different.

**Why salts matter:** Without salts, an attacker who knows the possible values (say, round dollar amounts) could try hashing each possibility until they find a match. Salts make this impossible. You'd need to guess both the value and its unique salt, which is computationally infeasible.

The salts are generated using a technique called **HMAC** (Hash-based Message Authentication Code). The important properties:

* **Deterministic** — the same data always produces the same salt. This means proofs are reproducible.
* **Unique** — each field gets its own salt based on its identifier. No two fields share a salt.
* **Derived from a master secret** — a single private key generates all salts. The master secret never leaves the secure enclave.
* **One-way** — knowing one salt tells you nothing about any other salt or the master secret.

### **Step 4: Value Commitment**

Now each value is combined with its salt to produce a **commitment** — a cryptographic fingerprint.

A commitment is a one-way operation. Given a value and its salt, anyone can compute the commitment and verify it matches. But given only the commitment, it's impossible to work backward to find the value.

**Everyday analogy:** Imagine writing a number on a piece of paper, putting it in a locked box, and publishing a photo of the locked box. Everyone can see the box exists, but no one can see the number. Later, you can open the box and everyone can verify the number was always there.

The system actually creates two fingerprints for each value using different methods — one optimized for compatibility with Ethereum smart contracts (keccak256), and another optimized for efficiency in zero-knowledge proof systems (Poseidon). Both represent the same value; they just serve different verification purposes.

### **Step 5: Merkle Tree**

All the individual commitments are organized into a structure called a **Merkle tree**. This is a way of combining many fingerprints into a single, compact **root hash** that represents all of them.

The key property: if any single commitment changes, the root hash changes completely. This makes the Merkle root a tamper-evident seal over all the data.

Think of it like a chain of custody form. If one item on the form is altered, the overall checksum changes and everyone knows something was tampered with.

See [Merkle Trees, Commitments & Chaining](/proof-of-reserve-network/merkle-trees-commitments-and-chaining) for a deeper explanation of how this works.

### **Step 6: Timeseries Chaining**

Before the root is finalized, it's linked to the previous proof's root. This creates a chain where each proof depends on the one before it, similar to how blocks in a blockchain reference the previous block.

**Why chaining matters:** Without it, someone could replace an old proof with a fabricated one, and no one would notice. With chaining, modifying any historical proof breaks the chain from that point forward, making tampering immediately detectable.

See [Merkle Trees, Commitments & Chaining](/proof-of-reserve-network/merkle-trees-commitments-and-chaining) for more detail.

### **Step 7: TEE Attestation**

This is where the hardware steps in. The Merkle root, along with the computed totals and metadata, is **attested** by the Trusted Execution Environment (TEE).

Attestation means the hardware itself produces a signed document saying: "I am genuine hardware, running this specific code, and the computation produced this exact result." The signature traces all the way back to a trusted certificate authority.

This is the strongest guarantee in the system. It's not a software signature that could be faked by a compromised server. It's a hardware signature that can only come from a genuine, unmodified enclave.

See [Trusted Execution Environments](/proof-of-reserve-network/trusted-execution-environments-tee) for the full explanation.

### **Step 8: Zero-Knowledge Proofs**

As an additional layer of security, the system generates **zero-knowledge proofs** (ZK proofs) that mathematically verify the computations are correct.

Two types of proofs are produced:

1. **Merkle root proof** — proves the root hash was correctly computed from all the commitments
2. **Sum proofs** — proves that the individual reserve values add up to the published total reserves (and the same for liabilities), without revealing what the individual values are

These proofs are independent of the hardware attestation. Even if you don't trust the hardware, the math still holds. And even if you're skeptical of the math, the hardware attestation provides an independent guarantee.

See [Zero-Knowledge Proofs](/proof-of-reserve-network/zero-knowledge-proofs) for more.

### **Step 9: Payload Assembly**

Finally, everything is bundled into a single JSON document, which is the **proof payload**. This payload is completely self-contained. It includes:

* The proof metadata (when it was generated, what data feed it covers)
* The verified totals (total reserves, total liabilities)
* The Merkle root and all commitments
* The hardware attestation document
* The zero-knowledge proofs
* All certificates and verification keys needed to check everything

A verifier doesn't need to contact any external service. They don't need special access or credentials. Everything needed to independently verify the proof is right there in the payload.

### **Why This Design?**

Several design choices make this pipeline particularly robust:

**Sequential processing** — each step depends on the previous step's output. This means errors are caught early and can't propagate.

**Redundant verification** — hardware attestation and ZK proofs provide two independent guarantees. Breaking one doesn't break the other.

**Self-contained output** — the proof payload includes everything needed for verification. No external dependencies, no trust in third-party services.

**Privacy by default** — individual values are never exposed. Only commitments and aggregate totals are published. A verifier can confirm the totals are correct without ever seeing the breakdown.

**Historical continuity** — time-series chaining ensures the proof history can't be rewritten. Each proof is anchored to the entire history before it.


# Trusted Execution Environments (TEE)

This section explains how secure hardware guarantees that data was processed correctly and privately, and why this is a critical part of the system's security.

### **The Problem: Who Watches the Server?**

When a server processes your data, you're trusting the operator. You trust that they're running the right software, that they haven't modified it, and that they aren't peeking at your private data.

But servers get hacked. Insiders go rogue. Operators make mistakes. And in high-stakes financial applications, "just trust us" isn't good enough.

What if the hardware itself could guarantee integrity — independent of the operator?

### **What Is a TEE?**

A **Trusted Execution Environment** is a special, isolated area inside a processor. Code running inside a TEE is completely sealed off from everything else — including the server's operating system, other applications, and even the cloud provider's own infrastructure.

**Think of it like a bank vault with a window.** You can put documents into the vault, and the vault processes them according to pre-set rules. You can see the results that come out. But you cannot open the vault, peek inside, or change the rules after it's sealed. The vault also stamps every result with a tamper-evident seal proving it came from inside.

That's essentially what a TEE does, but with cryptographic guarantees instead of physical locks.

TEE technology has been adopted across industries that handle sensitive data — from banking and healthcare to government and defense. Major cloud providers offer TEE solutions, and the technology is considered mature and production-ready for high-security applications.

### **TEE Technologies in the Landscape**

Several TEE technologies exist today, each with different architectures but the same core promise: isolated, verifiable computation.

| Technology                              | Provider | Approach                                                   |
| --------------------------------------- | -------- | ---------------------------------------------------------- |
| Nitro Enclaves                          | AWS      | Dedicated security chips, separate VM isolation            |
| SGX (Software Guard Extensions)         | Intel    | CPU-level enclaves with hardware memory encryption         |
| SEV (Secure Encrypted Virtualization)   | AMD      | Encrypted virtual machines at the hypervisor level         |
| TrustZone                               | ARM      | Processor-level separation for mobile and embedded devices |
| CCA (Confidential Compute Architecture) | ARM      | Next-gen confidential computing for cloud workloads        |

While the implementations differ, they all share the same fundamental properties: code and data are isolated from the rest of the system, the hardware produces cryptographic proof of what ran, and no external party — including the infrastructure operator — can observe or tamper with the execution.

This system is designed to work with TEE technology broadly. The architecture is TEE-agnostic at its core — what matters is the attestation guarantee, not which specific hardware provides it.

### **How This System Uses TEEs**

Here's the flow of how data moves through the TEE:<br>

<figure><img src="/files/3icP2vHRi2IVBzSMPftx" alt=""><figcaption></figcaption></figure>

#### **1. The Enclave Is Created**

When the system starts up, an enclave is created from a pre-built image — a package containing the exact code that will run. This image is **measured** (hashed) at creation time, producing a set of values that act as the code's fingerprint.

These measurement values are locked in. If anyone modifies even a single line of code, the measurements change. Think of it like a tamper-evident seal on a medicine bottle — you can tell immediately if it's been opened.

Different TEE platforms call these measurements different things (PCRs, MREnclave, launch digests, etc.), but the concept is universal: a cryptographic fingerprint of the code that the hardware will enforce.

#### **2. Data Enters the Enclave**

Private financial data (reserves, liabilities) is sent into the enclave through a secure, direct channel. This channel connects the host system to the enclave without going through the public network. Data enters the sealed environment and is no longer accessible to the outside world.

The specifics of the communication channel vary by TEE platform, but the security property is the same: data enters the enclave through a controlled, isolated path, and once inside, it's protected by hardware isolation.

#### **3. All Processing Happens Inside**

Everything that matters happens inside the enclave:

* Salts are derived from the master secret
* Each value is committed (fingerprinted)
* The Merkle tree is built
* Totals are computed
* The attestation is generated
* ZK proofs are created

At no point does the raw data leave the enclave. The operator, the host server, and even the cloud provider itself cannot see what's being processed. This is enforced by hardware, not by policy — there is no "admin override" that can bypass the isolation.

#### **4. The Hardware Produces an Attestation**

This is the key step. The enclave's hardware security module generates a signed **attestation document** — a cryptographic statement saying:

> "I am genuine hardware. I was running this specific code (here are the measurements). The computation produced this exact result (here is the data hash)."

This attestation is signed using a key that is embedded in the hardware itself. It cannot be extracted, copied, or used by software. The signature is proof that genuine, unmodified hardware produced this result.

Think of it like a notary stamp that's physically built into the vault. The stamp can't be removed, forged, or used outside the vault. When you see the stamp on a document, you know the vault produced it.

#### **5. The Signature Chains to a Root of Trust**

The enclave's signature is backed by a **certificate chain** — a sequence of digital certificates where each one vouches for the next, leading all the way up to a trusted **root certificate authority** maintained by the hardware provider.

<figure><img src="/files/v7HUJzV3XVrVANhAinik" alt=""><figcaption></figcaption></figure>

This chain works the same way HTTPS certificates work for websites. When you visit your bank's website, your browser verifies the site's certificate chains to a trusted root authority. Here, the verifier checks that the attestation's certificate chains back to the hardware provider's root certificate.

The root certificate is public — the provider publishes it, and it's included in every proof payload. Anyone can verify the chain without needing special access or permission.

### **What TEE Attestation Proves**

When you verify a TEE attestation from this system, you know five things for certain:

#### **1. Genuine Hardware**

The certificate chain traces to a recognized root certificate authority. This is not a software signature that could be faked by compromising a server. It originates from purpose-built security hardware that is manufactured and controlled by the provider.

An attacker who compromises a server — gaining full root access to the operating system — still cannot forge a valid attestation. The signing keys live in hardware that the operating system cannot reach.

#### **2. Correct Code**

The measurement values in the attestation are fingerprints of the code that ran. By comparing them to the known-good values published at deployment time, you can confirm the enclave ran exactly the right software — not a modified version with backdoors, data exfiltration, or altered logic.

This is a powerful guarantee. Even if a malicious actor gains control of the deployment infrastructure, any code changes would produce different measurements, and the attestation would fail verification against the published values.

#### **3. Untampered Results**

The attestation includes a hash of the computation's output (the Merkle root, totals, and metadata). This hash is signed by the hardware. If anyone modified the results after the enclave computed them, the hash wouldn't match.

This prevents a "man in the middle" attack where someone intercepts the enclave's output and replaces it with different data before publishing. The hardware-signed hash makes any such modification detectable.

#### **4. Isolation During Processing**

The TEE architecture guarantees that during processing, nothing outside the enclave can access the data inside. Not the operating system, not the hypervisor, not other processes on the same machine, and not the cloud provider's infrastructure.

This means sensitive data — individual reserve positions, custodian breakdowns, the master secret — is protected by hardware barriers, not just software permissions. There's no admin account that can bypass the isolation.

#### **5. Data Binding**

Here's what makes this system's approach particularly strong: the Merkle root isn't signed separately from the attestation. It goes directly into the attestation's data field. When the hardware signature verifies, you've proven the hardware itself computed that exact root.

Many systems compute data in one place and then sign it somewhere else. That creates a gap — you trust the signer, but can't prove the computation was correct. Here, computation and attestation happen in the same sealed environment. They're cryptographically bound together.

This binding is the difference between "someone signed off on these numbers" and "these numbers were computed inside verified, tamper-proof hardware." The latter is a fundamentally stronger guarantee.

### **What the Enclave Cannot Do**

The enclave's isolation works both ways. The enclave:

* **Cannot access the internet** — no outbound network connections
* **Cannot access the disk** — no reading or writing to the server's storage
* **Cannot talk to other processes** — only communicates through its dedicated secure channel
* **Cannot persist data across restarts** — if the enclave restarts, its memory is wiped clean

This extreme isolation is a feature, not a limitation. It means there's no way for data to leak out through side channels, and no way for external interference to affect the computation.

It also means the enclave can't be used as a general-purpose server. It does one thing — process data, produce proofs — and it does it in complete isolation. This limited attack surface is a security advantage.

### **Code Measurements: The Software Fingerprint**

When the enclave image is built, the hardware computes measurements of the code — cryptographic fingerprints that capture exactly what software is loaded. These measurements typically cover:

| What's Measured       | What It Captures                                             |
| --------------------- | ------------------------------------------------------------ |
| The application image | The complete enclave package — all the code and dependencies |
| The system layer      | The kernel, boot configuration, and runtime environment      |
| The application layer | The specific application logic within the enclave            |

These measurements are included in every attestation. They serve as an unforgeable fingerprint of exactly what code ran.

**How verifiers use these measurements:** When a new version of the enclave is deployed, the expected measurement values are published. Verifiers compare the values in the attestation against the published values. If they match, the enclave ran the expected code. If they don't, something was changed — and the attestation should not be trusted.

This is like checking the serial number on a sealed product. The manufacturer publishes the expected serial number. If it doesn't match, the product may have been tampered with. Except here, the "serial number" is a cryptographic hash that covers every byte of the code — it's impossible to make a meaningful change without the hash changing.

### **TEE + ZK: Why Both?**

You might wonder: if the hardware guarantees the computation, why also include zero-knowledge proofs?

The answer is **defense in depth**. No single security mechanism is perfect:

* **TEE alone** means you're trusting hardware. If a theoretical vulnerability in the hardware were ever discovered, the guarantees would break. History has shown that hardware vulnerabilities do get found — Spectre, Meltdown, and various SGX attacks have demonstrated this.
* **ZK alone** means you're trusting mathematics and the proof setup process. If the setup were ever compromised, false proofs could be created. While the mathematics is sound, the implementation and setup ceremony introduce practical trust assumptions.
* **Both together** means an attacker would need to simultaneously break hardware security AND mathematical proofs — two completely independent systems with different attack surfaces. The probability of both failing at the same time is astronomically lower than either failing alone.

This layered approach is the same principle used in critical infrastructure: defense doesn't rely on a single barrier, no matter how strong that barrier is. Banks have vaults, cameras, guards, alarms, and insurance — not because any one of those is insufficient, but because the combination is far stronger than any individual measure.

### **The Broader Confidential Computing Movement**

TEEs are part of a larger trend called **Confidential Computing** — an industry movement to protect data not just at rest (stored encrypted) and in transit (encrypted during transfer), but also **in use** (encrypted during processing).

The Confidential Computing Consortium, backed by major technology companies, is driving standardization and adoption of these technologies. This system aligns with that movement, using TEE attestation as a foundational building block for verifiable, privacy-preserving computation.

As TEE technology evolves — with new platforms, stronger isolation models, and broader hardware support — this system's architecture is designed to adopt improvements without changing the fundamental security model. The attestation guarantee is the constant; the specific hardware is the variable.

### **In Practice**

From a user's or verifier's perspective, TEE attestation is straightforward:

1. Receive a proof payload
2. Extract the attestation document
3. Verify the certificate chain leads to the provider's root certificate
4. Check the code measurements match the expected version
5. Confirm the data hash in the attestation matches the proof's data

If all checks pass, you have hardware-grade assurance that the computation was genuine. The verification process is documented in [Verification](/proof-of-reserve-network/verification)


# Zero-Knowledge Proofs

This section explains how mathematical proofs verify that computations are correct, without revealing the private data behind them.

### **The Idea Behind Zero-Knowledge Proofs**

Imagine you want to prove to someone that you know the combination to a safe, without actually telling them the combination. You could open the safe in front of them. They'd be convinced you know the combination, but they still wouldn't know what it is.

**Zero-knowledge proofs** (ZKPs) work the same way, but with math. They let you prove a statement is true like "these numbers add up to this total" without revealing what the numbers are.

This might sound like magic, but it's well-established mathematics. Zero-knowledge proofs have been studied since the 1980s and are used today in blockchains, digital identity systems, and privacy-preserving applications worldwide.

### **Why ZKPs Matter in This System**

This system handles sensitive financial data. Individual reserve positions, custodian-level breakdowns, liability details — this information needs to stay private. But the aggregate numbers like total reserves, total liabilities need to be provably correct.

ZKPs solve this tension. They let the system publish **totals** that anyone can see, while keeping the **breakdown** private, and providing mathematical proof that the totals are computed correctly from the hidden values.

Without ZKPs, you'd face an impossible choice:

* **Full transparency** — publish everything, including sensitive business data
* **Full privacy** — publish nothing, and ask people to trust you

ZKPs give you a third option: **privacy with proof**.

### **What This System Proves with ZKPs**

Two types of proofs are generated for every attestation:

#### **1. The Merkle Root Is Correct**

The Merkle root is the single hash that represents all committed data (see [Merkle Trees, Commitments & Chaining](/proof-of-reserve-network/merkle-trees-commitments-and-chaining)). The ZK proof demonstrates that this root was correctly computed from the individual commitments.

**What this means for you:** No one fabricated the root. It genuinely came from hashing all the committed values in the proper structure. The data integrity is mathematically guaranteed.

#### **2. The Totals Are Correct**

Two separate sum proofs are generated:

* **Reserves proof** — proves the individual reserve values add up to the published total reserves
* **Liabilities proof** — proves the individual liability values add up to the published total liabilities

**What this means for you:** The published totals ($X in reserves, $Y in liabilities) are exactly the sum of the actual positions. No values were added, removed, or altered. And crucially, you can verify this without seeing what each individual position is.

**Analogy:** Imagine a teacher announces that the class average on a test was 82%. A ZK proof would let you verify that 82% is the correct average of all student scores, without revealing any individual student's score.

### **How It Works (Without Getting Too Technical)**

#### **The Setup (One-Time)**

Before the system can generate proofs, a one-time setup process creates two special keys:

* **Proving key** — used by the system to generate proofs (stays with the system)
* **Verification key** — used by anyone to check proofs (public, included in every payload)

This setup is called a **trusted setup ceremony**. It's done once, and the resulting keys are used for all future proofs. The keys are specific to the computation being proven — if the computation changes, new keys are needed.

#### **Proof Generation (Every Attestation)**

When the system processes new data, it:

1. Takes the private inputs (individual values and their secrets)
2. Takes the public inputs (the total, the Merkle root)
3. Feeds them into the proof system
4. Produces a compact proof, just a few hundred bytes, regardless of how much data went in

The proof generation uses a system called **Groth16**, which is one of the most widely used and well-audited zero-knowledge proof systems. It's known for producing very small proofs that can be verified very quickly.

#### **Verification (Anyone, Anytime)**

To verify a ZK proof, you need three things:

* The proof itself
* The public values (totals, Merkle root)
* The verification key

The verification is a single mathematical check that returns either "valid" or "invalid." There's no gray area. If it's valid, the computation was correct. Period.

Verification is fast. It takes milliseconds and can be done by anyone with the proof payload. No special access, no credentials, no need to contact the system.

### **What Makes ZK Proofs Trustworthy?**

#### **Mathematical Soundness**

ZK proofs are based on well-studied mathematical problems. The security doesn't depend on hardware, network configuration, or operational practices. It depends on mathematics.

If the proof verifies, the computation was correct. This isn't a probabilistic statement or an estimate. It's a mathematical certainty (with negligible error probability, like 1 in 2^128, which is effectively impossible).

#### **Public Verification**

Anyone can verify. The verification key is public and included in every proof payload. There's no gatekeeper, no API to call, no permission needed. You can verify offline, on your own machine, using open-source tools.

#### **Compact and Efficient**

Regardless of how many values go into the computation, the proof is always the same small size which is roughly 200 bytes. This makes it practical to store, transmit, and verify proofs at scale.

#### **Independence from Hardware**

ZK proofs are purely mathematical. They don't rely on any hardware, cloud provider, or trusted third party. Even if the TEE hardware were theoretically compromised, the ZK proofs would still hold.

This independence is what makes the combination of TEE and ZK so powerful — they provide overlapping guarantees through completely different mechanisms.

### **Privacy Guarantees**

What ZK proofs reveal and hide in this system:

| Revealed (Public)                  | Hidden (Private)                          |
| ---------------------------------- | ----------------------------------------- |
| Total reserves                     | Individual reserve amounts per custodian  |
| Total liabilities                  | Individual liability amounts per position |
| Merkle root                        | The values behind each commitment         |
| Whether reserves cover liabilities | Exact collateralization ratio breakdown   |
| Proof validity (correct/incorrect) | Master secret and derived salts           |

The public information is enough for users to verify that the system is properly collateralized. The private information protects sensitive business relationships and competitive positions.

### **Collateralization Verification**

After both sum proofs are generated, the system checks:

> Are total reserves greater than or equal to total liabilities?

This simple comparison, combined with the ZK proofs guaranteeing both totals are correct, gives verifiers cryptographic assurance of the collateralization status.

The result — `isCollateralized: true` or `false` — is included in every proof payload.

### **The Bigger Picture**

ZK proofs are one layer in this system's security model:

<figure><img src="/files/Mx06Grh9dDJIN6GxRdOV" alt=""><figcaption></figcaption></figure>

Each layer is independent. Each provides its own guarantees. Together, they create a level of verifiability that no single mechanism could achieve alone.

For the technical community: the system uses Groth16 proofs over the BN128 curve, with Poseidon hashing for ZK-friendly commitments and keccak256 for EVM-compatible commitments. Circuit implementations and verification keys are open and auditable.


# Merkle Trees, Commitments & Chaining

This section explains how individual data points are fingerprinted, hidden, organized into a tamper-evident structure, and linked across time to create an immutable historical record.

### **Starting with Commitments**

Before we get to Merkle trees, we need to understand **commitments** as they're the building blocks.

#### **What Is a Commitment?**

A commitment is a way of locking in a value without revealing it. Think of it as putting a number in a sealed, tamper-evident envelope:

* **You can't see inside** — the commitment reveals nothing about the value
* **You can't swap it out** — once committed, the value is fixed
* **You can prove it later** — when you reveal the value, anyone can verify it matches the commitment

In this system, a commitment is created by combining a value with a **salt** (a unique secret) and running them through a hash function:

```
commitment = hash(value + salt)
```

The hash function is a one-way process. Given a value and salt, anyone can compute the commitment. But given only the commitment, it's impossible to figure out what value and salt produced it.

#### **Why Salts Are Essential**

Without a salt, commitments would be vulnerable to guessing. If someone knows the possible range of values (say, dollar amounts between $1 million and $100 million), they could hash each possibility until they find one that matches the commitment.

The salt eliminates this attack. Even if you know the value, you can't verify it without the salt. And salts in this system are derived from a private master secret. They never leave the secure enclave.

**Analogy:** Imagine a sealed envelope containing a number. Without a salt, it's like the envelope is slightly translucent. If there are only a few possible numbers, you might be able to tell which one is inside. With a salt, the envelope is completely opaque. The salt is like a unique, unpredictable padding that makes every envelope look identical from the outside.

#### **Dual Commitments**

The system creates **two commitments** for each value:

| Type              | Technology | Purpose                                                                 |
| ----------------- | ---------- | ----------------------------------------------------------------------- |
| Public commitment | keccak256  | Compatible with Ethereum smart contracts and widely used auditing tools |
| ZK commitment     | Poseidon   | Optimized for zero-knowledge proof systems                              |

Both commitments lock in the same value. They just use different mathematical methods suited for different verification contexts. The public commitment is the one external auditors and smart contracts would check. The ZK commitment is the one used inside the zero-knowledge proof system.

### **Now: Merkle Trees**

#### **What Is a Merkle Tree?**

A Merkle tree is a way of combining many fingerprints into one. It's named after Ralph Merkle, who invented it in 1979. The concept is used everywhere today — in Git (version control), in Bitcoin and Ethereum, in certificate transparency, and in file verification systems.

The idea is simple:

1. Start with all your commitments as **leaves** at the bottom
2. Pair them up and hash each pair together to create a **parent**
3. Keep pairing and hashing until you have a single hash at the top — the **root**

<figure><img src="/files/Zft2l5d5jBr2hJzrCZ2V" alt=""><figcaption></figcaption></figure>

* `A, B, C, D` are the individual value commitments
* `H(A+B)` means "hash of A combined with B"
* The root is a single hash that represents all four values

#### **Why Not Just Hash Everything Together?**

You could just concatenate all values and hash them once. But a Merkle tree gives you additional capabilities:

**Tamper evidence at the individual level.** If someone changes just one value (say, B), the root changes completely. But more importantly, you can trace exactly which branch was affected.

**Efficient selective verification.** If you want to prove that a specific value (say, C) is part of the tree, you only need to provide a few sibling hashes along the path to the root — not the entire dataset. This is called a **Merkle proof**.

**Consistent structure.** No matter how many values are committed, the root is always the same size (32 bytes). The tree scales without the root growing.

#### **A Real-World Analogy**

Imagine a company with four divisions. Each division seals its financial report in an envelope (commitment). Then:

* Divisions are paired: envelopes from Division A and B are sealed together in a larger envelope
* The same for C and D
* Finally, the two larger envelopes are sealed into one master envelope (the root)

If someone tampers with Division B's report, the seal on the A+B envelope breaks, which breaks the master seal. And you can check Division B's report without opening Division C or D's envelopes.

### **How the System Builds the Tree**

#### **Leaf Ordering**

Commitments are placed in the tree in a specific, deterministic order based on their field identifiers. This ensures that the same data always produces the same tree, regardless of the order it was submitted.

#### **Padding**

The tree always has a fixed number of leaf positions (16 in the current system). If fewer values are committed, the remaining positions are filled with placeholder values (zeros). This ensures the tree structure is always the same, which is required for the zero-knowledge proofs.

The orange nodes are real commitments; the gray nodes are zero-padded slots.

#### **Two Parallel Trees**

Just as there are two types of commitments (public and ZK), there are two parallel Merkle trees:

<figure><img src="/files/s4EUuXCYKVFCRrdHdfys" alt=""><figcaption></figcaption></figure>

Both trees have identical structure and leaf ordering. The only difference is the hash function used. The public root goes into the TEE attestation and is verifiable by anyone. The ZK root is used inside the zero-knowledge proof circuit.

### **What the Merkle Root Represents**

The Merkle root is the cornerstone of the proof payload. It's a single, compact fingerprint that represents:

* Every reserve value
* Every liability value
* Every salt used
* The exact ordering and structure of the data

Change any single value, alter any salt, or reorder any element — the root changes completely.

This root is what the TEE hardware attests (see [Trusted Execution Environments](/proof-of-reserve-network/trusted-execution-environments-tee)) and what the ZK proof verifies (see [Zero-Knowledge Proofs](/proof-of-reserve-network/zero-knowledge-proofs)). It's the anchor point that connects every layer of the system's security.

### **Timeseries Chaining**

#### **The Problem with Standalone Proofs**

Imagine the system produces a proof every hour. Each proof confirms that at that moment, reserves and liabilities had certain values. That's useful — but what stops someone from going back and replacing last Tuesday's proof with a fabricated one?

If each proof stands alone, there's no way to tell. An attacker could:

* **Replace** an old proof with one showing different numbers
* **Delete** a proof from the history entirely
* **Reorder** proofs to misrepresent the timeline
* **Insert** fabricated proofs between legitimate ones

The individual proof would still verify correctly (it has valid attestation and ZK proofs). But the historical record would be a lie.

#### **The Solution: Chain the Roots**

Timeseries chaining solves this by making each proof **depend on the one before it**. When a new proof is generated, it includes the previous proof's Merkle root. The two roots are combined to create a **chained root**.

<figure><img src="/files/qNIE0UPCJ8yxDC8nQwNe" alt=""><figcaption></figcaption></figure>

* **Proof #1** has no predecessor. It's the start of the chain, so its chained root is just its own root.
* **Proof #2** references Proof #1's root. Its chained root combines both.
* **Proof #3** references Proof #2's root. The chain continues.

Each link in the chain is like a knot in a rope — pull on any knot, and everything downstream shifts.

#### **What Chaining Prevents**

**Replacing a historical proof:** If an attacker replaces Proof #2 with fabricated data, the fabricated proof would have a different root. Proof #3 references Proof #2's original root — so the chain breaks. To get away with it, the attacker would need to re-forge every subsequent proof, each with valid hardware attestation and ZK proofs. That's effectively impossible.

**Deleting a proof:** If someone removes Proof #2, Proof #3 references a root that no longer exists. The gap is immediately obvious.

**Reordering proofs:** Each proof explicitly references its predecessor. Swapping them would mean a proof references a future proof — the ordering is self-evident.

**Inserting fabricated proofs:** Inserting between existing proofs would break the chain, because the subsequent proof already references the correct predecessor.

#### **Why This Is Like a Blockchain**

If this sounds familiar, it's because blockchains use the same principle. Each block contains the hash of the previous block, forming a chain that can't be modified without redoing all subsequent blocks.

|                 | Blockchain             | This System                      |
| --------------- | ---------------------- | -------------------------------- |
| **Chain links** | Blocks of transactions | Individual proof attestations    |
| **Secured by**  | Consensus (many nodes) | Hardware attestation + ZK proofs |
| **Purpose**     | Decentralized ledger   | Verifiable financial data        |
| **Frequency**   | Minutes (block time)   | On-demand (per attestation)      |

#### **Starting a New Chain**

Sometimes it's necessary to start a fresh chain — for example, when deploying a new version of the system or beginning a new data feed. In these cases, the system can generate a proof with no predecessor, creating a new chain from scratch.

This is an explicit action. The proof payload clearly indicates that there is no previous root, so verifiers know this is a chain start, not a broken link.

#### **Verifying the Chain**

To verify the chain between any two consecutive proofs:

1. Take the earlier proof's root
2. Take the later proof's root
3. Confirm the later proof's "previous root" field matches the earlier proof's root
4. Recompute the chained root and confirm it matches

To verify the full history, walk the chain from the first proof to the latest, checking each link.

### **Verification**

Verifiers can check the Merkle root by:

1. Taking all the commitments from the proof payload
2. Rebuilding the tree using the same algorithm
3. Confirming the recomputed root matches the root in the attestation

If the roots match, the commitments are the ones that were attested — nothing was added, removed, or changed after the hardware signed off.

### **Public Commitments Mode**

The system supports an optional **public commitments** mode for when transparency is more important than privacy:

| Mode              | What's Visible                            | Use Case                             |
| ----------------- | ----------------------------------------- | ------------------------------------ |
| Private (default) | Only commitments — values hidden          | Production use where privacy matters |
| Public            | Raw values included alongside commitments | Full transparency scenarios          |

In public mode, anyone can see the individual values. The Merkle tree and commitments still provide tamper evidence, but privacy is not the goal — auditability is.

### **Key Properties**

| Property                     | What It Means                                               |
| ---------------------------- | ----------------------------------------------------------- |
| **Tamper-evident**           | Changing any value changes the root                         |
| **Privacy-preserving**       | Commitments hide values; only the root is public            |
| **Deterministic**            | Same data always produces the same root                     |
| **Compact**                  | One 32-byte root represents all data                        |
| **Independently verifiable** | Anyone can rebuild the tree and check the root              |
| **Selectively provable**     | Individual values can be revealed without exposing others   |
| **Historically linked**      | Each proof chains to the previous one, preventing tampering |


# Verification

This section explains how anyone can independently verify a proof, confirming that the data is authentic, untampered, and correctly computed. No special access or credentials required.

### **The Promise of Independent Verification**

Every claim this system makes can be checked by anyone, anywhere, without trusting the system operator. The proof payload contains everything needed for verification — certificates, keys, proofs, and data. A verifier works entirely independently.

This is a fundamental design principle: **don't trust, verify.**

### **What's in a Proof Payload**

Before diving into verification steps, here's what a proof payload contains:

| Section                  | What's Inside                                                                         |
| ------------------------ | ------------------------------------------------------------------------------------- |
| **Metadata**             | Version, data feed identifier, timestamp, unique proof ID                             |
| **Verified Totals**      | Total reserves and total liabilities in USD                                           |
| **Merkle Proof**         | The root hash, all field commitments, and the previous root (for chain verification)  |
| **TEE Attestation**      | The hardware-signed attestation document, code measurements, and attested data fields |
| **ZK Proofs**            | Mathematical proofs for the Merkle root and sum computations                          |
| **Verification Context** | Root CA certificate and ZK verification keys                                          |

Everything needed to verify is included. No external calls, no APIs, no downloads.

### **The Five Verification Checks**

A complete verification performs five independent checks. Each one validates a different aspect of the proof:

<figure><img src="/files/NNb0JkIzUmJpGkpf0dA1" alt=""><figcaption></figcaption></figure>

Let's walk through each one.

#### **Check 1: Hardware Authenticity**

**Question:** Was this attestation produced by genuine TEE hardware?

**How it's verified:**

The attestation document is signed by the enclave's hardware. That signature is backed by a certificate chain — a sequence of digital certificates, each vouching for the next, leading all the way up to the hardware provider's Root Certificate Authority.

Think of it like verifying a passport:

* The passport (attestation) has a stamp (signature)
* The stamp traces to a local authority (enclave certificate)
* The local authority traces to a national authority (intermediate certificate)
* The national authority traces to an internationally recognized body (Root CA)

If the chain is valid and unbroken, the attestation came from genuine hardware. The Root CA certificate is publicly known and included in the payload for convenience.

**What passing means:** A real TEE enclave produced this attestation. It's not a software-generated fake.

#### **Check 2: Code Integrity**

**Question:** Was the enclave running the correct, unmodified software?

**How it's verified:**

The attestation includes code measurement values — fingerprints of the software that ran inside the enclave. These are compared against the **expected values** published when the software was deployed. They must match exactly.

Think of it like a seal on a software package. When the manufacturer ships the software, they publish the seal's pattern. When you receive the package, you check the seal. If it matches, the software hasn't been tampered with.

**What passing means:** The enclave ran the expected software. No modifications, no backdoors, no unauthorized changes.

#### **Check 3: Data Binding**

**Question:** Does the attestation actually cover the data in this payload?

**How it's verified:**

The attestation document contains a data hash. This is the value that the hardware signed. The verifier:

1. Takes the attested data from the payload (Merkle root, total reserves, total liabilities, proof ID, feed ID, timestamp)
2. Recomputes the hash from those values
3. Compares it to the data hash in the attestation

If they match, the hardware attested exactly this data, not some other data that was swapped in later.

**Why this matters:** Without this check, someone could take a valid attestation from one computation and attach it to different data. The data binding ensures the attestation and the payload are inseparable.

**What passing means:** The data in this payload is exactly what the hardware computed and signed. Nothing was swapped or modified after attestation.

#### **Check 4: Mathematical Correctness**

**Question:** Are the computations provably correct?

**How it's verified:**

Three ZK proofs are checked:

**A. Merkle Root Proof** Verifies that the published Merkle root was correctly computed from the leaf commitments. This ensures the root genuinely represents the committed data.

**B. Reserves Sum Proof** Verifies that hidden individual reserve values add up to the published total reserves. This ensures the total isn't fabricated.

**C. Liabilities Sum Proof** Verifies that hidden individual liability values add up to the published total liabilities. Same guarantee as above.

Each verification is a mathematical check using the verification keys included in the payload. The check returns a simple yes or no — there's no ambiguity.

**What passing means:** The Merkle root is correctly computed. The total reserves are the true sum of individual reserves. The total liabilities are the true sum of individual liabilities. All of this is proven with mathematical certainty.

#### **Check 5: Merkle Root Consistency**

**Question:** Do the commitments in the payload actually produce the claimed root?

**How it's verified:**

The verifier takes all the field commitments from the payload and rebuilds the Merkle tree from scratch. If the recomputed root matches the root in the attestation, the commitments are genuine.

This check closes the loop: the commitments produce the root, the root is attested by hardware, the ZK proof confirms the computation. Everything connects.

**What passing means:** The commitments in the payload are the original ones — nothing was added, removed, or altered after the tree was built.

### **What Full Verification Tells You**

If all five checks pass, you know:

| Statement                               | Guarantee                                             |
| --------------------------------------- | ----------------------------------------------------- |
| The proof came from real hardware       | Certificate chain validates to the provider's Root CA |
| The correct code was running            | Code measurements match expected values               |
| The data hasn't been swapped            | Attestation hash matches payload data                 |
| The totals are mathematically correct   | ZK proofs verify                                      |
| The commitments are genuine             | Merkle root recomputation matches                     |
| The system is (or isn't) collateralized | Total reserves vs. total liabilities                  |

This isn't "probably correct" or "we checked and it looked fine." It's cryptographic certainty backed by hardware and mathematics.

### **What If a Check Fails?**

| Failed Check             | What It Might Mean                                                                                  |
| ------------------------ | --------------------------------------------------------------------------------------------------- |
| Hardware authenticity    | The attestation wasn't produced by genuine TEE hardware — it may be fabricated                      |
| Code integrity           | The enclave ran different code than expected — the software may have been modified                  |
| Data binding             | The payload data doesn't match what was attested — the data may have been swapped after computation |
| Mathematical correctness | The computation has errors or the proofs were fabricated — the totals may not be correct            |
| Merkle root consistency  | The commitments were altered after the tree was built — the data may have been tampered with        |

Any single failure means the proof should not be trusted. The system is designed so that all checks must pass.

### **Verification Is Optional but Available**

Not every consumer of this data needs to run full verification. Different audiences have different needs:

| Audience           | Typical Approach                                                               |
| ------------------ | ------------------------------------------------------------------------------ |
| End users          | Check the collateralization status; trust that the protocol runs verification  |
| Protocol operators | Run full verification on every proof; alert on failures                        |
| Auditors           | Run full verification; also check code measurements against deployment records |
| Regulators         | Run full verification; may also request raw data disclosure with salts         |
| Researchers        | Run full verification; inspect proof structure and timing                      |

The important thing is that verification **can** be done by anyone. The option is always there.

### **Offline Verification**

The proof payload is self-contained. Verification doesn't require:

* An internet connection
* Access to the system's servers
* An API key or credentials
* Any proprietary software

All you need is the proof payload and open-source verification tools. The system provides reference verification scripts, and the payload format is documented so anyone can build their own verifier.

### **Chain Verification**

Beyond verifying individual proofs, you can verify the **chain** between consecutive proofs:

1. Take two consecutive proofs
2. Confirm the later proof's "previous root" matches the earlier proof's root
3. Verify the chained root was correctly computed

This ensures the historical sequence is intact. See [Merkle Trees, Commitments & Chaining](/proof-of-reserve-network/merkle-trees-commitments-and-chaining)for details.

### **Browser Verification**

The system includes a browser-compatible verification reference, meaning proofs can be verified directly in a web browser without any server-side processing. This is particularly useful for:

* Building user-facing dashboards that verify proofs in real time
* Allowing anyone to verify proofs without installing anything
* Embedding verification into web applications

**For Self Verification here is the Repo:** \
<https://github.com/Artificial-Financial-Intelligence/por-proof-verifier-script>&#x20;


# Security Model

This section provides a complete picture of the system's security architecture — what's protected, what's public, how the layers work together, and what the limitations are.

### **The Security Philosophy**

This system is built on a simple principle: **no single point of failure.**

Every critical guarantee is backed by at least two independent mechanisms. Hardware attestation and mathematical proofs. Cryptographic commitments and Merkle trees. Timeseries chaining and certificate verification.

An attacker would need to break multiple, unrelated systems simultaneously. Compromise the hardware? The math still holds. Forge the math? The hardware attestation still catches it. Tamper with the data? The Merkle root changes. Modify historical proofs? The chain breaks.

This is called **defense in depth** — the same principle used in banking vaults, nuclear facilities, and aviation safety. No single barrier is assumed to be unbreakable. Security comes from the combination.

### **What Stays Private**

These values never leave the secure enclave and are never included in proof payloads:

| Private Data          | Why It Must Stay Private                                                                                                                 |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **Master secret**     | The key used to derive all salts. If exposed, every commitment could be opened, revealing all historical values.                         |
| **Individual values** | Per-custodian reserve amounts, per-position liability amounts. This is sensitive business data that reveals relationships and positions. |
| **Derived salts**     | The unique secrets mixed into each commitment. Knowing a salt and a commitment lets you recover the value.                               |
| **Raw input data**    | The unprocessed financial data before it enters the cryptographic pipeline.                                                              |

These values exist only in the enclave's memory during computation. When the enclave finishes processing, they're gone. The enclave has no persistent storage. If it restarts, its memory is wiped clean.

### **What's Public**

These values are included in every proof payload and are safe to publish:

| Public Data                  | Why It's Safe                                                                   |
| ---------------------------- | ------------------------------------------------------------------------------- |
| **Commitments**              | One-way fingerprints can't be reversed to find the value without the salt       |
| **Merkle roots**             | A single hash representing all data reveals nothing about individual values     |
| **Total reserves**           | The aggregate amount across all custodians (individual breakdown hidden)        |
| **Total liabilities**        | The aggregate amount across all positions (individual breakdown hidden)         |
| **ZK proofs**                | Mathematical proofs that verify correctness reveal nothing about private inputs |
| **Attestation document**     | The hardware's signed statement needed for verification                         |
| **Code measurements**        | Fingerprints of the code that ran public knowledge                              |
| **Verification keys**        | Needed by anyone who wants to verify the proofs                                 |
| **Root CA certificate**      | The hardware provider's public trust anchor that’s already publicly available   |
| **Collateralization status** | Whether reserves cover liabilities, the key fact users care about               |

The design ensures that everything a verifier needs is public, while everything an attacker would want stays private.

### **The Four Security Layers**

<figure><img src="/files/3PXYXpt9RSwIQ2AdSuvI" alt=""><figcaption></figcaption></figure>

#### **Layer 1: Hardware Isolation (TEE)**

The TEE enclave is a hardware-isolated environment. During computation:

* The server operator cannot read the enclave's memory
* The host operating system cannot access the enclave
* Other processes on the same machine are completely separated
* Even the cloud provider's own infrastructure team cannot peek inside

The enclave produces a hardware-signed attestation that traces back to the provider's root certificate. This proves genuine hardware produced the result.

**What it doesn't protect against:** A theoretical compromise of the hardware design itself. This is why Layer 2 exists.

#### **Layer 2: Zero-Knowledge Proofs**

ZK proofs provide mathematical certainty that:

* The Merkle root was correctly computed from the commitments
* The individual values sum to the published totals

This layer is completely independent of hardware. The proofs are based on mathematics, not trust in any manufacturer or operator. Even if the TEE were somehow compromised, the math still holds.

**What it doesn't protect against:** A compromised trusted setup ceremony (the one-time key generation). This is why Layer 1 exists — it provides an independent guarantee.

#### **Layer 3: Cryptographic Commitments & Merkle Trees**

Commitments hide individual values using strong, well-studied hash functions. Merkle trees organize commitments into a single root that changes completely if any value is modified.

These are standard cryptographic primitives used across the industry — in blockchains, in certificate transparency, in secure messaging. Their security properties are well-understood and battle-tested.

**What it doesn't protect against:** If the master secret is exposed, all salts can be derived and commitments opened. This is why the master secret lives only inside the enclave.

#### **Layer 4: Timeseries Chaining**

Each proof chains to the previous one. Modifying, deleting, or reordering any proof in the history breaks the chain from that point forward.

This is the same principle that makes blockchains tamper-evident. The difference is that here, individual proofs are also backed by hardware attestation and ZK proofs.

**What it doesn't protect against:** A completely fresh start (someone could start a new chain). This is detectable because the first proof in a chain explicitly has no predecessor — it's visible in the payload.

### **How the Layers Overlap**

The real strength of this system isn't any single layer — it's how they overlap:

<figure><img src="/files/jE7CVzTZdQK5F8djqM8C" alt=""><figcaption></figcaption></figure>

Each layer covers gaps that others leave. Together, they create comprehensive coverage.

### **Threat Analysis**

#### **Threats the system handles:**

| Threat                                      | How It's Handled                                                                          |
| ------------------------------------------- | ----------------------------------------------------------------------------------------- |
| **Server is hacked**                        | TEE isolation — attacker can't read enclave memory or modify computation                  |
| **Operator is malicious**                   | TEE + ZK — operator never touches the computation; proofs verify independently            |
| **Data is tampered with after computation** | Merkle root + data binding — any change invalidates the attestation                       |
| **Historical proofs are modified**          | Timeseries chaining — modification breaks the chain                                       |
| **Values are guessed from commitments**     | Salted commitments — guessing requires the salt, which never leaves the enclave           |
| **Totals are fabricated**                   | ZK sum proofs — mathematical proof that totals are correct                                |
| **Wrong code is deployed**                  | Code measurements — fingerprints are verified against published values                    |
| **Proofs are fabricated from scratch**      | Certificate chain — must trace to the provider's Root CA, which requires genuine hardware |

#### **Threats the system does NOT handle:**

| Limitation                   | Explanation                                                                                                                                                  | Mitigation                                                                                                                                                         |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Bad input data**           | If a custodian reports false reserves, the system faithfully attests the wrong number. The system proves *computational integrity*, not *data truthfulness*. | Use multiple data sources and cross-reference. The system is one layer in a broader trust framework.                                                               |
| **Hardware vulnerability**   | A theoretical, undiscovered vulnerability in TEE hardware could compromise isolation guarantees.                                                             | ZK proofs provide an independent mathematical guarantee. Both would need to fail simultaneously.                                                                   |
| **Trusted setup compromise** | If the ZK trusted setup ceremony was dishonest, false proofs could be generated.                                                                             | TEE attestation provides an independent hardware guarantee. Both would need to fail simultaneously.                                                                |
| **Master secret exposure**   | If the master secret leaks, all historical commitments could be opened (values revealed).                                                                    | The secret lives only inside the enclave. There's no API to extract it, and the enclave has no persistent storage or network access. Key rotation allows recovery. |

### **Financial Data Precision**

Financial data requires exact arithmetic. A rounding error of $0.01 across millions of transactions can accumulate into meaningful discrepancies. The system addresses this through:

* **Integer arithmetic** — all USD values are converted to integer form (multiplied by 1,000,000) before any computation. There are no floating-point numbers in the critical path.
* **Arbitrary precision** — the system uses a specialized decimal arithmetic library that handles numbers of any size without rounding errors.
* **Consistent formatting** — output values are always presented with 2 decimal places for clarity, but computed with 6 decimal places of precision internally.

This means $1.00 is always exactly $1.00 — never $0.999999 or $1.000001.

### **Key Management**

#### **Master Secret**

The master secret is the most sensitive value in the system. It's used to derive all salts, which protect all committed values. The system protects it through:

* **Enclave-only access** — the secret exists only inside the TEE during computation
* **No persistent storage** — the enclave has no disk; if it restarts, the secret must be re-provided
* **No network access** — the enclave cannot send the secret anywhere
* **HMAC derivation** — the secret is never used directly in commitments; it generates salts through a one-way function

#### **Key Versioning**

Salts include a version number in their derivation. This means:

* The master secret can be rotated if needed
* Old proofs remain valid with their version's salts
* New proofs use the updated version
* There's a clean transition path without invalidating history

#### **Enclave Certificates**

Each attestation includes an enclave certificate with an expiration time. This is a short-lived certificate generated by the hardware for that specific attestation. Verifiers should check that the certificate was valid at the time of attestation.

### **Comparison to Other Approaches**

| Approach             | Trust Requirement                    | This System's Advantage                                          |
| -------------------- | ------------------------------------ | ---------------------------------------------------------------- |
| Trusted oracle       | Trust the oracle operator            | No operator trust needed — hardware + math prove correctness     |
| Multi-sig committee  | Trust the majority of signers        | No human signers — verification is automated and deterministic   |
| Periodic audits      | Trust the auditor; snapshots in time | Continuous, real-time verification; no waiting for audit cycles  |
| On-chain only        | Limited to on-chain data             | Works with off-chain data (real-world assets, bank reserves)     |
| Software attestation | Trust the software environment       | Hardware attestation — the physical chip signs, not the software |

### **Summary**

The security model is built on overlapping guarantees:

1. **Hardware** (TEE) guarantees the computation environment is genuine and isolated
2. **Mathematics** (ZK proofs) guarantees the computations are correct
3. **Cryptography** (commitments & Merkle trees) guarantees data integrity and privacy
4. **Hash chaining** (timeseries) guarantees historical continuity

No single layer needs to be perfect. The system is secure as long as an attacker cannot break all layers simultaneously — which would require compromising both hardware and mathematics, an extraordinarily difficult proposition.


# Overview

Tokenization solved the *representation* problem — converting real-world assets into transferable digital tokens.\
What it did **not** solve is the *verification* problem: proving, in real time, that those tokens remain fully backed by their underlying reserves.

AFI introduces **Proof-of-Reserve (PoR) Vaults** as a foundational primitive for the RWA ecosystem.\
These vaults create a **cryptographically enforced linkage** between off-chain collateral, on-chain supply, and DeFi composability.

***

### **What AFI Proof Of Reserve Vaults Do**

At their core, AFI PoR Vaults perform three functions:

#### **1. Escrow On-Chain the Tokenized Asset**&#x20;

The issuer deposits their entire supply of the tokenized asset (e.g., `rwaX`) into a **non-custodial ERC-4626 vault**.

* The vault locks and publicly displays the balance.
* These tokens cannot be rehypothecated, redirected, or silently re-used.
* This creates a **verifiable, immutable reserve floor.**

***

#### **2. Mint a New Receipt Token with Cryptographic Supply Limits**

When the vault receives the base RWA token, it mints **afi-rwaX** — an ERC-4626 receipt token representing provably backed collateral.

* **afi-rwaX supply cannot exceed the balance of rwax held in the vault.**
* The cap is enforced by the vault contract itself.
* Anyone can independently verify the mint cap using on-chain data.

This converts issuer-backed assets into **math-backed assets**.

***

#### **3. Bind Off-Chain Reserves to On-Chain Enforcement**

AFI integrates reserve attestations into a **Proof Registry** that encodes the relationship:

```
afi-rwaX supply ≤ rwaX locked < attested off-chain reserves
```

In practice:

* The left inequality is enforced by the contract (cannot mint beyond on-chain collateral).
* The right inequality is enforced by continuous reserve attestations (via auditors, oracles, or AVS networks).
* Any discrepancy triggers alerts or supply restrictions.

This creates a **real-time solvency guarantee**, anchored both on-chain and off-chain.

***

### **Why This Is Transformative**

AFI’s PoR Vaults fundamentally change how RWA tokens behave:

#### **A. RWA Tokens Stop Being “Issuer IOUs”**

Traditional RWA tokens rely on:

* Custodian certificates
* Corporate balance sheets
* Legal contracts
* Human trust

AFI converts them into **cryptographically enforced assets**, with deterministic visibility into reserves.

***

#### **B. DeFi Protocols Gain a Safe RWA Collateral Layer**

Protocols like Aave, Compound and Morpho require:

* Programmatic verifiability
* Deterministic risk limits
* Predictable solvency

afi-rwaX satisfies all three:

* It is always **fully collateralized** by locked rwaUSD.
* Its supply cannot exceed verified reserves.
* Its backing is independently confirmable by any contract.

This unlocks:

* Lending markets
* Stablecoin minting
* Structured yield products
* On-chain treasuries

All without counterparty risk.

***

#### **C. Issuers Gain Institutional-Grade Transparency**

For RWA issuers, AFI becomes a **distribution and trust layer**:

* Reserves → Attested
* Tokens → Verified
* Integrations → Safe
* Liquidity → Composable
* Market Access → Expanded

Issuers effectively “upgrade” their tokens into assets that DeFi can use safely.

***

### **From Human Assurance to Programmatic Proof**

With AFI, the RWA stack evolves:

**Before AFI**

* Issuers provide PDFs
* Users trust issuers
* DeFi trusts users
* Risk flows downstream unchecked

**With AFI**

* Issuers deposit & attest reserves
* Vaults enforce supply limits
* On-chain proofs confirm solvency
* DeFi integrates fully verified collateral

The trust chain moves from **people → paperwork → protocols**.


# Launching Institutional afi-rwaUSDi Vault

AFI is introducing the **afi-rwaUSDi Institutional Vault**, a dedicated Proof-Of-Reserve vault backed by less liquid assets like market-neutral funds, private credit, etc.\
\
This vault represents the first institutional deployment of AFI’s **on-chain reserve verification framework**, enabling regulated issuers to bring real-world collateral on-chain with transparent, mathematically enforced backing.\
\
rwaUSDi asset is issued by [Multipli](https://multipli.fi/).

***

### **Overview**

The afi-rwaUSDi Vault is built to solve the core challenge of RWA integration:

> **Off-chain collateral cannot be verified or enforced by smart contracts.**

By locking rwaUSDi inside an ERC-4626 PoR Vault and minting **afi-rwaUSDi** as the on-chain receipt token, AFI creates a **provable, deterministic link** between:

1. **Less liquid assets like** market-neutral funds, private credit, etc.
2. **Tokenized rwaUSDi supply**
3. **Circulating afi-rwaUSDi in DeFi**

This transforms gold-backed assets from *issuer-dependent claims* into **cryptographically verifiable collateral**, suitable for institutional deployment across DeFi.

***

## **Vault Architecture**

#### **1. Reserve Tokenization (Off-Chain → On-Chain)**

The Assessed Entities hold a diversified pool of assets, including cash reserves, fund investments, strategic equity positions, and income-generating real-world operating assets.\
These reserves are tokenized as **rwaUSDi**, where:

* 1 rwaUSDi = $1 backed by market-neutral funds, private credit etc
* Backing is attested by custodians and independent auditors
* Supply reflects real-world gold holdings

***

#### **2. Locked Collateral (On-Chain POR Vault)**

The issuer deposits **100% of their rwaUSDi supply** into the AFI Proof-Of-Reserve Vault.\
The vault enforces:

```
afi-rwaUSDi supply ≤ rwaUSDi locked in vault
```

rwaUSDi becomes **non-circulating collateral**, fully visible on-chain.

***

#### **3. Minting of Institutional Receipt Token (afi-rwaUSDi)**

For every rwaUSDi deposited, the vault mints **1 afi-rwaUSDi**, a clean ERC-4626 receipt token engineered for DeFi composability.

afi-rwaUSDi is the **circulating asset**, that can be used by:

* Institutional treasuries
* DeFi lending protocols
* Liquidity pools
* Market makers
* Cross-chain integrations

This token is always provably backed by gold reserves.

***

## **Why This Structure Is Needed**

#### **1. RWA tokens are opaque by default**

Most RWA issuers publish reserve reports via PDFs, legal attestations, or monthly audits.\
These mechanisms cannot be read or trusted by smart contracts.

afi-rwaUSDi solves this by binding reserve backing to **on-chain enforcement**, not delayed documentation.

***

#### **2. On-chain solvency requires real-time constraints**

afi-rwaUSD cannot be over-minted or under-backed.\
The vault mathematically enforces full collateralization at the contract level:

* No entity can increase circulating supply
* No reserves can be silently redeployed
* No fractional exposure can occur
* No recursive minting (like xUSD) is possible

All supply changes require collateral deposits and are visible in real time.

***

#### **3. DeFi requires verifiable collateral—not issuer promises**

Protocols such as Aave, Morpho, Curve, Pendle, and money-market primitives cannot rely on off-chain trust.\
They require **deterministic invariants**, such as:

```
Circulating Tokens ≤ Verified Reserves
```

afi-rwaUSD provides this guarantee natively.

***

## **Flow Summary**

#### **Without AFI**

```
Real World Assets → Custodian → Issuer → rwaUSDi → DeFi (Unverified)
```

#### **With AFI Proof-of-Reserve**

```
Real World Assets → Custodian → rwaUSD → AFI PoR Vault → afi-rwaUSDi → DeFi (Verified)
```

afi-rwaUSDi is the first **institutional-grade, provably backed, composable RWA stablecoin**.


# afiUSD Vault

AFI POR USD Vaults are the foundational layer for generating and distributing yield across the protocol. Each vault adheres to the ERC-4626 standard and includes advanced features such as yield vesting, withdrawal cooldowns, and global cross-chain coordination. These vaults form the asset layer backing AFI’s index products such as afiUSD ( POR-USD Vault )

### afiUSD Vault <a href="#afiusd-vault" id="afiusd-vault"></a>

The <kbd>afiUSD</kbd> Vault is the primary implementation of the AFI yield infrastructure on supported chains. It is a fully compliant ERC-4626 vault with protocol-specific enhancements.

#### Key Features - <a href="#key-features" id="key-features"></a>

* **ERC-4626 Compliance** - Implements the full ERC-4626 tokenized vault interface, allowing seamless interoperability with other DeFi protocols.
* **Withdrawal Cooldown** - Introduces a **72-hour cooldown period** post-withdrawal request to allow strategy unwinding and ensure liquidity availability.
* **Yield Vesting** - Yield generated by AFI is incorporated into the vault's exchange rate **gradually**, smoothing accrual and preventing front-running or deposit-timing arbitrage.
* **Fee Management -** Fee Management supports configurable deposit and withdrawal fees, programmable at the vault or strategy level. Currently, both fees are set to 0.
* **Virtual Asset Accounting** - Tracks total assets under management, including **vested and unvested yield**, to provide accurate NAV computation.

***

### Cross-Chain Yield Distribution <a href="#cross-chain-yield-distribution" id="cross-chain-yield-distribution"></a>

afiUSD will operate vaults across multiple chains - each independently collecting deposits and generating yield. However, yield distribution is coordinated globally to ensure fairness and consistency in `afiUSD` value across all deployments.

#### Objectives - <a href="#objectives" id="objectives"></a>

* Maintain **one unified global exchange rate** for `afiUSD`
* Ensure users on all chains receive proportional yield
* Prevent liquidity fragmentation across deployments

### How Yield Distribution Works <a href="#how-yield-distribution-works" id="how-yield-distribution-works"></a>

#### Step 1: Collect Chain-Level Data <a href="#step-1-collect-chain-level-data" id="step-1-collect-chain-level-data"></a>

* **Vault Deposits:** Track total deposits per chain (e.g., Ethereum: 500K USDC, Arbitrum: 300K USDC)
* **Vault Yields:** Track yield generated by agents on each chain (e.g., Ethereum: 10K USDC, Arbitrum: 3K USDC)

#### Step 2: Aggregate Global Totals <a href="#step-2-aggregate-global-totals" id="step-2-aggregate-global-totals"></a>

Copy

```
totalDeposit = ethDeposit + arbDeposit  
             = 500,000 + 300,000  
             = 800,000 USDC

totalYield = ethYield + arbYield  
           = 10,000 + 3,000  
           = 13,000 USDC
```

#### Step 3: Calculate Global Exchange Rate <a href="#step-3-calculate-global-exchange-rate" id="step-3-calculate-global-exchange-rate"></a>

The exchange rate is updated globally using:

```
newExchangeRate = ((totalDeposit + totalYield) * 1e6) / totalDeposit 
                = ((800,000 + 13,000) * 1,000,000) / 800,000
                = 1,016,250 (scaled by 1e6 for USDC precision)
```

This exchange rate reflects the updated value of 1 vault share across all chains.

#### Step 4: Compute Chain-Specific Yield Distribution <a href="#step-4-compute-chain-specific-yield-distribution" id="step-4-compute-chain-specific-yield-distribution"></a>

```
vaultYield = (newExchangeRate * vaultDeposit) / 1e6 - vaultDeposit
```

For each vault:

* **Ethereum Vault:**

  ```
  ethVaultYield = (1,016,250 * 500,000) / 1,000,000 - 500,000  
                = 8,125 USDC
  ```
* **Arbitrum Vault:**

  ```
  arbVaultYield = (1,016,250 * 300,000) / 1,000,000 - 300,000  
                   = 4,875 USDC
  ```

**Total Distributed Yield:**

```
8,125 + 4,875 = 13,000 USDC (matches total global yield)
```

<table><thead><tr><th width="249">Chain</th><th>Deposits</th><th>Yield Generated</th><th>Yield Distributed</th></tr></thead><tbody><tr><td>ETH</td><td>500,000 USDC</td><td>10,000 USDC</td><td>8,125 USDC</td></tr><tr><td>Arbitrum</td><td>300,000 USDC</td><td>3,000 USDC</td><td>4,875 USDC</td></tr><tr><td><strong>Total</strong></td><td><strong>800,000 USDC</strong></td><td><strong>13,000 USDC</strong></td><td><p><strong>13,000 USDC</strong></p><h3 id="distribution-process"><br></h3></td></tr></tbody></table>

***

### Distribution Process - <a href="#distribution-process" id="distribution-process"></a>

1. **Off-chain Calculation:**
   * Our off-chain Engine collects deposit and yield data from all chains.
   * It computes the new global exchange rate and the yield to distribute to each vault.
2. **On-chain Distribution:**
   * The yield rebalancer (authorized address) calls the `distributeYield` function on each vault’s Yield contract, passing the calculated yield for that vault.
   * The vault contract updates its internal accounting and distributes the yield to users (usually with vesting).


# Technical Architecture

### Overview <a href="#overview" id="overview"></a>

The vault system is designed to abstract complex DeFi strategy execution into a simple and transparent interface for users. Through a layered architecture and clearly defined flows, users can deposit stablecoins, receive yield-bearing vault tokens, and withdraw assets, all while the system optimally manages funds across integrated protocols.

### System Architecture <a href="#system-architecture" id="system-architecture"></a>

<figure><img src="/files/YOkBZ9FJLsaynvFcK5as" alt=""><figcaption></figcaption></figure>

The vault system consists of four primary layers:

#### 1. Non-Custodial **Wallet Layer** <a href="#id-1.-smart-wallet-layer" id="id-1.-smart-wallet-layer"></a>

* **User** connects his wallet that interacts with the `afiUSD Vault` to deposit and withdraw assets.
* Deposits are converted into vault shares at the current exchange rate.

#### 2. **Core Contracts** <a href="#id-2.-core-contracts" id="id-2.-core-contracts"></a>

* **afiUSD Vault**: Central vault contract handling deposits, withdrawals, and yield accrual.
* **Yield**: Receives strategy performance updates and facilitates yield distribution over time.
* **Manager**: Executes asset allocation into supported external DeFi protocols.

#### 3. **Admin Layer** <a href="#id-3.-admin-layer" id="id-3.-admin-layer"></a>

* **Admin / Operator / Rebalancer**: Authorized roles responsible for yield updates, vault operations, rebalancing, and governance proposals.
  * **ADMIN\_ROLE**: Multi-signature governance (3/4)
  * **OPERATOR\_ROLE**: Operational functions
  * **REBALANCER\_ROLE**: Yield distribution

#### 4. **External Protocols** <a href="#id-4.-external-protocols" id="id-4.-external-protocols"></a>

* Capital is deployed across multiple integrated protocols through the `Manager`, aiming for optimal yield based on strategy logic.

***

### Flow Summary <a href="#flow-summary" id="flow-summary"></a>

#### Deposit Flow - <a href="#deposit-flow" id="deposit-flow"></a>

<figure><img src="/files/58Zl5wjx8upzOCeOYE30" alt=""><figcaption></figcaption></figure>

**Sequence Diagram**

* Users approve the vault to spend their assets.
* Vault transfers the assets to the `Manager`.
* Vault mints shares to the user based on the current exchange rate.
* Fee shares (if applicable) are minted to the `Treasury`.
* The `Manager` deploys capital across selected DeFi protocols.

**Step-by-Step:**

1. When a user joins our platform, they connect their wallet to the application.
2. Once a user approves asset spending, our backend service automatically invokes the `deposit()` function from the user's wallet. This function includes the specified amount and the receiver's address, facilitating the direct transfer of funds to the Vault.
3. Vault transfers funds to the `Manager.`
4. Vault mints shares to the user.
5. Manager deploys funds across integrated protocols.

***

#### Withdrawal Flow - <a href="#withdrawal-flow" id="withdrawal-flow"></a>

<figure><img src="/files/TVFuL4Vkqsiwj63AFOA5" alt=""><figcaption></figcaption></figure>

**Sequence Diagram**

* Users initiate a withdrawal request with their vault share amount.
* A cooldown period (e.g., 72h) is triggered.
* Once complete, the withdrawal is executed and shares are burned.
* Funds are retrieved from protocols and sent to the user.

**Step-by-Step**

1. User calls `requestWithdrawal(shares)`.
2. 72-hour cooldown period begins.
3. `Manager` retrieves funds from protocols.
4. Once cooldown ends, user executes withdrawal.
5. Vault burns user shares.
6. Assets transferred back to user.

#### Yield Distribution Flow - <a href="#yield-distribution-flow" id="yield-distribution-flow"></a>

<figure><img src="/files/AlKPdkcSVKzkZaBAQJMV" alt=""><figcaption></figcaption></figure>

**Sequence Diagram**

* The off-chain engine calculates strategy profits and pushes them on-chain.
* The `Rebalancer` role calls `distributeYield()` on the `Yield` contract.
* Vault's virtual assets are updated.
* Treasury receives a portion of the yield as fee shares.
* Exchange rate increases for all vault holders.

**Step-by-Step**

1. Off-chain system computes yield from deployed strategies.
2. Rebalancer initiates on-chain yield distribution.
3. Yield is allocated to the vault and recorded.
4. Fee shares (if configured) are minted to Treasury.
5. Exchange rate increases gradually as yield vests.

***

### Vault Mechanics <a href="#vault-mechanics" id="vault-mechanics"></a>

#### Yield Vesting - <a href="#yield-vesting" id="yield-vesting"></a>

To protect against front-running and provide a fair yield experience:

* Yield accrues linearly over a vesting period (typically 24 hours).
* This smooths out exchange rate increases and reduces volatility.
* Prevents “sniping” behavior around profit distribution events.

#### Cooldown Period (Withdrawals) - <a href="#cooldown-period-withdrawals" id="cooldown-period-withdrawals"></a>

* Designed to ensure liquidity before honoring withdrawal requests.
* The `Manager` begins to unwind deployed positions during this period.
* Helps avoid slippage or capital inefficiency during high withdrawal demand.


# Strategy Analysis

afiUSD uses a structured, multi-tier strategy framework designed to optimise yield while maintaining strict controls on principal risk. All strategies are diversified across blue-chip protocols and proven derivative markets, with continuous monitoring to minimise drawdowns and execution risk.

Importantly, **all strategies are designed to carry minimal to zero principal risk unless the underlying asset itself depegs**. A detailed risk-mitigation architecture governs position sizing, leverage caps, counterparty selection, and maturity-aligned exposure.

***

### **1. Low-Risk Strategy: Lending on Blue-Chip Protocols**

The foundation of the afiUSD strategy stack is built on **low-risk, highly liquid lending markets** such as:

* **Aave**
* **Euler**
* **Morpho Blue**

#### **Objective**

Generate stable base yield with negligible liquidation risk.

#### **Characteristics**

* No exposure to volatile collateral
* Deep liquidity and long operational history
* Continuous on-chain solvency monitoring
* Minimal execution complexity

#### **Risk Profile**

Very low. Principal risk only arises if the core stablecoin (USDC/USDe) depegs—otherwise lending positions remain structurally safe.

***

### **2. Medium-Risk Strategy: Accumulating PTs and Holding to Maturity**

This strategy involves purchasing **Pendle Principal Tokens (PTs)** at attractive discounts and holding them until maturity. We selectively choose assets with strong historical stability and robust backing, such as **USDe**, based on:

* **Fundamental analysis** (peg stability, backing, liquidity reserves)
* **Technical analysis** (volatility profile, redemption flows, maturity yield curve)

#### **Objective**

Capture fixed yield with predictable outcomes while maintaining exposure only to high-quality underlying assets.

#### **Characteristics**

* Returns are known upfront and locked through maturity
* No looping, no leverage
* No exposure to impermanent loss
* Designed to be non-liquidation-sensitive

#### **Risk Profile**

Moderate. Risk primarily stems from **underlying asset depeg** or **protocol-level failure**, both mitigated through strict selection standards.

***

### **3. High-Risk Strategy: Leveraged PT Loops via Morpho / Euler**

This category targets amplified yield by:

1. Buying PTs
2. Using them as collateral or looping them through integrated markets such as **Morpho** or **Euler PT markets**
3. Leveraging the fixed yield component to magnify returns

#### **Objective**

Maximise capital efficiency and boost fixed yield returns within controlled leverage levels.

#### **Characteristics**

* Leverage applied only within safe LTV bands
* Automated guardrails to avoid liquidation risk
* Dynamic rebalancing around maturity timelines
* Exposure diversified across durations and markets

#### **Risk Profile**

Higher relative to other strategies, but still **minimal principal risk** under normal conditions.\
Risk becomes material **only** in the event of:

* A severe underlying asset depeg
* Sudden collapse in PT liquidity
* Catastrophic protocol failure

All loops are executed with strictly monitored health factors and capped leverage to mitigate this.

***

### **4. Principal Protection Philosophy**

Across all strategy tiers, AFI follows one core invariant:

#### **“Principal risk remains minimal to zero unless the underlying stablecoin itself depegs.”**

To uphold this principle:

* Only fundamentally strong stablecoins with long-term stability signals are used
* No exposure is taken to untested or high-volatility assets
* Only blue-chip and battle-tested protocols are integrated


# How to Access POR Vaults on AFI

AFI provides access to two Proof-of-Reserve vaults: **afi-rwaUSDi** (Institutional RWA Vault) and **afiUSD** (Yield Vault backed by Pendle strategies).

\
Access to these vaults is intentionally gated to ensure user safety, compliance, and responsible capital onboarding.

***

### **afi-rwaUSDi Vault (Institutional Access Only)**

The **afi-rwaUSDi PoR Vault** is designed specifically for institutional partners, custodians, and regulated entities.\
This vault is backed by tokenized gold reserves and follows stringent compliance and operational requirements.

> **Deposits into the afi-rwaUSDi Vault are currently closed to the public.**\
> Only approved institutional entities can access this vault.

***

### **afiUSD Vault (User Access via Invite Codes)**

Access to the **afiUSD vault** is currently **invite-only**.

* **If you already have an invite code**:\
  Head over to the [**Referral page**](https://yield.afiprotocol.xyz/referral), enter your invite code, and proceed to make a deposit.
* **If you don’t have an invite code**:\
  Reach out to us on **Telegram** to request access and receive an invite code.

Once access is granted and a deposit is made, your wallet is onboarded to the afiUSD vault.


# Oracles

### afiUSD Oracle -&#x20;

The **afiUSD Oracle** exposes a **Chainlink-compatible afiUSD / USD price feed**.

It derives price from:

* afiUSD vault exchange rate (`IafiUSD.exchangeRate()` – 6 decimals)
* Chainlink USDC / USD feed

The oracle implements standard Chainlink interfaces, enabling **drop-in use wherever a Chainlink feed is expected**.

#### Interface

* `decimals()` → 8
* `latestAnswer()` → afiUSD / USD price
* `latestRoundData()` → Chainlink-style round data

#### Helpers

* `getUSDCPrice()` → USDC / USD from Chainlink
* `getCurrentExchangeRate()` → afiUSD vault exchange rate

#### Usage

```solidity
int256 price = afiOracle.latestAnswer(); // afiUSD / USD (8 decimals)
```

#### Deployment

* **Ethereum Mainnet**: [`0x32f232423829296F035E2cfcdC426911D4A1a582`](https://etherscan.io/address/0x32f232423829296f035e2cfcdc426911d4a1a582)

***

### afi-rwaUSDi Oracle -&#x20;

Stores the **afi-rwaUSDi ↔ underlying asset exchange rate**, used by the vault for share-to-asset conversions.

#### Properties

* **Precision**: 6 decimals (1e6)

#### Functions

* `fetchExchangeRate()` → read current rate
* `updateExchangeRate()` → update rate (authorized updaters)

#### Deployment

* **Ethereum Mainnet**: [`0x7Ddb808B451890cD6BDdCB06B3C80Bf355a644AE`](https://etherscan.io/address/0x7ddb808b451890cd6bddcb06b3c80bf355a644ae)
* **Base**: [`0x6a34dF39c0d66332F957ECacF84Da1FAf30165F3`](https://basescan.org/address/0x6a34df39c0d66332f957ecacf84da1faf30165f3)


# AFI Points & Referral Program

Rewards Program

AFI Points reward users for being active participants in the AFI ecosystem — whether by minting `afiUSD`, referring others, or joining through a referral.

**Season 1 is LIVE.**&#x20;

AFI is currently in **Private Beta**, and you can participate only if you have an **access code**.

#### **Access Codes**

* You can **enter AFI only through an existing access code**.
* Once you join, **you’ll receive your own access code** to share with others.
* **Deposits and afiUSD minting are available exclusively to access code holders.**

  > *Without an access code, you won’t be able to deposit or mint during the Private Beta.*

You can currently earn points through:

* **Minting afiUSD**
* **Referral Program**

Each activity has a base points payout, with additional referral points and referral boosts applied where applicable.

#### Base AFI Points <a href="#base-afi-points" id="base-afi-points"></a>

Deposit your stablecoins and mint `afiUSD` to earn base AFI Points.

* **Base Multiplier:** `1×`
* Points accrue based on the **amount of `afiUSD` minted** and the **duration** it remains active on-chain.
* These are your **core points**, independent of referrals.

#### Referral Points <a href="#referral-points" id="referral-points"></a>

Invite friends and earn **bonus points** whenever they participate.

* You earn **10% of the total base points** your referrals generate.
* These are **additional points** — your referral keeps all of their own base points.
* Referral codes are **permanent** once applied.
* The more active your referred users, the more points you accumulate over time.

#### Referral Boost <a href="#referral-boost" id="referral-boost"></a>

If you join AFI using someone’s referral code, you receive a **5% boost** on all **base points** you earn.

This bonus applies automatically and remains valid throughout the season.

#### Example <a href="#example" id="example"></a>

Let’s say:

* **User A:** earns 100 base points
* **User B:** earns 200 base points
* **User C:** earns 300 base points

Referral chain: A → B → C

#### **Points Breakdown**

| User | Base AFI Points | Referral Points     | Referral Boost      |
| ---- | --------------- | ------------------- | ------------------- |
| A    | 100             | 10% of B’s 200 = 20 | -                   |
| B    | 200             | 10% of C’s 300 = 30 | 5% of own base = 10 |
| C    | 300             | -                   | 5% of own base = 15 |

Each component — Base, Referral, and Boost — is tracked separately in the dashboard.

#### Track Your Progress <a href="#track-your-progress" id="track-your-progress"></a>

Visit the **Points & Referral Dashboard** to:

* View your **Base AFI Points**, **Referral Points**, and **Referral Boost** separately
* Monitor Season progress and be prepared for upcoming opportunities


# FAQs

Here, we've answered the most frequently asked questions about AFI

<details>

<summary><strong>What is AFI?</strong></summary>

AFI is the Financial Intelligence Ledger For RWAs. We provide fully auditable vaults, cryptographic proofs, and ERC-4626 receipt tokens to ensure that on-chain assets remain verifiably backed by real-world collateral or yield strategies.

</details>

<details>

<summary>What does Proof-Of-Reserve (POR) mean?</summary>

Proof-Of-Reserve means that for each asset tokenized and vaulted, the supply of the circulating receipt token (e.g., afi-rwaX) is always **≤** the verified locked collateral or underlying asset, as enforced on-chain via smart contracts and an independent attestation network.

</details>

<details>

<summary>What is the difference between tokenization and verifiable collateralization?</summary>

Tokenization is merely issuing a digital representation of an asset. Verifiable collateralization means that the asset backing that token is **auditable**, **on-chain locked**, and **programmatically enforced** — not just promised in a PDF.

</details>

<details>

<summary>Who is AFI built for?</summary>

AFI is built for:

* Institutional treasury teams seeking tokenized real-world assets with full transparency
* DeFi protocols needing composable, verifiably backed collateral
* Yield investors needing transparent strategies with enforceable supply constraints
* Issuers of RWAs looking for a trust-minimized distribution layer

</details>

<details>

<summary>What are POR Vaults?</summary>

POR Vaults are ERC-4626 compliant vault contracts that lock collateral (e.g., rwaX) and mint corresponding receipt tokens (e.g., afi-rwaX). The vault ensures supply cannot exceed verified backing, and reserve proofs are published via the PoR Registry.

</details>

<details>

<summary>How does the vault ensure backing remains intact?</summary>

The vault monitors three variables each epoch:

* On-chain locked tokens, Ron​
* Attested off-chain collateral, Roff​
* Circulating receipt supply S\
  \
  It enforces the invariant:

```
S ≤ α⋅min(Ron​,Roff​)
```

Where α is a safety coefficient (e.g., 0.95).

</details>

<details>

<summary>What happens if the underlying issuer mints more collateral tokens without locking them?</summary>

Because the receipt token’s mint function is governed by the vault logic, new receipt tokens cannot be minted unless additional collateral is locked and verified. This prevents unchecked minting and ensures that the invariant remains enforced.

</details>

<details>

<summary>How safe are my assets when using AFI Vaults?</summary>

Your assets are stored on-chain in audited smart contracts. All our audit reports are linked here. Collateral is locked into the ERC-4626 vault and cannot be arbitrarily transferred.&#x20;

</details>

<details>

<summary>Which wallets are supported?</summary>

Any standard Web3 wallet compatible with the blockchain network (e.g., MetaMask, Ledger, WalletConnect) can interact with AFI Vaults. Be sure to connect via the official app link: <https://app.afiprotocol.ai>

</details>

<details>

<summary>Can I use multiple chains for the same vault?</summary>

No, currently AFI is live on ETH L1.

</details>

<details>

<summary>How can I contact support?</summary>

Submit your query via <support@afiprotocol.xyz> or join our Discord community. We aim to respond within 24 business hours.

</details>

<details>

<summary>Does AFI have a dedicated mobile app?</summary>

Not currently. You can access all vault functionality via the web application in your mobile browser.

</details>

<details>

<summary>Are there fees for deposits or withdrawals?</summary>

Vaults support configurable fees at the strategy or vault level. Currently, deposit and withdrawal fees are **0%**.&#x20;

</details>


# Socials and Brand Assets

AFI Brand Kit & Official Channels

If you need assistance or have questions about **AFI**, reach out through our official channels below:

* **Website:** [https://afiprotocol.xyz](https://afiprotocol.xyz/)
* **Twitter:** <https://x.com/afiprotocol_xyz>
* **Discord:** <https://discord.gg/afiprotocol>
* **Email**: <support@afiprotocol.xyz>

For direct queries, you can contact **@Oxriskyops** on Telegram.

📁 **All official brand assets, including logos, banners, and media kits, are maintained in this**[ **Notion Site.** ](https://chainrisk-cloud.notion.site/AFI-Brand-Assets-1a481ddadd9c80a5b0e4e1a4b1a2fb65)


# Audits & Bug Bounty

Includes multiple smart contract audits conducted with Quantstamp and Cantina, along with a continuous bug bounty program to ensure ongoing security and resilience.

## Audits  <a href="#v1-contracts-12th-nov-2024" id="v1-contracts-12th-nov-2024"></a>

### POR Vault Contracts (1st December, 2025) <a href="#v1-contracts-12th-nov-2024" id="v1-contracts-12th-nov-2024"></a>

### [Quantstamp Private Audit Report ](https://certificate.quantstamp.com/full/afi-vault/dc8a68ae-e72b-4b63-bef2-544c709f6fda/index.html)

The Quantstamp private audit report on POR smart contracts highlighted 1 high and 1 medium issue, all of which were promptly addressed and subsequently verified by the auditors.

### afiUSD Contracts (1st August, 2025) <a href="#v1-contracts-12th-nov-2024" id="v1-contracts-12th-nov-2024"></a>

### [Cantina Private Audit Report ](https://cantina.xyz/portfolio/49c4ad16-2ab3-49f0-bcee-356ebf628020)

The Cantina private audit report on afiUSD smart contracts highlighted 1 critical issue along with a few medium and low-level issues, all of which were promptly addressed and subsequently verified by the auditors.

{% file src="/files/FFodqbGWYc1jNpEyojGX" %}

### afiUSD Security Review Report by Independent Researchers ( 20th August, 2025)

The audit report by independent researchers, zuhaibmohd and 0xWeb3boy on AfiUSD smart contracts highlighted a few low-level issues, all of which were promptly addressed and subsequently verified by the auditors.

{% file src="/files/08PKf1DjLyodKHrX2ckj" %}

***

## Bug Bounty & Responsible Disclosure Program

At **AFI**, we prioritize user trust and adhere to the highest privacy and security standards. To reinforce this commitment, we actively invite security researchers to identify vulnerabilities and collaborate with us in resolving them swiftly and effectively. We value the security research community and fully support responsible disclosure. Through our **Bug Bounty Program**, we reward researchers who help enhance the security and resilience of the afiUSD ecosystem.

### Responsible Disclosure Program Rules

* Include detailed, reproducible steps in your reports. Issues that cannot be reproduced will not be eligible for rewards.
* Submit one vulnerability per report unless multiple vulnerabilities need to be chained to demonstrate impact. In cases of duplicate reports, only the first reproducible submission will be rewarded.
* Vulnerabilities stemming from the same root cause will be treated as a single issue and awarded a single bounty.
* Social engineering attacks (e.g., phishing, vishing, smishing) are strictly prohibited.
* Do **NOT** exploit or test vulnerabilities on the **afiUSD mainnet contracts**. Use test/fork environments only.&#x20;
* **Only Medium- and High-severity vulnerabilities are eligible for rewards.** Low-severity or informational findings are appreciated but may not qualify for payouts.

### Reporting & Response

Researchers can report vulnerabilities by emailing our security team at [security@afiprotocol.xyz](mailto:security@afiprotocol.ai)

* **Initial Response:** within 24 hours
* **Issue Triage:** within 2-3 business days
* **Fix Timelines:** vary based on severity
* **Bounty Payments:** processed after the fix is verified.


# Risk Disclaimer

Last Updated: November 2025

Artificial Financial Intelligence (“AFI”) is a decentralized protocol that enables users to access yield strategies, liquidity management, and on-chain financial products through smart contracts. While AFI employs audited contracts, active monitoring, and robust security measures, participation in decentralized finance (DeFi) carries inherent risks.

***

#### **1. Smart Contract and Protocol Risk**

All vaults and strategies within AFI operate on smart contracts deployed on public blockchains. Although AFI has undergone multiple audits by **Cantina** and **Quantstamp**, and maintains a continuous **bug bounty program**, unforeseen vulnerabilities or exploits may still occur. Users should understand that smart contract failures could result in partial or total loss of funds.

***

#### **2. Market and Strategy Risk**

AFI strategies interact with third-party DeFi protocols (e.g., Aave, Pendle, Morpho, etc.) to generate yield. Market volatility, liquidity shortages, oracle malfunctions, or protocol-level failures may adversely affect performance or returns. Yields displayed are variable and not guaranteed.

***

#### **3. Counterparty and Integration Risk**

AFI integrates with external systems such as lending markets, liquidity providers, oracles, bridges, and other third-party infrastructure. These external dependencies operate independently of AFI and can introduce additional layers of risk. A failure, exploit, governance change, or operational issue in any integrated protocol may impact the performance, safety, or availability of AFI’s products. AFI cannot guarantee the reliability or continued operation of any third-party service.

***

#### **4.** Network, Infrastructure & Blockchain Risk

AFI depends on the stability of the underlying blockchain and its infrastructure layers. Congestion, network delays, validator failures, RPC downtime, or wallet software issues may affect transaction execution. Users may also be exposed to MEV extraction, front-running, or unexpected transaction ordering. These events may cause delays, failed transactions, or financial loss beyond AFI’s control.

***

#### **5. Regulatory and Compliance Risk**

The regulatory environment for DeFi, tokenised assets and blockchain-native financial products is rapidly evolving and may differ across jurisdictions. By using AFI you confirm that you are **solely responsible for ensuring compliance with your local laws, tax obligations, and regulatory requirements.** AFI makes no representation that any product or asset offered is legal in your jurisdiction.

***

#### **6. No Custody or Guarantees**

AFI is a **non-custodial** protocol. Users retain ownership of their assets through self-custodied wallets at all times. AFI, its contributors, or affiliated entities **do not provide insurance, guarantees, or repayment** in case of losses caused by market movements, technical failures at your end, or third-party integrations.

***

#### **7. User Responsibility**

Before using AFI, users should:

* Conduct independent due diligence and understand associated risks.
* Use secure and verified wallet interfaces.
* Avoid depositing more than they can afford to lose.

***

#### **8.** Participate Responsibly

Decentralized finance offers innovation and opportunity but also material risk. By interacting with AFI, you acknowledge that there are inherent risks involved, and you may incur losses due to factors beyond the protocol’s control. You should conduct your own research, assess your risk tolerance, and ensure you fully understand how the protocol operates before engaging with it.\
\
**AFI is committed to transparency, security, and risk management — but DeFi always involves risk. Please participate responsibly.**


# Risk Management Framework

The current strategy encompasses understanding and deciding on two things (mainly):

* **Protocol exposure**
* **Crypto Assets**

### Crypto Asset Selection

First we mainly focus on the asset selection. Deciding on the strategy and choosing the exact Pendle Token (PT) assets play a vital role in the success of the strategy. Since PT is based on an underlying crypto asset, it is necessary to understand the dynamics of the underlying asset along with the current market analysis of the PT token. Here we lay down the points for the choice. There are two aspects while deciding the PT tokens, namely a quantitative and a qualitative analysis.

### Qualitative Analysis

In this part, we deep dive into studying the qualitative aspect of the underlying tokens as well as the PT tokens. Below are the points

* Underlying token is listed by a reputable firm (Aging : 6+ Months; TVL : $50M+)
* Token has been audited by a reputable audit organization (Preferable 2+ audits)
* Token is listed in protocols and those listing is managed by good risk managers (like Gauntlet, Euler, Aave).
* If the token is yield-bearing, the underlying protocol should have a minimum of $40M+ without recursive looping. Also, look at the reserve pool (reserve pool > 0.5\*TVL).

#### Quantitative Analysis

Here we list down the quantitative analysis that we do for the underlying and PT assets.

* Underlying Token should have a TVL of $20M+ and a DeX liquidity of $10M+
* PT asset markets in protocols (Euler, Equilibria) should have a current liquidity of preferably $200K+ (assuming currently we are managing $1M). This liquidity numbers will change as our TVL increases.
* Historical analysis of the underlying assets. 95th percentile of volatility should be < 1%.
* Probability of (depegs > 0.8%) for underlying assets should be <0.1
* PT assets will be selected by looking at three attributes:
  1. Current price of PT asset
  2. APR spread of the PT assets in Euler market (while deciding on Euler pools)
  3. APR value of PT assets in Equilibria market/LP Pools (while deciding on LP Pools)
* There should be an active trigger mechanism which will alert any price drop of underlying assets of \
  \> 0.5% at any moment.

### Protocol Exposure

Another important part of strategy curation is deciding on the protocol through which our strategy will gain exposure. For a healthy and less risky strategy, it is crucial to understand the underlying dynamics and credibility of the protocols. In this section, we outline the key points that we consider when selecting a protocol and implementing a strategy involving it. Here, there are two aspects to consider, namely the qualitative and quantitative analysis of the protocol.

#### Qualitative Analysis

In this section, we delve into the qualitative aspects of the protocols in depth. Below are the points

* Underlying protocol is in the DeFi space for a significant duration of time, and has been audited by a reputable audit organization (Aging: 6+ Months; Preferably 2+ audits)
* In the case of yield-bearing protocols, regular attestations (at least once a week) or transparent debank links.
* No/minimal presence of recursive looping in case of yield-bearing protocols.
* If a yield-bearing protocol, the underlying protocol should have a minimum of $20M+ without recursive looping. Also, look at the reserve pool (reserve pool > 0.5\*TVL).
* For a yield-bearing protocol, exposure to any risky protocol that has seen any sort of insolvency scenario in the last 4 months should be avoided.

#### Quantitative Analysis

Here, we present the quantitative analysis performed for the underlying and PT assets.

* The protocol should have a TVL of $ 50M or more for the typical case, and for yield-bearing TVLs of $ 20M or more (excluding recursive looping).
* If the protocol has an underlying token, the 95th percentile of the volatility of the token in the last 4 months should be <1%.
* If a yield-bearing protocol has a yield-bearing coin in the market, then the presence of a $500K+ market cap in the Dex.


# Terms of Use

Last Updated on 29th July 2025

Welcome to **AFI**, a decentralized platform designed to automate financial strategies through non-custodial smart contracts. These **Terms of Use (“Terms”)** govern your access to and use of the AFI platform, including its website, smart contracts, services, interfaces, tokens (such as **afiusd**), and all associated features and technologies (collectively referred to as the “**Platform**” or “**AFI**”).

By accessing, browsing, interacting with, or transacting on AFI, you (“**User**,” “**you**,” or “**your**”) **acknowledge that you have read, understood, and agree to be legally bound** by these Terms in their entirety. These Terms form a binding agreement between you and AFI.

If you **do not agree** to these Terms or any part of them, you must **refrain from accessing or using** the AFI Platform in any form. Use of AFI is entirely **voluntary**, and by continuing, you represent that you meet all eligibility criteria outlined herein and are legally permitted to use decentralized finance services in your jurisdiction.

***

### 1. Overview of AFI

AFI is a **decentralized, non-custodial financial infrastructure** designed to enable users to participate in autonomous, algorithmically optimized decentralized finance (“DeFi”) strategies. Users interact with the AFI Platform by connecting their self-custodied wallets and authorizing the deployment of certain stablecoin assets (currently **USDC, USDT and AUSD**) into yield-generating protocols via smart contract automation.

Upon deposit, users receive a dynamically calculated amount of **afiusd**, a **yield-bearing vault token** that reflects the evolving performance of the underlying strategies. It is important to note that **afiusd is not a stablecoin**, but a representation of the user’s claim on the vault’s yield-bearing performance.

All processes—including wallet creation, fund deployment, afiusd minting, and strategy rebalancing—are **entirely governed by smart contracts**, without manual oversight or discretionary decision-making by any human operator. AFI does not take custody of user funds at any point, nor does it provide investment advice, guarantees, or assurances regarding any returns or capital preservation.

Use of the AFI Platform is **entirely at the user’s own risk**, and users are expected to understand the decentralized and experimental nature of smart contract-based financial technologies before participating.

***

### 2. Eligibility

By accessing or using the AFI platform, you represent and warrant that you meet **all** of the following eligibility criteria:

* You are at least **18 years old** or have reached the **age of legal majority** under the laws of your jurisdiction;
* You possess the **full legal capacity** and authority to enter into and be bound by these Terms, and to use the AFI platform without violating any applicable laws or regulations;
* You are **not a citizen, resident, or located in** any country, territory, or jurisdiction where the use of **decentralized finance (DeFi) platforms**, smart contracts, or digital asset-related services is **prohibited, restricted, or unauthorized** under local law, including but not limited to jurisdictions subject to comprehensive **sanctions, embargoes, or regulatory bans.**

It is your sole responsibility to ensure that your access to and use of AFI complies with all applicable laws, regulations, and restrictions in your location. AFI does **not monitor or control user locations** and **disclaims all liability** for any unauthorized or unlawful use of the platform.

AFI reserves the right to restrict or revoke access to its services for any user who fails to meet these eligibility criteria or who, in AFI’s sole discretion, poses a legal, regulatory, or reputational risk to the platform.

***

### 3. Use of the Platform

#### **3.1 Wallet Connection and Smart Wallet Deployment**

To access the AFI Protocol, you are required to connect a supported non-custodial wallet (such as MetaMask) to the AFI interface ("User Interface"). Upon successful connection, the platform will automatically deploy a dedicated ERC-4337-compatible **smart wallet** that is uniquely associated with your external wallet address ("Smart Wallet").

This Smart Wallet serves as your personal programmable agent on-chain and is utilized to:

* Receive, manage, and hold deposits made by you;
* Interact with AFI’s algorithmic strategies and other smart contracts;
* Hold afiUSD, the protocol’s yield-bearing token representing your position in the AFI Vaults and strategies.

#### **3.2 Smart Wallet Permissions and User Authorizations**

By using the platform and connecting your wallet, you expressly authorize AFI’s interface and smart contract infrastructure to:

* Initiate the deployment of your personal Smart Wallet;
* Request and manage permissioned access to a defined portion of your funds for the purpose of executing yield strategies;
* Enable the Smart Wallet to operate autonomously in accordance with on-chain logic, including the ability to deposit, withdraw, rebalance, or interact with third-party protocols strictly within the scope of AFI’s strategy modules.

You retain full control of your externally owned account (EOA), and all interactions between your EOA and the Smart Wallet require your active approval or pre-consented delegation.

#### **3.3 Non-Custodial Framework and Limitation of Responsibility**

You acknowledge and agree that:

* AFI does not have custody of your assets at any point;
* AFI does not possess your private keys, seed phrases, or credentials;
* The Smart Wallet operates entirely based on autonomous smart contract logic, and AFI cannot access, alter, or override its operations.

You are solely responsible for the security of your connected wallet and Smart Wallet. AFI disclaims all liability for any loss of access, loss of funds due to user error, third-party vulnerabilities, or incorrect authorizations initiated from your end.

***

### 4. Yield and Performance

AFI offers access to automated, algorithmic DeFi strategies designed to seek yield by deploying user-deposited stablecoins (currently USDC) across integrated third-party protocols. However, **AFI makes no representation, warranty, or promise** regarding the actual yield generated or the overall performance of any strategy.

The **afiusd token**, received in exchange for stablecoin deposits, is a **yield-bearing vault token** whose value fluctuates based on:

* The success or failure of yield-generating strategies;
* On-chain market volatility;
* The security, uptime, and liquidity of third-party DeFi protocols used (e.g., Pendle, Euler Finance).

Users must understand that:

* The **value of afiusd may increase or decrease**;
* There is **no guarantee of positive returns, profit, or preservation of principal;**
* Yield, if any, is variable and subject to real-time market conditions and smart contract execution risks.

Before interacting with the AFI platform, users are strongly advised to **assess their own risk tolerance**, conduct independent due diligence, and consider seeking advice from qualified financial or legal professionals.

AFI disclaims all liability for any direct, indirect, or consequential loss resulting from performance outcomes or market volatility affecting afiusd or the underlying strategies.

***

### 5. Third-Party Protocol Disclaimer

AFI’s platform interacts with a range of external decentralized finance (DeFi) protocols, including but not limited to **Pendle, Euler Finance,** and other third-party smart contract systems. These integrations are implemented through autonomous, non-custodial smart contracts that deploy user funds in accordance with algorithmic strategies.

#### Users acknowledge and agree that:

* These third-party protocols are **entirely independent** and are **not owned, operated, maintained, or directly controlled by AFI** or any of its affiliates, contributors, or developers;
* AFI provides **no warranties or guarantees** regarding the **security, functionality, accuracy, or uptime** of any third-party platform or smart contract;
* AFI’s integration with such protocols **does not imply any endorsement, partnership, vetting, or certification** of their practices, security standards, or regulatory status;
* Each third-party platform may be subject to its own risks, including but not limited to:
  * Smart contract vulnerabilities
  * Protocol-level failures
  * Exploits, hacks, or liquidity shortfalls
  * Governance changes or deprecation

**By using AFI, users assume full responsibility** for any consequences resulting from their interaction with these third-party protocols. This includes the risk of partial or total loss of deposited assets, failure of afiusd to retain value, or inability to redeem funds due to protocol-side issues.

AFI disclaims all liability for any damage, loss, or disruption resulting from the use of or reliance on any external platform or service integrated with the AFI ecosystem.

***

### 6. Smart Contract and Automation Risks

AFI is a fully autonomous and non-custodial platform that operates exclusively through smart contracts and algorithmic agents. All transactions, fund deployments, and yield strategies are executed programmatically without any human intervention or manual oversight.

By using the AFI platform, **you acknowledge and accept the following risks**:

* **Autonomous Execution**: Once you deposit assets (such as USDC), those funds are routed through AFI’s smart contracts and deployed across third-party DeFi protocols automatically. No individual or team member of AFI can manually intervene, pause, or reverse these operations.
* **Inherent Smart Contract Risks**: Smart contracts are experimental technologies and may contain:
  * Undiscovered bugs or vulnerabilities
  * Logic or execution errors
  * Compatibility issues with integrated DeFi protocols
* **Security Limitations**: Despite internal testing and audits (if applicable), **no smart contract can be guaranteed to be entirely free of risk**. Exploits, flash loan attacks, and zero-day vulnerabilities in AFI or any connected protocol could result in the permanent loss of funds.
* **No Recovery Mechanism**: AFI does **not maintain any control over user funds** once they are deposited into smart contracts. In the event of a system failure, hack, or loss through a third-party protocol, **AFI cannot retrieve, reimburse, or insure** lost assets.

By using the platform, you accept these risks in full and agree that you are solely responsible for any financial exposure or losses incurred. Users are advised to carefully assess their risk tolerance and consult with independent financial, legal, or technical advisors before interacting with the AFI platform.

***

### 7. Regulatory Compliance

AFI is a decentralized, autonomous protocol that operates globally without centralized control or jurisdictional restrictions. **AFI does not provide legal, tax, or regulatory advice,** and makes no representations regarding the legality of its services in any specific jurisdiction.

By accessing and using AFI, you expressly acknowledge and agree that:

* **Personal Legal Responsibility**: You are solely and entirely responsible for determining whether your access to and use of the AFI platform is legal and compliant with all applicable laws, regulations, rules, and administrative guidance in your country, region, or jurisdiction.
* **No Guarantees or Warranties**: AFI does not assess, ensure, or warrant the regulatory status, licensing, or compliance of any third-party DeFi protocol integrated within its ecosystem. Participation in the AFI platform is at your own discretion and risk.
* **Tax Compliance**: You are solely responsible for reporting and paying any taxes associated with your activity on the platform, including but not limited to income, capital gains, or transaction-based taxes as required by your local authorities.
* **Restricted Jurisdictions**: You agree not to use AFI if you are located in, incorporated in, or a citizen or resident of any jurisdiction where the use of decentralized finance (DeFi) platforms, smart contracts, or similar technologies is restricted, regulated, or prohibited by applicable law.

By continuing to interact with AFI, you confirm that you have conducted your own legal due diligence and accept full liability for any consequences resulting from non-compliant or unlawful use of the platform.

***

### 8. No Investment Advice

All content, features, and tools made available on the AFI platform are provided for **informational and technical purposes only. Nothing presented by AFI—whether through its interface, documentation, dashboards, analytics, or smart contracts—should be interpreted as:**

* Investment advice
* Financial planning guidance
* A recommendation to buy, sell, or hold any digital asset
* An offer or solicitation to participate in any investment product or service

AFI does not act as a broker, dealer, investment advisor, or fiduciary under any jurisdiction’s laws. Users are **solely responsible** for evaluating their individual financial situation, risk appetite, and investment goals.

We strongly recommend that users seek advice from **independent financial, legal, and tax professionals** before making decisions related to digital asset participation, DeFi strategies, or use of yield-generating protocols.

**Your use of the AFI platform is entirely at your own discretion and risk.** AFI disclaims any liability for decisions made or outcomes experienced by users based on information obtained through the platform.

***

### 9. Indemnity

To the fullest extent permitted by applicable law, you agree to **indemnify, defend, and hold harmless** AFI, including its developers, ecosystem contributors, affiliates, partners, and service providers (collectively, “AFI Parties”) from and against any and all **claims, actions, demands, liabilities, damages, losses, costs, or expenses**, including but not limited to reasonable legal and accounting fees, arising out of or relating to:

* **Your use or misuse of the AFI platform**, smart contracts, website, or any associated tools and services
* **Any violation or alleged violation of these Terms** by you or anyone using your wallet or smart wallet on the AFI platform
* **Your breach of any applicable laws, regulations, or third-party rights**, including those governing digital assets, securities, financial services, or data privacy
* **Your interaction with third-party DeFi protocols**, platforms, or smart contracts integrated within AFI, including but not limited to any financial or data loss arising from such protocols

AFI reserves the right, at its sole discretion and at your expense, to assume the exclusive defense and control of any matter subject to indemnification by you. In such cases, you agree to cooperate fully with AFI in asserting any available defenses.

This indemnity obligation will survive the termination or expiration of your use of the AFI platform.

***

### 10. Limitation of Liability

To the maximum extent permitted under applicable law, you expressly agree that:

* **AFI and its affiliates, developers, contributors, and partners (collectively, the “AFI Parties”) shall not be liable for any indirect, incidental, special, exemplary, punitive, or consequential damages**, including but not limited to loss of funds, lost profits, lost data, loss of business opportunities, or reputational harm
* This limitation applies whether the claim arises from **contract, tort, negligence, strict liability, or any other legal theory,** and regardless of whether AFI was advised of, or could have foreseen, the possibility of such damages
* Specifically, **AFI shall not be liable for any damages arising from:**
  * Failure, vulnerability, or exploit of any smart contract on or integrated with the platform
  * Operational risks associated with third-party DeFi protocols
  * User errors, including loss of private keys or incorrect wallet interactions
  * Temporary or permanent inaccessibility of the AFI platform
  * Regulatory actions or legal prohibitions that affect your ability to use the platform or access your assets

In jurisdictions where the exclusion or limitation of liability for consequential or incidental damages is not allowed, AFI’s total aggregate liability to you for any and all claims shall be limited to **no more than the amount you have directly deposited through the platform in the 30 days preceding the event giving rise to the claim.**

***

### 11. Changes to the Terms

AFI reserves the right to modify, amend, or update these Terms of Use at any time, at its sole discretion. Any such changes will be effective immediately upon being published on the AFI website or user interface, unless stated otherwise.

* **By continuing to access or use the AFI platform after such changes are made, you agree to be bound by the updated Terms.**
* AFI is under no obligation to provide you with individual notice of changes. It is your sole responsibility to **review these Terms periodically** to ensure that you understand and agree to the latest version.
* If you do not agree with the updated Terms, your only recourse is to **discontinue use of the AFI platform** and associated services.

These Terms represent a legally binding agreement between you and AFI. Continued use constitutes reaffirmation of your acceptance.

***

### 12. Termination

AFI reserves the right, at its sole discretion, to suspend, restrict, or terminate your access to the platform and its services at any time, with or without prior notice, under any of the following circumstances:

* **Suspected violation of these Terms of Use**
* **Engagement in unlawful, fraudulent, or abusive activities**
* **Actions that may compromise the security, integrity, or functionality of the AFI platform or any third-party protocol integrated within it**
* **Compliance with legal, regulatory, or enforcement requests or obligations**

Upon termination:

* Your access to the AFI smart wallet, afiusd tokens, and associated services may be disabled
* AFI shall not be liable for any resulting loss of access, data, or funds, especially if tied to smart contract operations beyond AFI’s control
* Your obligations under these Terms—including indemnity, disclaimers, and limitations of liability—will survive termination

Termination is without prejudice to any other rights or remedies available to AFI under applicable law.

***

### 13. Governing Law and Jurisdiction

These Terms shall be governed by, and construed in accordance with, the laws of **Nevis**, without regard to its conflict of law provisions.

You agree that any disputes, controversies, or claims arising out of or in connection with your use of the AFI platform, these Terms, or any related matter shall be subject to the **exclusive jurisdiction of the courts of Nevis**.

You hereby waive any objection to the venue or jurisdiction of such courts, including objections based on forum non conveniens or lack of personal jurisdiction.

***

### 14. Contact Information

If you have any questions, concerns, or feedback regarding these Terms or the AFI platform, please reach out to us through the following channels:

📧 **Email**: [support@afiprotocol.xyz](mailto:support@afiprotocol.ai)\
🌐 **Website**: [https://afiprotocol.xyz ](https://afiprotocol.xyz/)

We welcome responsible disclosure of any security concerns or vulnerabilities related to AFI's smart contracts or platform.


# Privacy Policy

Last Updated on 29th July 2025

### 1. Introduction

AFI is a decentralized, non-custodial protocol that powers cross-chain, risk-aware decentralized finance (DeFi) strategies through autonomous, algorithmic agents. As a decentralized system operating on smart contracts, AFI does not itself collect, process, or retain personal data from its users. Users interact directly with on-chain infrastructure and maintain full control over their wallets and data.

However, certain AFI-affiliated platforms, frontend interfaces, technology partners, or third-party service providers (collectively, “Affiliated Entities”) may require the collection and processing of personal data to deliver services, comply with applicable laws (such as KYC/AML obligations), or enhance user functionality. These affiliated platforms operate in jurisdictions that may impose obligations under data protection regulations, including but not limited to:

* **The General Data Protection Regulation (GDPR)** — for users in the European Economic Area (EEA) (globally recognised);
* **Other applicable national or regional data protection laws** — depending on the user’s location.

This Privacy Policy describes how personal data is collected, used, shared, and protected by or on behalf of AFI-affiliated entities and platforms. It applies to all individuals accessing or interacting with AFI through regulated or user-facing services where personal data is involved.

Please read this Policy carefully to understand your rights and how your data is handled.

***

### 2. Scope and Applicability

This Privacy Policy governs the collection, use, disclosure, and protection of personal data processed through AFI-affiliated platforms and services, to the extent that such processing occurs in connection with user interaction, regulatory compliance, or operational functionality.

Specifically, this Policy applies to:

* **Users Accessing AFI via Affiliated Frontends**: Individuals who engage with AFI through third-party interfaces (including web and mobile applications) that provide access to AFI’s decentralized financial products and tools.
* **Users Undergoing KYC/AML Procedures**: Individuals required to complete Know Your Customer (KYC), Anti-Money Laundering (AML), or other identity verification processes through integrated third-party compliance service providers. These procedures may be mandated by law or by AFI-affiliated platforms offering fiat on/off ramps, token offerings, or regulated financial services.
* **Institutional Counterparties and Partners**: Legal entities, such as liquidity providers, decentralized autonomous organizations (DAOs), node operators, or infrastructure partners, that interact with AFI infrastructure or enter into legal agreements with AFI-affiliated service providers.
* **Visitors and Users of Informational Tools**: Individuals who browse or interact with analytics dashboards, documentation sites, smart wallet interfaces, or other publicly accessible tools offered by AFI-affiliated platforms, even if they do not directly engage in DeFi transactions.

This Policy does not apply to on-chain interactions that do not involve personal data, nor to services or platforms that are not officially affiliated with AFI or its authorized partners. In decentralized environments, the ultimate responsibility for wallet security, transaction confidentiality, and pseudonymous activity remains with the user.

***

### 3. Data Controller and Data Processor Roles

Due to the decentralized and non-custodial nature of the AFI protocol, the collection and processing of personal data is not conducted by the protocol itself, but rather by affiliated frontend platforms and third-party service providers. The distinction between Data Controllers and Data Processors, as defined under the General Data Protection Regulation (GDPR), is outlined below:

* **AFI Protocol**: AFI is a decentralized software infrastructure deployed on public blockchains. It does not collect, store, or manage any personal data and, therefore, does not act as a “Data Controller” or “Data Processor” under GDPR. AFI operates solely as a permissionless coordination layer for risk-aware, cross-chain DeFi strategies.
* **Frontend Operators and Affiliated Platforms**: Independent or partnered platforms that provide user-facing access to the AFI protocol (via web or mobile applications) may collect personal information in connection with user onboarding, compliance requirements, or service customization. Depending on their implementation and contractual roles, such operators may act as:
  * **Data Controllers**, where they determine the purpose and means of personal data processing; or
  * **Data Processors**, where they process data solely on behalf of another controller, such as a regulated financial institution.
* **Third-Party KYC/AML Providers**: Vendors such as Sumsub, Veriff, or Jumio may be integrated into affiliated frontends to carry out identity verification and compliance screening. These providers process personal data under contractual instructions from the frontend operator and do not interface directly with the AFI protocol. In such cases, the **frontend operator remains the Data Controller,** and the **KYC/AML provider acts as a Data Processor.**
* **Data Controller Contact Information**: The specific identity and contact details of the applicable Data Controller for your personal data will be made available in the Terms of Use and Privacy Policy of the frontend platform or service you are interacting with.

Users are encouraged to review the privacy documentation of the frontend they use to understand how their data is handled and by whom.

***

### 4. Types of Data Collected

AFI itself, as a decentralized protocol, does not collect any personal information. However, certain personal data may be collected by AFI-affiliated frontends, partners, or integrated third-party service providers in accordance with applicable legal, technical, or operational requirements. The type and extent of data collected depend on your interaction with the platform and the services accessed. These data categories include:

#### A. Identity Verification Data

Collected when a user undergoes Know Your Customer (KYC), Anti-Money Laundering (AML), or identity verification procedures, typically conducted by a third-party provider:

* Full legal name
* Date of birth
* Country of nationality and tax residency
* Government-issued identification documents (e.g., passport, driver's license, national ID)
* Real-time selfie or biometric data (used for liveness or facial recognition checks)
* Social Security Number (SSN), Tax Identification Number (TIN), or other local equivalents, as required by law

This information is required to comply with regulatory obligations and prevent fraud, money laundering, or sanctions evasion.

#### B. Contact Information

Collected when a user registers an account, interacts with customer support, or subscribes to communications:

* Email address
* Mobile phone number (where required for two-factor authentication or alerts)
* Residential or mailing address (as required for regulatory disclosures or identity validation)

#### C. Technical and Wallet Data

Collected automatically through your interaction with frontend interfaces or smart wallet tools:

* Public blockchain wallet addresses
* Device identifiers, including browser type and operating system
* IP address and geolocation data (inferred from IP or device settings)
* Session metadata, including login timestamps, interface navigation, and page interaction logs
* Cookies and similar tracking technologies (as disclosed in the Cookie Policy of the respective frontend)

This data helps improve security, detect suspicious behavior, and optimize the user interface.

#### D. Financial and Transactional Data

Collected when users interact with fiat on/off ramps, participate in token offerings, or utilize AFI Vaults or DeFi strategies:

* Fiat or crypto transaction history (e.g., deposits, withdrawals, swaps)
* On-chain activity including yield participation, wallet-to-wallet transfers, and governance interactions
* Declarations or records of source of funds or wealth (as part of Enhanced Due Diligence where required)

This data may be used for compliance screening, auditing, and risk assessment in line with global financial regulations.

***

### 5. Legal Bases for Processing Personal Data (Under GDPR Article 6)

AFI-affiliated frontends and service providers process personal data only when there is a valid legal basis to do so, as outlined under Article 6 of the General Data Protection Regulation (GDPR). Depending on the context and purpose of interaction, one or more of the following legal bases may apply:

#### A. Consent – Article 6(1)(a)

Users may be asked to provide explicit and informed consent for certain types of data collection and processing. This includes:

* Submitting personal data for Know Your Customer (KYC) verification
* Receiving marketing communications or product updates
* Participating in optional platform features, such as rewards programs or community governance

Users retain the right to withdraw consent at any time without affecting the lawfulness of processing based on consent before its withdrawal.

#### B. Contractual Necessity – Article 6(1)(b)

Processing may be necessary for the performance of a contractual relationship, or to take steps at a user's request prior to entering into such a contract. Examples include:

* Enabling user access to regulated offerings or gated features of the protocol
* Facilitating token purchases, fiat on-ramp/off-ramp services, or smart account activations
* Providing essential customer support or technical assistance

Failure to provide the required data in such cases may prevent users from accessing certain services or fulfilling their intended transactions.

#### C. Legal Obligation – Article 6(1)(c)

Certain personal data must be collected and retained in order to fulfill statutory or regulatory obligations, particularly in relation to:

* Anti-money laundering (AML) and counter-terrorism financing (CTF) compliance
* Sanctions screening and monitoring as per OFAC, UN, or EU lists
* Tax reporting requirements, including FATCA, CRS, or similar frameworks

Data collected under this basis may be disclosed to competent legal or regulatory authorities as required by applicable law.

#### D. Legitimate Interests – Article 6(1)(f)

In some cases, processing is necessary to serve the legitimate interests of AFI-affiliated entities or the broader user base, provided such interests are not overridden by the fundamental rights or freedoms of users. This includes:

* Security monitoring, threat detection, and fraud prevention
* Risk scoring for on-chain behavior, transaction volume, or access from high-risk jurisdictions
* Platform optimization based on aggregated usage patterns and technical diagnostics
* Ensuring protocol integrity and minimizing exposure to malicious actors

Where legitimate interests form the basis for processing, users may object to such processing, subject to applicable legal limits.

***

### 6. Use of Personal Data

AFI-affiliated frontends, partners, and third-party service providers may use personal data collected from users strictly for lawful and predefined purposes. These purposes are consistent with applicable data protection regulations, including the General Data Protection Regulation (GDPR), and aim to ensure platform integrity, user protection, and regulatory compliance. Personal data may be used for the following specific purposes:

#### A. Conducting KYC/AML and Identity Verification Checks

To verify user identity, prevent impersonation, and meet anti-money laundering (AML) and counter-terrorism financing (CTF) regulations. This includes:

* Authenticating documents and biometric data
* Cross-checking against global sanctions, politically exposed persons (PEP), and watchlists
* Assessing user risk profile for access to regulated services

#### B. Facilitating Fiat On/Off-Ramp Transactions

To process and validate fiat-to-crypto or crypto-to-fiat conversions via integrated financial partners. Personal data may be used to:

* Confirm account ownership
* Enable transaction authorization
* Satisfy banking partner compliance checks

#### C. Preventing Fraud, Abuse, and Financial Crime

To detect suspicious activity, prevent fraud, and maintain ecosystem trust. Data may be processed for:

* Device fingerprinting and IP address tracking
* Monitoring of high-risk behavior or unusual transaction patterns
* Implementing security alerts or enforcement actions

#### D. Complying with Legal or Regulatory Obligations

To fulfill obligations under financial, tax, or data protection laws. This includes:

* Retaining user data for statutory periods
* Responding to valid requests from regulators, tax authorities, or courts
* Generating compliance reports and audit trails

#### E. Managing Participation in Token Offerings, Rewards, and Governance

To enable qualified users to:

* Participate in token sales, airdrops, or loyalty programs
* Receive rewards, yield distributions, or governance tokens
* Cast votes or submit proposals in on-chain or off-chain governance processes

#### F. Communicating with Users and Resolving Disputes

To ensure seamless user support and platform transparency. This includes:

* Responding to inquiries or support tickets
* Sending service-related notices, such as terms updates or security alerts
* Addressing user complaints, appeals, or correction requests

***

### 7. Data Sharing and Disclosure

AFI-affiliated platforms and service providers recognize the importance of protecting personal data and only share such information when necessary, and always in accordance with applicable laws including the GDPR, CCPA, and other relevant frameworks. Data sharing is limited to well-defined circumstances, and all parties involved are bound by confidentiality, security, and lawful processing obligations.

Personal data may be shared with the following categories of recipients:

#### A. Third-Party KYC/AML and Identity Verification Providers

To carry out regulatory compliance procedures, your data may be shared with specialized service providers such as Sumsub, Veriff, or equivalent vendors. These providers:

* Operate under strict data processing agreements
* Are only authorized to use your data for identity verification and compliance checks
* Must adhere to applicable privacy regulations, including GDPR Article 28 (Data Processor obligations)

#### B. Cloud, Hosting, and Analytics Providers

To maintain platform performance, monitor system health, and improve user experience, certain technical and behavioral data may be shared with:

* Hosting providers (e.g., AWS, Cloudflare)
* Analytics platforms (e.g., Plausible, Matomo – privacy-respecting alternatives to Google Analytics)

All such providers are contractually obligated to implement industry-standard data protection and security controls.

#### C. Regulatory or Legal Authorities

AFI-affiliated entities may disclose personal data if required to:

* Comply with binding legal obligations
* Respond to lawful subpoenas, court orders, or regulatory enforcement requests
* Satisfy tax, anti-money laundering, or financial reporting requirements

Such disclosures will be limited to the minimum data necessary to fulfill the legal request.

#### D. Protocol Partners and Affiliate Frontend Operators

If you interact with the AFI protocol through a partner frontend or wallet interface, certain data may be shared between AFI-affiliated entities and the frontend operator to:

* Enable or manage access to gated features
* Facilitate communications or customer support
* Enforce compliance or usage terms

All partner entities are required to provide transparent data handling policies and obtain user consent where applicable.

**No Sale of Personal Data**

AFI and its ecosystem participants do not sell, rent, or trade user personal data to any third parties. Data is only processed and shared as necessary for protocol operation, user support, and regulatory compliance.

***

### 8. International Data Transfers

AFI-affiliated platforms and service providers may engage vendors, partners, or data processors located outside the European Economic Area (EEA), including but not limited to jurisdictions such as the United States, Singapore, and other regions where data protection laws may differ from those in the EU. As part of our commitment to user privacy and regulatory compliance, all such international transfers of personal data are carried out in full accordance with the General Data Protection Regulation (GDPR), particularly Chapter V on data transfers.

To ensure that your data remains protected regardless of where it is processed, AFI or its affiliated frontend operators implement one or more of the following safeguards:

#### A. EU Standard Contractual Clauses (SCCs)

Where data is transferred to countries that have not been recognized by the European Commission as providing an adequate level of data protection, we utilize Standard Contractual Clauses as approved by the European Commission. These legally binding agreements obligate non-EEA recipients to provide equivalent protections to those guaranteed under EU law.

#### B. Adequacy Decisions

When transferring personal data to countries that the European Commission has deemed to offer an adequate level of protection (e.g., countries like Japan or the United Kingdom), data transfers are permitted without the need for additional safeguards.

#### C. Binding Corporate Rules (BCRs) or Equivalent Mechanisms

In some cases, personal data may be transferred within corporate groups or infrastructure providers operating under Binding Corporate Rules. These are internal policies approved by EU data protection authorities that ensure consistent, GDPR-level data protection across all global operations.

**User Rights in the Context of International Transfers**

Regardless of where your data is processed, you maintain all rights provided under GDPR, including the right to access, correct, delete, or object to the processing of your personal data. You may also request a copy of the applicable data transfer safeguards by contacting the relevant data controller as specified in the frontend's legal documentation.

***

### 9. Data Retention

AFI-affiliated platforms and their third-party service providers retain personal data only for as long as is necessary to fulfill the specific purposes for which it was collected, as described in this Privacy Policy. This includes compliance with applicable legal, regulatory, accounting, and reporting obligations, as well as dispute resolution, fraud prevention, and security monitoring.

Retention periods may vary depending on the type of data and the legal or operational context. Generally, the following retention standards apply:

#### A. KYC and AML Records

To comply with anti-money laundering (AML) and counter-terrorist financing (CTF) regulations—such as the U.S. Bank Secrecy Act (BSA), the EU AMLD framework, and FATF guidelines—personal data collected during Know Your Customer (KYC) procedures is retained for a minimum of five (5) years from the date of:

* Completion of the verification process, or
* The end of the user relationship or last user interaction, whichever is later.

#### B. General User Account Data

Personal data related to general usage, platform preferences, and non-KYC-related information is retained:

* Until the user deletes their account or requests data erasure, subject to applicable legal constraints, or
* After a defined period of inactivity, typically not exceeding 24 months, after which data may be anonymized or deleted.

#### C. Regulatory Compliance and Dispute Resolution

Certain data may be retained:

* As required by law, including tax reporting (e.g., FATCA/CRS), sanctions compliance, or transaction audits.
* For fraud detection or abuse mitigation, where records may be maintained even after account closure if a legitimate risk is identified.

#### D. Anonymization and Aggregation

Where data is no longer needed for a legal or business purpose, it may be anonymized and retained in an aggregated format for analytics, protocol performance, and risk modeling—without retaining any personally identifiable information.

**Data Minimization Principle**

In line with GDPR Article 5(1)(e), AFI and its partners ensure that personal data is not retained for longer than necessary. All retention timelines are periodically reviewed to ensure compliance with evolving legal requirements and best industry practices.

***

### 10. Your Rights (Under GDPR)

If you are located in the European Economic Area (EEA) or are otherwise subject to the General Data Protection Regulation (GDPR), you are entitled to a range of rights in relation to your personal data. These rights aim to give you greater transparency and control over how your data is used by AFI-affiliated platforms and third-party service providers.

Subject to applicable laws and certain limitations, your rights include:

#### A. Right of Access

You have the right to request confirmation of whether personal data concerning you is being processed, and to access a copy of such data, including the purposes of processing, categories of data, recipients, and data retention periods.

#### B. Right to Rectification

If any of your personal data is inaccurate or incomplete, you may request that it be corrected or supplemented.

#### C. Right to Erasure ("Right to be Forgotten")

You may request the deletion of your personal data where:

* The data is no longer necessary for the purpose for which it was collected,
* You have withdrawn consent (where consent was the legal basis),
* You have objected to processing and there are no overriding legitimate grounds,
* Processing was unlawful, or
* Deletion is required to comply with a legal obligation.

**Note**: This right may be limited where data must be retained to comply with legal or regulatory obligations (e.g., KYC retention under AML laws).

#### D. Right to Restriction of Processing

You can request the temporary suspension of processing where:

* You contest the accuracy of your data,
* Processing is unlawful but you oppose deletion,
* Data is no longer needed but required for legal claims, or
* You have objected and verification of legitimate grounds is pending.

#### E. Right to Data Portability

You may request a copy of your personal data in a structured, commonly used, and machine-readable format, and have the right to transmit that data to another controller where processing is based on consent or contract and carried out by automated means.

#### F. Right to Object

You can object at any time to:

* Processing based on legitimate interests (including profiling),
* Direct marketing (if applicable), which will result in immediate cessation.

#### G. Right to Withdraw Consent

Where processing is based on your consent (e.g., optional KYC, marketing communications), you have the right to withdraw consent at any time without affecting the lawfulness of prior processing.

**How to Exercise Your Rights**

You may exercise these rights by submitting a request:

* Via the frontend interface (where user tools are available), or
* Through the KYC provider’s or data controller’s designated support channels.

For your protection, you may be asked to verify your identity before a request can be processed. Responses to valid requests will typically be provided within 30 days unless otherwise permitted under applicable law.

***

### 11. Cookies and Analytics

Certain AFI-affiliated frontends and web interfaces may use cookies and similar tracking technologies to enhance user experience, ensure platform functionality, and analyze usage patterns. These tools help the frontend operators understand how users interact with their services and improve performance accordingly.

#### A. Types of Cookies and Tools Used

The following categories of cookies and analytics tools may be implemented:

* **Essential Cookies**: Required for the basic operation of the site (e.g., wallet connection, session management, security verification). These cannot be disabled through cookie settings.
* **Performance and Analytics Cookies**: Used to gather data on site usage, traffic sources, and performance metrics (e.g., Google Analytics). This helps frontend operators improve the usability and efficiency of the interface.
* **Preference Cookies**: Used to remember user settings or preferences, such as selected language or wallet connection state.
* **Marketing or Tracking Cookies (if applicable)**: Only used where marketing tools are integrated. These track behavior across sites and are disabled by default unless the user opts in.

#### B. User Consent and Control

In compliance with GDPR and other privacy regulations:

* Users will be presented with a cookie consent banner or modal when accessing AFI-affiliated websites for the first time.
* Non-essential cookies (e.g., analytics or marketing) will only be activated if the user provides explicit consent.
* Users may manage or revoke their cookie preferences at any time via the frontend’s privacy or cookie settings page.

#### C. Third-Party Services

Some analytics and cookie tools may be operated by third-party providers (e.g., Google, Plausible, Cloudflare). These providers may collect data according to their own privacy policies and are subject to contractual obligations for data protection.

***

### 12. Data Security

AFI and its affiliated platforms prioritize the protection of personal data by implementing robust technical and organizational safeguards, in line with industry best practices and regulatory expectations.

#### A. Security Measures

All personal data processed by or on behalf of AFI-affiliated services is:

* **Encrypted in Transit and at Rest**: Utilizing modern encryption protocols (e.g., TLS, AES-256) to protect data from interception or unauthorized access.
* **Stored in Access-Controlled Environments**: Hosted on infrastructure with strict access controls, authentication mechanisms, and role-based permissions to prevent unauthorized access or misuse.
* **Processed by Certified Vendors**: Service providers involved in data processing are required to adhere to recognized security standards, such as:
  * SOC 2 (System and Organization Controls)
  * ISO/IEC 27001 (Information Security Management Systems)
  * Other equivalent international certifications

#### B. Decentralized Protocol Assurance

As a decentralized protocol, AFI itself does not store, access, or process personal data, including user credentials or wallet keys. All sensitive data handling is delegated to third-party service providers or frontend operators under strict contractual obligations and data privacy requirements.

#### C. Incident Response

In the unlikely event of a data breach involving affiliated services, users will be notified in accordance with applicable data protection laws, and remediation measures will be promptly initiated.

***

### 13. Changes to This Policy

AFI-affiliated platforms reserve the right to update or modify this Privacy Policy at any time, in order to reflect:

* Changes in regulatory or legal requirements
* Updates to AFI’s protocol architecture, features, or services
* Shifts in data processing practices by third-party providers

#### A. Notification of Changes

When material changes are made, users will be informed through one or more of the following methods:

* A prominent notice on the relevant frontend or dashboard
* Email notification (if the user has provided a valid email address)
* In-app or website banners indicating the update

#### B. Review and Acceptance

Continued use of AFI-affiliated services after such changes are published will constitute acknowledgment and acceptance of the updated policy. Users are encouraged to periodically review this Privacy Policy to stay informed about how their personal data is handled.

#### C. Version History

The effective date and last updated date will always be listed at the top of this document for transparency and auditability.

***

### 14. Contact

For data protection-related inquiries, rights requests, or complaints, please contact the Data Protection Officer (DPO) of the affiliated frontend operator at:

📧 **Email**: [support@afiprotocol.xyz](mailto:support@afiprotocol.ai)


# Third Party Disclaimer

Last Updated on 29th July 2025

AFI is a decentralized, non-custodial protocol that powers autonomous financial markets through algorithmic agents executing risk-aware DeFi strategies 24/7. By using AFI, you acknowledge and agree to the following:

***

### 1. Use of Third-Party Protocols

AFI utilizes user-deposited funds currently in the form of stablecoins such as USDC by programmatically deploying them into various decentralized finance (DeFi) protocols, including but not limited to Pendle, Euler Finance, and similar platforms. This deployment is carried out through autonomous smart contracts governed by AFI’s proprietary algorithmic logic, which operates 24/7 without manual intervention.

It is important to understand that these external DeFi protocols are wholly independent entities. AFI does not own, operate, manage, or control any of these third-party platforms. The interaction with such protocols is purely functional, and their inclusion within the AFI ecosystem is based on technical compatibility and strategic yield optimization, not on any form of legal or commercial partnership, endorsement, or affiliation.

Accordingly, AFI disclaims any liability for the performance, conduct, security practices, or regulatory compliance of these third-party platforms. Users should exercise caution and conduct their own due diligence regarding the risks associated with interacting even indirectly with these external protocols, as any loss or issue originating from them falls outside AFI’s control.

***

### 2. Smart Wallet and Vault Token Architecture

When a user connects their external wallet (such as MetaMask or another Web3-compatible wallet) to the AFI platform, they initiate the creation of a personalized smart wallet, a non-custodial contract-based wallet unique to their account. This smart wallet serves as a secure, autonomous interface between the user’s funds and the broader decentralized finance ecosystem.

Upon depositing stablecoins (currently limited to USDC) into their smart wallet, users implicitly grant permission for those assets to be deployed into AFI’s automated, yield-generating strategies. These strategies are executed by algorithmic agents that dynamically allocate funds across a curated set of third-party DeFi protocols.

In return for their deposit, users receive a calculated amount of afiusd, a proprietary vault token issued directly to their smart wallet. Unlike stablecoins, afiusd is not pegged to the US dollar; instead, it is a yield-bearing asset whose value fluctuates over time based on the performance of the underlying strategies and the cumulative yield generated from those deployments.

The exchange rate between afiusd and the base stablecoin (e.g., USDC) adjusts algorithmically. As strategies generate yield and reinvest earnings, the value of afiusd increases, enabling users to redeem it later for more than their original deposit — assuming strategies perform favorably. Thus, afiusd acts as a tokenized representation of a share in a performance-linked yield vault, not as a fixed-value currency.

This system allows users to benefit from continuous, compounding yield without manual intervention while maintaining full ownership and control over their smart wallet.

***

### 3. Smart Contract Risks and Automation

AFI operates through a network of autonomous smart contracts that handle the full lifecycle of fund deployment, management, and yield generation. Once a user deposits assets (such as USDC) into their smart wallet, those funds are automatically routed across various third-party DeFi protocols according to predefined algorithmic strategies — without any manual oversight or intervention by the AFI team.

While this automation enhances efficiency, scalability, and neutrality, it also introduces inherent smart contract-related risks. All logic, including fund allocation, strategy selection, and token minting/redemption, is executed strictly by code. As such, AFI’s platform is entirely dependent on the functionality and integrity of both its own contracts and those it interacts with externally.

Importantly, AFI does not audit, maintain, or guarantee the operational soundness of any external smart contracts — such as those belonging to Pendle, Euler Finance, or other integrated DeFi platforms. If any of these protocols suffer from vulnerabilities like code exploits, logic bugs, oracle manipulation, or liquidity failures, the resulting impact — including partial or total loss of user funds — is beyond AFI’s ability to prevent, recover, or insure against.

Users are therefore advised to understand the non-custodial and autonomous nature of DeFi and acknowledge that participation in such environments entails a high level of technological and financial risk. Engaging with AFI implies acceptance of these risks, as well as the possibility of adverse outcomes due to the decentralized infrastructure it leverages.

***

### 4. No Liability for Third-Party Losses

AFI assumes no responsibility for any direct or indirect losses resulting from the performance or failure of third-party services, including but not limited to:

* Impermanent loss, liquidation, or smart contract risk
* Protocol shutdowns or regulatory actions
* Loss of value due to adverse market conditions or afiusd exchange rate fluctuations

Users may also later choose to deploy **afiusd** into additional protocols for compounding yield, at their own discretion and risk.

***

### 5. No Guarantees of Return

AFI provides access to algorithmically managed DeFi strategies through its yield-bearing vault token, afiusd. However, users must understand that the performance and value appreciation of afiusd are not guaranteed. These returns are entirely contingent upon the behavior and yield outcomes of third-party decentralized finance protocols to which user funds are allocated. While AFI’s autonomous agents aim to optimize capital deployment for maximum yield potential, there is no assurance of profit, principal preservation, or favorable price movement of afiusd. Users may receive less than their original deposit upon redemption, particularly in scenarios of market volatility or third-party protocol underperformance.

***

### 6. Regulatory Status

AFI functions as a decentralized interface to autonomous financial strategies, interacting with various DeFi protocols that may or may not be regulated in specific jurisdictions. AFI does not conduct any legal or regulatory vetting of third-party protocols, nor does it provide legal advice regarding the permissibility of DeFi participation under local laws. It is the sole responsibility of users to ensure that their use of AFI’s platform and engagement with afiusd tokens comply with the laws, regulations, and financial rules applicable in their jurisdiction, including those governing securities, derivatives, and stablecoin usage.

***

### 7. Indemnity

By accessing or using the AFI platform and its related services, you agree to indemnify, defend, and hold harmless AFI, its developers, smart contract contributors, ecosystem participants, affiliates, and any related parties from and against any and all claims, damages, liabilities, losses, or legal expenses arising from your use of afiusd, interaction with third-party protocols, or any consequences resulting from the automated deployment of your assets. This includes, without limitation, losses due to protocol failures, regulatory actions, smart contract exploits, or user error. Your engagement with AFI implies full understanding and acceptance of these conditions.

***

**By using AFI, you confirm that you understand the risks of deploying digital assets into decentralized finance protocols and acknowledge that AFI bears no responsibility for third-party services or outcomes.**


# Digital Asset Custody Framework

Last Updated on 29th July 2025

### **1. Introduction**

**AFI (Artificial Financial Intelligence)** is a decentralized, non-custodial protocol purpose-built for coordinating cross-chain, risk-aware decentralized finance (DeFi) strategies through algorithmic agents. AFI introduces a new paradigm for autonomous asset management, removing the need for centralized intermediaries by leveraging smart contract automation, programmable logic, and user-governed infrastructure.

Importantly, AFI is non-custodial by desig&#x6E;**.** The protocol **does not take possession of, control, or manage user funds** at any point. Instead, all interactions occur through **self-custodied wallets** and **ERC-4337-compatible smart accounts**, allowing users or institutions to retain complete control over their private keys and digital assets. Vault interactions, strategy orchestration, and yield optimization are executed via **audited, deterministic smart contracts**, with no centralized admin keys controlling user funds.

This Custody Framework Note provides an overview of the principles, architecture, operational safeguards, and technical assurances that collectively define AFI’s approach to digital asset custody. While AFI does not function as a traditional custodian, the protocol incorporates best-in-class practices to promote **institutional-grade security, operational transparency, and resilient asset management** in line with global regulatory and cybersecurity expectations.

This document is intended for:

* Institutional participants evaluating AFI’s custody posture.
* Security professionals assessing AFI's non-custodial infrastructure.
* Legal or compliance teams analyzing responsibilities under applicable custodial regulations.
* Developers or integrators building on top of AFI vaults and agent layers.

The rest of this note details the key architectural layers that govern asset access and control, including:

* Smart contract-based vault architecture
* Role-based permissions and agent coordination
* Multi-chain interoperability and cross-chain asset routing
* Yield computation and distribution governance
* Administrative oversight through multisig and DAO controls

By design, AFI aims to align user sovereignty with secure automation, offering the benefits of advanced DeFi strategies without compromising custody principles.

***

### **2. Custody Model Overview**

AFI adheres to a **non-custodial architecture**, grounded in trust-minimized infrastructure and smart contract automation. The protocol’s design is based on the principle that **users should always retain full control over their digital assets**, without the need for custodial intermediaries. This model eliminates counterparty risk traditionally associated with centralized asset managers or custodians.

AFI’s custody architecture is built on the following foundational principles:

* **User Sovereignty**

AFI is committed to upholding user sovereignty as a core tenet. All users interact with the protocol through **wallets they own and control**, and **AFI never takes possession of private keys, seed phrases, or recovery credentials.** Users authorize interactions via cryptographic signatures, and smart contracts enforce rules transparently without requiring trust in human operators or centralized entities.

* **Self-Custody via Smart Wallets**

The protocol supports ERC-4337-compatible smart accounts, enabling advanced account abstraction features while preserving user control. These smart wallets allow for:

&#x20;\- Granular permissions

&#x20;\- Recovery mechanisms governed by the user

&#x20;\- Delegated execution by trusted agents (with revocation rights)

This ensures that even complex DeFi strategies can be executed programmatically **without relinquishing custody to third parties.**

* **Programmable Control through On-Chain Agents**

AFI’s strategy execution layer operates via algorithmic agents and programmable smart contracts. These agents interact with user-deposited funds held in **ERC-4626-compliant vaults**, under strict access control logic. Actions such as rebalancing, yield harvesting, or risk mitigation are **triggered by permissioned logic,** verified and enforced directly on-chain. At no point can agents override the withdrawal rights of users or redirect assets without explicit logic-based authorization.

* **No Intermediary Custody or Recovery Access**

Neither AFI nor any of its developers, DAO participants, or affiliated interfaces **has the ability to access, seize, or recover user funds.** All custody is enforced by deterministic smart contracts and externally owned or smart accounts. This ensures elimination of single points of failure, removal of trust-based custodianship, and full alignment with the principles of decentralized finance.

***

### **3. Key Components**

The AFI protocol employs a modular, secure, and auditable custody infrastructure made up of **three primary components**: **Vaults**, **Smart Wallet Interfaces**, and **Manager & Admin Modules**. Together, these components form the foundation of AFI’s non-custodial model, allowing for seamless execution of cross-chain strategies while preserving user control and system integrity.

#### **A. AFI Vaults (ERC-4626-Compliant)**

At the core of the AFI custody infrastructure are **ERC-4626 tokenized vault contracts**. These vaults are designed to be fully permissionless, enabling any user or agent to deposit supported digital assets under transparent and predictable rules.

**Key features of AFI Vaults include:**

* **Standards-Compliant Infrastructure:** All vaults adhere to the ERC-4626 standard, ensuring interoperability with wallets, interfaces, and other DeFi protocols.
* **Immutable Logic (Unless Governed):** Vault contracts are non-upgradeable by default, meaning their core logic cannot be altered once deployed. However, **governance-authorized upgrades** may be permitted through time-locked, transparent proposals passed by the AFI DAO or approved via multisig to adapt to evolving security or operational requirements.
* **Automated Yield Handling:** Vaults automatically accrue yield from underlying strategies, with returns subject to linear vesting, withdrawal cooldowns, or fee mechanisms as defined in the smart contract. This ensures predictable behavior and protection against manipulation or abrupt liquidity drain.

#### **B. Smart Wallet Interfaces**

Users engage with the AFI protocol using **smart account-based wallets**, which combine traditional user control with advanced programmability. These wallets support:

* **Signature Abstraction:** Leveraging ERC-4337, users can authorize actions via gasless transactions, batch execution, or alternative signature schemes.
* **Session Delegation:** Users may temporarily delegate specific permissions (e.g., yield claims, rebalancing) to on-chain agents or automation tools, without transferring asset custody or compromising wallet security.
* **Access Control & Recovery Options:** Wallets may integrate optional role-based controls, social recovery, or multi-factor authentication, offering flexibility without undermining decentralization.
* **Compatibility Across Platforms:** These smart wallets are accessible via browser extensions, mobile apps, and hardware wallets, offering institutional and retail users alike a secure and customizable interface for DeFi engagement.

#### **C. Manager & Admin Modules**

AFI’s infrastructure separates operational execution from administrative governance, enforcing security through strict **Role-Based Access Control (RBAC)** and multi-signature protections.

* **Multisig Governance:** Critical parameters and upgrades are controlled through multi-signature wallets, often held by trusted governance participants, ecosystem contributors, or decentralized autonomous organization (DAO) representatives.
* **Configurable Roles:** Different smart contracts (vaults, yield logic, agents) implement granular roles, such as strategy executor, fee manager, or emergency pauser, allowing for efficient but controlled system administration.
* **Operational Flexibility:** While day-to-day vault operation is permissionless, privileged functions such as emergency halts, logic upgrades, or fund migrations (if any) are gated by on-chain or multisig-based checks, ensuring no single point of failure or abuse.

***

### **4. Security and Risk Mitigation**

AFI is built on the principle of **resilient decentralization**, minimizing custodial exposure and systemic risks while adhering to best practices in protocol security. This section outlines the **layered defenses and mitigation mechanisms** embedded within the AFI custody framework to protect user funds, system integrity, and protocol continuity.

**A. Smart Contract Audits**

All core smart contracts within the AFI ecosystem are subject to thorough **third-party audits** by independent, industry-recognized blockchain security firms. These audits evaluate the logic, access control, edge cases, gas optimization, and attack surfaces of AFI's vaults, agents, and supporting modules.

**Key elements include:**

* **Pre-Deployment Audits:** No contract is deployed to mainnet without undergoing at least one full-scope audit.
* **Post-Deployment Bounties:** A bug bounty program is maintained to incentivize the white-hat community to discover vulnerabilities in live contracts, with rewards scaled by severity and impact.
* **Formal Verification (Optional):** For mission-critical components such as vaults and yield logic, formal methods may be used to mathematically prove safety and correctness against specific invariants.

#### **B. Multisig Access Control**

While AFI is non-custodial, certain administrative and emergency operations, such as adjusting yield parameters, toggling cooldowns, or pausing contracts in response to detected threats, are controlled through multi-signature authorization mechanisms.

**Key security features:**

* **Decentralized Signer Structure:** Multisig wallets are composed of geographically distributed, institutionally vetted signers to prevent single-point failures and reduce collusion risk.
* **Threshold Authorization:** Sensitive actions require approval from a predefined quorum (e.g., 3 of 5 or 4 of 7 signers), ensuring collaborative decision-making and transparency.
* **Time-Locked Operations:** Governance or admin-level changes may be subject to timelocks, giving the community advance notice of any upcoming modifications.

#### **C. Risk Segmentation**

AFI mitigates systemic risks by isolating smart contracts and separating asset exposures across multiple dimensions:

* **Vault Isolation:** Each vault operates independently with its own asset pool, strategy logic, and configuration. A failure in one vault does not impact others, protecting the broader system from contagion.
* **Stratified Yield Exposure:** Users can choose between vaults offering different **risk-return profiles**, such as conservative strategies with real-world yield integrations vs. experimental DeFi farming, allowing for informed risk management.
* **Withdrawal Cooldowns & Rate Limiting:** To deter exploits or flash-liquidity events, withdrawals from AFI vaults are governed by cooldown timers, rate caps, and algorithmically enforced **vesting mechanisms.**
* **Oracle & Agent Redundancy:** Yield calculations and asset pricing rely on **multi-source oracles** and redundant agent networks, ensuring resistance to manipulation, downtime, or single-source failures.

***

### **5. Asset Recovery and Incident Response**

AFI’s **non-custodial design** ensures that users maintain full control over their digital assets at all times. Consequently, AFI does **not** possess the ability to access, retrieve, or reset private keys, and cannot facilitate recovery of lost or stolen funds resulting from compromised user wallets. **Self-custody** is a core principle of the protocol, and users bear the sole responsibility for securing their wallets, seed phrases, and private credentials.

However, AFI incorporates **structured incident response protocols** and **fail-safe mechanisms** to address threats at the protocol level, particularly when smart contract vulnerabilities, attack vectors, or front-end exploits are detected.

#### **A. User Asset Recovery Limitations**

* **No Centralized Key Custody:** AFI does not store or manage private keys, wallet seed phrases, or access credentials. If a user loses access to their wallet, the protocol cannot restore control or reverse transactions.
* **Wallet Compatibility:** Users are encouraged to use secure, audited wallets (e.g., hardware wallets or smart accounts with social recovery features) that support backup and recovery functions at the wallet level.
* **Best Practice Education:** Educational resources and UX warnings are provided through the AFI frontend to guide users on safe wallet usage and backup procedures.

#### **B. Protocol-Level Incident Response**

Although user-level asset recovery is not possible, AFI has developed a **multi-stakeholder incident response framework** to ensure swift mitigation and transparency in case of protocol-level threats or vulnerabilities.

**Key components include:**

* **Cross-Team Coordination:** Incident response is coordinated across core developers, frontend interface operators, third-party security researchers, and smart contract auditors. A communication bridge is maintained with white-hat communities to support rapid disclosure and resolution.
* **Emergency Multisig Controls:** AFI's administrative architecture includes emergency pause functions, governed by a distributed multisig. If a threat is confirmed, affected smart contracts can be paused temporarily to prevent further damage while mitigation strategies are developed and deployed.
* **Postmortem & Disclosure:** After any significant incident, the AFI team will publish a detailed post-incident report, outlining:
  * The nature and scope of the issue
  * Actions taken to mitigate harm
  * Contract upgrades or patches
  * Preventive measures going forward
* **Timelocked Resumption:** Contracts paused during incidents may only be resumed after a defined review and governance process, ensuring accountability and avoiding rushed redeployments.

AFI’s approach to incident response balances **decentralization**, **transparency**, and **operational security**. While the protocol cannot intervene in individual wallet compromises, it takes every measure to protect shared infrastructure and provide users with early warnings, coordinated defenses, and full disclosure when required.

***

### **6. Institutional Custody Integration**

While AFI operates on a **non-custodial architecture**, the protocol has been consciously designed to accommodate the needs of **institutional participants** who require compliant, auditable, and policy-enforced asset management solutions. Institutions such as asset managers, DAO treasuries, crypto funds, and fintech platforms often operate under regulatory frameworks that demand **robust custody controls**, **segregation of duties**, and **multi-layer authorization**.

AFI’s **modular and composable infrastructure** supports this by enabling seamless integration with external institutional custody solutions and programmable access control layers, without compromising the **trustless**, **decentralized ethos** of the protocol.

#### **A. Qualified Custodian Integration**

Institutional users can connect their AFI interactions to regulated custodians via APIs and middleware platforms. This includes integration with:

* **BitGo**
* **Anchorage Digital**
* **Fireblocks**
* **Copper**
* **Other SOC 2 / ISO 27001-certified custody providers**

These custodians provide secure off-chain private key management, cold/hot wallet segregation, automated transaction monitoring, and regulatory-grade compliance features. Through these integrations, institutions can interact with AFI vaults and agents without ever taking custody of private keys internally.

#### **B. On-Chain Agent Wrappers**

AFI supports the use of custom on-chain wrappers that allow institutional custodians or internal compliance teams to manage interactions with the protocol in a **controlled** manner. These wrappers may implement:

* **Role-based permissions** (e.g., maker/checker models)
* **Activity logging and compliance reporting**
* **Whitelisted asset interactions** based on internal investment mandates
* **Audit trails** for governance and fiduciary oversight

Such wrappers can be deployed as smart contracts governed by institutional policies and serve as middleware between user funds (custodied off-chain) and AFI’s on-chain vault strategies.

#### **C. Transaction Approval Layers**

Institutions can configure **multi-party transaction flows** using AFI-compatible smart wallets (e.g., Gnosis Safe, ERC-4337 smart accounts) that enforce:

* **Co-signing requirements** from compliance officers or portfolio managers
* **Pre-trade checks** aligned with AML or risk limits
* **Custom execution policies** such as transaction batching, cooldown timers, or rate limits

These smart wallets act as **programmable gateways** for interacting with AFI, ensuring that institutional governance structures are respected and fully auditable.

By supporting **institutional-grade custody integrations** without introducing centralized custody into the protocol itself, AFI strikes a unique balance between decentralization and enterprise adoption. This flexibility allows institutions to benefit from AFI’s cross-chain yield infrastructure while maintaining full control over their risk, compliance, and governance requirements.

***

### **7. Regulatory Alignment**

AFI has been intentionally designed as a **decentralized, non-custodial infrastructure**, which places it outside the scope of **Virtual Asset Service Provider (VASP)** classification under the majority of global regulatory frameworks, such as those defined by the **Financial Action Task Force (FATF)**, **MiCA (EU)**, or **FinCEN (U.S.)**. Since the AFI protocol does not directly custody user funds, manage private keys, or intermediate transactions between users, it does not fulfill the functional criteria typically required for licensing as a custodian or exchange.

However, AFI recognizes the importance of **regulatory clarity and alignment**, particularly for its institutional users, developer ecosystem, and affiliated frontends or integrations. To ensure compatibility with jurisdictional compliance frameworks and to foster responsible growth, **AFI-affiliated entities** may engage in the following regulatory coordination practices:

#### **A. Custodial Partner Coordination**

While AFI itself is non-custodial, third-party platforms built on or integrating with AFI may partner with licensed custodians and fiat on/off-ramp providers. These custodians may provide:

* Secure key management for institutional and retail users
* Fiat gateways for onboarding or redeeming digital assets
* Regulated stablecoin issuance or custody services

Such integrations enable **compliant user flows**, particularly where fiat onboarding, regulated token offerings, or asset-backed stablecoins are involved.

#### **B. Compliance Infrastructure for Institutions**

To meet the needs of regulated entities and enterprises, **AFI-affiliated interfaces** and agent frameworks may offer **optional compliance modules**, such as:

* **KYC/AML onboarding** powered by third-party verification providers
* **Transaction screening and monitoring**, including sanctions checks and address risk scoring
* **Wallet whitelisting and blacklisting**, in line with internal or jurisdictional controls

These tools ensure that institutions interacting with AFI infrastructure can maintain compliance with their internal risk frameworks or with laws applicable in their operating jurisdictions.

#### **C. Legal Wrappers and Structured Interfaces**

To interface with financial institutions or satisfy operational licensing needs, **AFI-affiliated projects** may deploy legal entities or wrappers such as:

* **Decentralized Autonomous Companies (DACs)** or DAOs structured under compliant jurisdictions (e.g., Wyoming, Marshall Islands, Switzerland)
* **Foundation or trust structures** that support governance, protocol funding, or operational oversight
* **SPVs or licensed partners** for executing token issuances, service agreements, or other regulated activities

These structures allow **AFI-aligned teams** to interact with the off-chain world while preserving the **decentralized, trust-minimized design** of the underlying protocol.

By remaining **outside the regulatory perimeter** while enabling **compliant interaction layers**, AFI ensures it can scale across borders and user types, from anonymous DeFi users to fully regulated institutions, **without compromising its decentralized ethos.**

***

### **8. Conclusion**

The **AFI Custody Framework** represents a **paradigm shift** in how digital assets can be coordinated, managed, and secured in a decentralized financial ecosystem. By design, AFI upholds the principles of **self-custody**, **transparency**, and **protocol-level neutrality**, ensuring that **users, not intermediaries**, retain full control over their assets at all times.

**AFI does not assume custody or possession** of any user funds. Instead, it facilitates **secure**, **verifiable**, and **programmable financial strategies** through smart contracts, agent-driven automation, and modular interfaces. This non-custodial model **eliminates traditional points of failure** while providing the flexibility to accommodate a diverse range of use cases, from retail self-service to institutional integration.

As the protocol and its ecosystem mature, the **AFI custody architecture** is expected to evolve in line with real-world requirements. Future enhancements may include:

* Modular integration with licensed custodians for hybrid use cases
* Real-time audit frameworks to strengthen institutional trust
* Advanced compliance layers for region-specific onboarding
* Cross-chain custody harmonization to support multi-chain strategies

Despite these developments, **AFI will remain fundamentally non-custodial at the protocol layer**, preserving its commitment to decentralization and trustless financial coordination.

This framework aims to serve as a foundation for secure participation in the AFI ecosystem, whether by individual users, institutional actors, or developers building on top of the protocol.


# Anti-Money Laundering (AML) Policy

Last Updated on 29th July 2025

### **1. Purpose**

This **Anti-Money Laundering (AML) Policy** outlines AFI’s commitment to upholding the highest standards in combating **money laundering**, **terrorism financing**, **sanctions evasion**, and other forms of financial crime. The policy is designed to voluntarily ensure compliance with the European Union’s **Fifth Anti-Money Laundering Directive (AMLD5)**, along with applicable international regulatory frameworks and industry best practices.

AFI operates as a **decentralized, non-custodial financial protocol** that leverages algorithmic agents and smart contracts for cross-chain (Swarm Intelligence), risk-optimized asset deployment. Despite the platform’s non-custodial architecture and absence of direct control over user assets, AFI recognizes its responsibility to implement effective controls that minimize the risk of illicit financial activity occurring via its infrastructure.

This AML Policy serves the following core purposes:

* **Promoting a risk-based culture of compliance** that aligns with decentralized finance (DeFi) principles and technological innovations
* **Establishing internal guidelines and monitoring procedures** for ecosystem participants who interact with the AFI protocol, including interface providers, developers, and integrators
* **Demonstrating AFI’s proactive stance** in supporting lawful use of decentralized technologies and maintaining transparency and trust within the ecosystem

AFI is committed to continuously evolving its AML practices to reflect changes in global regulations, threat landscapes, and decentralized technology risks, while maintaining a balance between user privacy, permissionless access, and regulatory integrity.

***

### **2. Scope**

This AML Policy applies to all operational layers, technical interfaces, and user interactions within the AFI ecosystem that may involve or present exposure to money laundering or terrorist financing risks. While AFI is a decentralized, non-custodial protocol and does not take possession of user funds, it acknowledges that certain components of the platform—particularly those involving **user access**, **smart contract execution**, and **value transfer**—may be targeted or exploited for illicit activity.

This Policy governs and informs AML risk mitigation efforts in connection with the following:

* **User Onboarding via Front-End Gateways:**\
  Any web-based or application-based interface that facilitates user access to AFI’s decentralized infrastructure, including integrations by third-party interface providers, must implement appropriate risk-based controls, including user screening and identity verification where applicable.
* **Smart Wallet Creation and Usage:**\
  The automatic creation of ERC-4337-compatible smart wallets for users entails the possibility of repeated, pseudonymous wallet interactions. Although no custodial services are provided, the platform recognizes the importance of transaction pattern monitoring and behavioral analytics to detect anomalous or suspicious activity.
* **Deployment of Crypto Assets into Yield Strategies:**\
  Funds deposited into AFI vaults may be deployed across third-party DeFi protocols. The AML implications of routing user assets to external smart contracts are considered within the risk framework, and protocols integrated by AFI’s autonomous agents are subject to periodic due diligence.
* **Minting and Redemption of the afiusd Vault Token:**\
  The minting and burning of afiusd tokens, which represent claims to the yield generated from user-deployed stablecoins, can involve complex, cross-chain, or privacy-enhancing transaction flows. These token lifecycle events are monitored to prevent abuse, layering, or value obfuscation associated with money laundering techniques.

This Policy applies to all contributors, developers, validators, third-party integrators, and governance participants who support the AFI protocol in a manner that could impact financial integrity or regulatory exposure. It also outlines shared expectations for front-end operators and partners interacting with end users.

***

### **3. Legal Framework**

This **Anti-Money Laundering Policy** has been developed in accordance with the European Union’s **Fifth Anti-Money Laundering Directive (AMLD5)**, which came into effect in January 2020. AMLD5 extends AML compliance obligations to a broader range of entities, including **virtual asset service providers (VASPs)**, decentralized platforms, and wallet service providers, where applicable.

AFI, while operating as a **decentralized and non-custodial protocol**, aligns its compliance framework with the core principles of **AMLD5** and global **Financial Action Task Force (FATF)** standards to the extent technically and operationally feasible. This includes the implementation or facilitation of the following key requirements:

* **Customer Due Diligence (CDD) and Enhanced Due Diligence (EDD):**\
  AFI expects front-end operators or interface providers interacting with users to implement robust identity verification measures, including **Know Your Customer (KYC)** procedures. In higher-risk cases, such as users from high-risk jurisdictions or using privacy-enhancing technologies, EDD protocols must be applied to gather additional information and perform deeper risk assessment.
* **Suspicious Transaction Monitoring and Reporting:**\
  While AFI cannot directly monitor users due to its decentralized nature, the protocol encourages interface providers and analytics-integrated components to monitor wallet behavior for suspicious transaction patterns (e.g., rapid fund cycling, use of mixers, sudden high-volume interactions). Where applicable, suspicious activity should be escalated and reported to the relevant **Financial Intelligence Unit (FIU).**
* **Recordkeeping Obligations:**\
  In compliance with AMLD5, relevant user data collected during CDD/EDD procedures must be retained securely for a minimum of **five (5) years**. This includes identity documentation, transaction logs, and audit trails. Where AFI integrates with custodial or regulated gateways, those entities are expected to fulfill these data retention responsibilities.
* **Cooperation with Financial Intelligence Units (FIUs):**\
  AFI and its ecosystem partners commit to cooperating with law enforcement and competent FIUs upon lawful request, including facilitating access to relevant transaction data or user records, where such data exists or is held by regulated partners.

This legal framework ensures that AFI’s AML strategy is not only technically mindful of its decentralized architecture but also aligned with emerging European and global standards for **decentralized finance (DeFi) compliance**.

***

### **4. AML Risk Approach**

In alignment with the requirements of AMLD5 and FATF guidelines, AFI adopts a **Risk-Based Approach (RBA)** to Anti-Money Laundering (AML) compliance. This means that AFI assesses and addresses the likelihood and impact of potential money laundering or terrorist financing (ML/TF) risks based on the nature of user interactions, transaction behavior, and technical environment.

While operating as a decentralized, non-custodial protocol, AFI applies this RBA through **modular compliance features** integrated into its ecosystem interfaces, smart wallet architecture, and analytics layers. This allows risk to be assessed without compromising decentralization principles.

#### **1. High-Risk Indicators**

AFI and its ecosystem partners flag or scrutinize activities that exhibit one or more of the following **high-risk characteristics**:

* **Anonymized Transactions:** Use of privacy-enhancing technologies (e.g., Tornado Cash, Monero bridges) that obscure fund origin or destination.
* **Large, Unusual Deposits:** Sudden or disproportionate deposits into vaults or yield strategies without historical precedent.
* **Interactions with Mixers or Obfuscation Protocols:** Engagement with services designed to hide fund provenance.
* **Cross-Border Transfers from High-Risk Jurisdictions:** Interactions originating from or directed to jurisdictions identified by the EU or FATF as non-cooperative or high-risk.
* **Rapid In/Out Transactions:** Patterns indicating potential layering or structuring behavior.

Such activities may trigger **enhanced review or restrictions** where interface providers or on-chain compliance tools are used.

#### **2. Low-Risk Indicators**

Conversely, the following are considered **low-risk indicators**:

* **Transparent, Verifiable On-Chain Activity:** Clear transaction history with identifiable wallet behavior traceable across DeFi platforms.
* **Known Source of Funds:** Deposits from regulated platforms or wallets with a consistent and explainable asset trail.
* **Stable Usage Patterns:** Gradual and consistent use of AFI vaults and smart accounts for yield purposes over time.

Where low-risk factors dominate, the AML burden on users may be proportionally lower, consistent with AMLD5’s **proportionality principle**.

#### **3. Adaptive Risk Monitoring**

Although AFI does not operate as a centralized custodian or financial institution, the protocol encourages integration with **on-chain compliance tools** (e.g., Chainalysis, TRM Labs) to dynamically assess wallet risk scores, transactional metadata, and jurisdictional exposure. These tools support ecosystem partners in aligning with AMLD5 requirements while preserving **user privacy and decentralization**.

***

### **5. Customer Due Diligence (CDD)**

AFI recognizes the importance of **Customer Due Diligence (CDD)** as a core component of AML compliance under the EU's **Fifth Anti-Money Laundering Directive (AMLD5)**. While the AFI protocol itself is decentralized, non-custodial, and does not directly hold or control user funds, CDD obligations may arise when AFI interfaces with users through regulated third-party platforms or fiat on/off ramp providers.

#### **KYC Obligations**

Where AFI or affiliated third-party frontends enable user interactions that involve regulated financial activities, such as fiat conversion, account-linked services, or interaction with regulated entities, **Know Your Customer (KYC)** procedures must be implemented. These are carried out via compliant third-party KYC vendors, such as **Sumsub**, **Veriff**, or equivalent, who adhere to **GDPR** and **AMLD5** standards.

KYC verification is mandatory under the following conditions:

* Use of fiat deposit or withdrawal rails
* Redemption of afiusd vault tokens to off-chain assets
* Onboarding from jurisdictions with AML enforcement mandates
* Any legal requirement under the jurisdiction of the frontend operator

#### **Minimum Information Required**

To comply with AMLD5 and ensure identity verification, the following minimum user data points are collected during KYC:

* **Full legal name**
* **Date of birth**
* **Nationality**
* **Residential address**
* **Government-issued photo identification** (e.g., passport, national ID, driver’s license)

In some cases, **additional supporting documents** (such as proof of address or source of funds) may be required for verification or audit purposes.

#### **Enhanced Due Diligence (EDD) Triggers**

AFI or its frontend partners will apply **Enhanced Due Diligence (EDD)** when certain higher-risk scenarios are detected. These include, but are not limited to:

* Users from high-risk jurisdictions, as identified by the EU or FATF (e.g., countries on the grey or blacklist)
* Large-volume redemptions of afiusd tokens that may indicate abnormal behavior or require deeper scrutiny of fund origin
* Identified **Politically Exposed Persons (PEPs)** or their associates, who may pose elevated corruption or reputational risks

EDD measures may include additional document verification, ongoing monitoring, approval escalations, or outright service restrictions.

#### **Protocol Nature and Limitations**

It is important to note that **AFI’s core smart contract protocol operates in a non-custodial and permissionless manner**, meaning:

* It does not collect or store personal data
* It does not hold user funds or custody assets
* It does not exercise control over third-party frontend decisions

Where user access is facilitated via interfaces that operate under regulatory oversight, those service providers are responsible for implementing and enforcing appropriate CDD/EDD mechanisms. AFI supports the development of **privacy-preserving KYC solutions** that allow compliant access without undermining decentralization principles.

***

### **6. Transaction Monitoring**

As part of its commitment to mitigating financial crime risks in accordance with AMLD5, **AFI implements robust on-chain transaction monitoring protocols**, in collaboration with industry-leading blockchain analytics providers. While the AFI protocol is non-custodial and decentralized, transaction monitoring is performed at the interface level (e.g., via frontends or partners) to ensure regulatory alignment where applicable.

#### **Use of Analytics Tools**

AFI and/or its third-party interface operators will leverage specialized **blockchain intelligence tools** to monitor user behavior across the ecosystem. These tools include, but are not limited to:

* **Chainalysis**
* **TRM Labs**
* **Elliptic** (where applicable)

These systems provide **real-time insights** into wallet activity, historical behavior, and risk categorization of on-chain addresses.

#### **Real-Time Risk Alerts**

The monitoring tools are configured to trigger alerts for transactions or behaviors that exhibit **red flags** commonly associated with money laundering, terrorist financing, or illicit activity. Key alert categories include:

* Interactions with **sanctioned addresses** as identified by international sanction lists (e.g., **OFAC**, **EU**, **UN**)
* Patterns of **layering or structuring**, such as rapid movement of funds across multiple wallets to obscure origin
* Frequent interaction with **privacy-enhancing tools** (e.g., Tornado Cash, mixers) or **darknet-related addresses**
* Sudden **large-value transactions** inconsistent with historical usage patterns

Alerts may be escalated for human review or automatically logged for further investigation, depending on the severity of the risk.

#### **Response to Suspicious Activity**

If suspicious activity is detected through monitoring systems, the following actions may be taken:

* **Flagging** of the user’s wallet address in internal risk databases
* **Temporary or permanent frontend access restrictions**, especially where the frontend operates under a regulatory license or has KYC/AML obligations
* **Generation of a Suspicious Activity Report (SAR)** by the frontend operator or responsible party, in accordance with local **Financial Intelligence Unit (FIU)** obligations

AFI does not have access to user identities on the protocol level, but it supports responsible frontend partners in meeting their legal duties by ensuring compatibility with **industry-standard monitoring solutions**.

#### **Privacy and Transparency**

AFI is committed to upholding **user privacy** while ensuring regulatory alignment. Monitoring tools are used **solely for compliance and risk management purposes** and do not extend to unauthorized surveillance or data misuse.

Where applicable, users will be informed of the **data processing** involved in frontend interaction through transparent **privacy notices**.

***

### **7. Recordkeeping**

In accordance with the **Fifth Anti-Money Laundering Directive (AMLD5)** and applicable global best practices, AFI, through its affiliated frontend operators or third-party compliance partners, ensures that all relevant records are maintained **securely and systematically** for **regulatory, audit, and investigative purposes**.

While the core AFI protocol is decentralized and does not hold user data, **recordkeeping obligations apply at the interface level**, where user interactions with regulated components such as fiat on/off ramps, smart wallet generation, and afiusd redemptions occur.

#### **Records to Be Maintained**

The following categories of information are retained where applicable:

* **Customer Due Diligence (CDD) and Enhanced Due Diligence (EDD) Records**, including:
  * Identity documents and verification data
  * Risk assessments and EDD rationale for flagged users
  * Source of funds declarations (where required)
* **Transaction Logs and Audit Trails**, including:
  * On-chain transaction hashes and timestamps
  * Smart wallet deployment and afiusd vault interactions
  * Wallet risk classification history (e.g., analytics scores)
* **Suspicious Activity Reports (SARs)** and related internal investigation files, such as:
  * Reason for suspicion
  * Communications with FIUs or legal authorities
  * Actions taken (e.g., frontend restrictions)

#### **Retention Period**

* All AML-relevant records will be retained for a **minimum period of five (5) years**, starting from the date the relationship with the user ends or the transaction is executed.
* In cases of ongoing investigations or requests from competent authorities, records may be retained for longer as legally required.

#### **Data Security and Protection**

* All personal and transactional data is stored in **secure, access-controlled systems** by the relevant frontend or compliance entity.
* AFI and its partners commit to full compliance with the **General Data Protection Regulation (GDPR)** and any other applicable data protection laws.
* Records will be:
  * **Encrypted at rest and in transit**
  * **Accessible only to authorized personnel**
  * **Regularly reviewed for accuracy and relevance**
  * **Deleted or anonymized after the retention period expires**, unless otherwise required by law

#### **Transparency**

Users interacting with any regulated frontend of AFI will be **notified of the data collection and retention policies** through privacy notices and terms of use. **Consent**, where required, will be explicitly obtained and recorded.

***

### **8. Sanctions and Prohibited Jurisdictions**

AFI is committed to upholding international sanctions laws and preventing the misuse of its protocol by individuals or entities in restricted or high-risk regions. Although the AFI protocol operates in a decentralized and permissionless manner, **front-end interfaces, integrations, and associated service providers are subject to legal obligations** and will enforce restrictions accordingly.

#### **Prohibited Jurisdictions**

AFI and its affiliated interfaces will not knowingly offer services to users located in, or associated with, the following:

* **Jurisdictions designated as “High-Risk” or “Non-Cooperative”** by the **Financial Action Task Force (FATF)**
* Countries or territories subject to **sanctions imposed by the European Union (EU)**, the **United Nations (UN)**, or the **United States Office of Foreign Assets Control (OFAC)**
* Any other jurisdiction where the offering of decentralized financial services may contravene local laws or expose AFI to undue legal or regulatory risk

#### **Enforcement Mechanisms**

To enforce these restrictions, AFI frontends and integration partners will implement:

* **Geo-blocking and IP-based restrictions** to prevent access from sanctioned or prohibited jurisdictions
* **Compliance screening and sanctions list checks** using reputable tools (e.g., Dow Jones Risk & Compliance, World-Check)
* **Blockchain analytics** to detect indirect exposure to sanctioned wallets or high-risk sources
* **Service refusals or limitations** for users attempting to interact from prohibited regions, including:
  * Disabling onboarding
  * Rejecting afiusd vault minting or redemption
  * Blocking smart wallet initialization

#### **Disclaimer on Protocol Accessibility**

While AFI’s smart contracts are deployed on public blockchains and may be **technically accessible worldwide**, AFI **does not authorize or condone use of its platform in contravention of applicable sanctions laws.** Any such unauthorized use shall be considered a breach of this AML Policy and the AFI Terms of Use.

#### **Ongoing Updates**

Sanctions lists are subject to continuous updates. AFI and its compliance partners will monitor changes in real time and **adjust access controls accordingly** to remain compliant with evolving international regulatory obligations.

***

### **9. Training and Awareness**

AFI recognizes that a strong culture of compliance is essential to maintaining the integrity of its decentralized financial ecosystem. To that end, all contributors, developers, and teams involved in user-facing, compliance-relevant, or ecosystem-integrated activities are required to undergo **periodic Anti-Money Laundering (AML) training** and awareness programs.

#### **Mandatory Training Areas**

The training curriculum shall include, but not be limited to:

* **Understanding AMLD5 obligations**, including:
  * Customer Due Diligence (CDD) and Enhanced Due Diligence (EDD)
  * Suspicious activity monitoring and reporting
  * Recordkeeping and data retention requirements
* **Recognizing and responding to AML risk indicators**, such as:
  * Red flags involving anonymizing technologies or high-risk transaction patterns
  * Use of mixers, privacy coins, or cross-chain obfuscation techniques
  * Attempts to circumvent frontend geoblocking or sanctions enforcement
* **Proper escalation and reporting channels** for suspected financial crime, including:
  * How to document and submit Suspicious Activity Reports (SARs)
  * When and how to engage with compliance leads or legal counsel

#### **Delivery and Frequency**

* Training will be delivered through:
  * Online modules
  * Internal workshops
  * Third-party compliance partners, where applicable
* New team members must complete AML training prior to onboarding.
* Annual refresher training is mandatory for all relevant stakeholders.
* Targeted, ad hoc training may also be conducted in response to regulatory changes or newly identified risks.

#### **Documentation and Audit**

* Completion of training shall be documented and logged as part of AFI's internal compliance records.
* Audit trails will be maintained to demonstrate adherence to AMLD5 training obligations and to support reviews by regulatory or governance bodies, if required.

***

### **10. Reporting Obligations**

AFI is committed to full compliance with applicable anti-money laundering and counter-terrorism financing (AML/CTF) reporting duties under AMLD5. While the AFI core protocol remains non-custodial and decentralized, **regulated front-end interfaces** or affiliated entities facilitating user access may fall within the scope of AML regulatory oversight. In such cases, these entities assume responsibility for fulfilling all mandatory reporting obligations.

#### **10.1 Filing of Suspicious Activity Reports (SARs)**

* Where suspicious behavior is detected, whether through automated monitoring systems or manual escalation, **Suspicious Activity Reports (SARs)** will be prepared and submitted to the competent **Financial Intelligence Unit (FIU)** in the relevant jurisdiction.
* SARs will be filed in accordance with:
  * Applicable thresholds and submission timelines
  * Formatting and confidentiality standards set by the FIU
  * Requirements to avoid tipping-off affected users

#### **10.2 Cooperation with Law Enforcement**

* AFI or its associated regulated gateways will fully cooperate with authorized requests from law enforcement and regulatory authorities.
* Cooperation may include, but is not limited to:
  * Providing CDD/EDD documentation
  * Supplying transaction records and analytics
  * Freezing or suspending access through regulated frontends (where legally empowered)

#### **10.3 Escalation Protocols**

* All red flags identified by transaction monitoring systems, KYC/KYB checks, or third-party alerts will be escalated in a timely manner to designated compliance officers or legal counsel.
* A standardized escalation process shall be maintained, detailing:
  * Initial identification and classification of risk
  * Timeframes for escalation
  * Responsibilities for SAR decision-making and final review

#### **10.4 Confidentiality and Legal Protections**

* All reporting activity will be handled confidentially to preserve the integrity of investigations.
* Personnel involved in filing or supporting SARs will be protected from legal liability, provided actions are taken in good faith and in compliance with applicable laws.

***

### **11. Governance**

AFI maintains a clear governance structure to ensure effective implementation, oversight, and continuous improvement of its Anti-Money Laundering (AML) Policy.

### **11.1 Compliance Officer**

The appointed Compliance Officer holds overall responsibility for:

* Oversight of AML/CTF measures and compliance frameworks
* Ensuring adherence to AMLD5 obligations across relevant interfaces
* Managing audits, internal reviews, and reporting processes
* Acting as the primary point of contact for regulators and Financial Intelligence Units (FIUs)
* Overseeing the effectiveness of third-party KYC/AML service providers

#### **11.2 Policy Review and Maintenance**

* This AML Policy will be reviewed:
  * **At least annually**, to ensure continued relevance and effectiveness
  * **Immediately** following any:
    * Major regulatory developments
    * Structural changes in AFI’s architecture or product suite
    * Material changes in AML/CTF risk exposure
* Reviews shall be documented and approved by the Compliance Officer or equivalent governance body.

***

### **12. Disclaimer**

AFI is a **decentralized and autonomous financial protocol,** operating without custodianship or centralized control. As such, this AML Policy primarily governs:

* **Front-end interfaces** and **platform integrations** provided by third-party entities operating in regulated jurisdictions, and
* **Affiliate partners** who facilitate fiat on/off ramps or user onboarding services in compliance with AMLD5 and local laws.

Users who choose to interact directly with AFI’s smart contracts (i.e., without going through a regulated interface or integration) do so entirely at their own discretion and are solely responsible for:

* Assessing and complying with the laws and regulations applicable in their jurisdiction
* Ensuring their actions do not violate national or international sanctions or anti-money laundering provisions

AFI makes no representations or warranties regarding the legality of access or use in any specific territory.

### **Contact**

To report suspicious activity or obtain further clarification regarding this AML Policy, please contact:\
📧 \[<support@afiprotocol.xyz>]\
🌐 \[afiprotocol.xyz]


# Know Your Customer (KYC) Policy

Last Updated on 29th July 2025

### **1. Purpose**

This Know Your Customer (KYC) Policy establishes AFI’s proactive voluntary stance on identifying and verifying users to mitigate the risks of fraud, money laundering, terrorist financing, and violations of U.S. securities laws. The purpose of this policy is to ensure that AFI, through its associated front-end gateways, partners, or regulated integrations, complies with applicable legal and regulatory standards, particularly those enforced by the U.S. Securities and Exchange Commission (SEC) and the Financial Crimes Enforcement Network (FinCEN) in addition to typical St Kitts and Nevis based AML and KYC compliance requirements.

While AFI is fundamentally a decentralized, non-custodial, and autonomous DeFi protocol that does not control user assets or operate as a financial intermediary, it voluntarily acknowledges that certain access points or affiliated services may fall under the regulatory purview of U.S. federal law. In such cases, those entities are responsible for enforcing KYC obligations in line with this policy to ensure lawful user onboarding, prevent the circumvention of securities registration requirements, and uphold the integrity of the AFI ecosystem.

***

### **2. Applicability**

This Know Your Customer (KYC) Policy applies specifically to users, entities, and partners who engage with AFI through interfaces or components that may trigger U.S. regulatory obligations, particularly under the supervision of the Securities and Exchange Commission (SEC) or other federal agencies.

The policy is binding on the following categories:

* **Retail Users Utilizing Regulated Interfaces:**\
  Individuals who access AFI through front-end platforms that facilitate **fiat on/off ramps**, offer tokenized securities, or provide access to **investment advisory tools** are subject to identity verification and ongoing KYC requirements, as mandated under U.S. Anti-Money Laundering (AML) and securities laws.
* **Participants in Regulated Offerings:**\
  Any user participating in capital-raising mechanisms associated with AFI, such as **Simple Agreements for Future Tokens (SAFTs), yield-bearing financial instruments,** or other instruments that may be classified as investment contracts under the **Howey Test**, must undergo strict identity checks and suitability assessments to comply with SEC requirements.
* **Institutional Counterparties:**\
  All **exchanges, liquidity providers, custodians,** and **third-party DeFi platforms** interacting with AFI's infrastructure in a manner that involves asset custody, cross-border flows, or regulated financial services must implement robust KYC and Anti-Money Laundering controls, in line with this policy.
* **Compliant Integration Partners:**\
  Any **third-party platform, dApp, or API integration** that leverages AFI for regulated activities and is subject to **federal or state-level securities compliance** (such as broker-dealers, investment advisors, or ATS platforms) must enforce equivalent KYC standards aligned with U.S. regulatory expectations.

By clarifying these application zones, AFI ensures that regulatory accountability is maintained across the ecosystem, while respecting the protocol’s decentralized architecture.

***

### **3. Regulatory Basis**

This Know Your Customer (KYC) Policy is anchored in the relevant legal and regulatory frameworks governing identity verification, anti-money laundering, and securities compliance within the United States. It reflects AFI’s commitment to upholding industry standards and legal obligations where applicable.

The following laws and regulatory instruments form the foundation of this Policy:

* **U.S. Securities Act of 1933 (as amended):**\
  Establishes the requirement for registration of securities offerings and mandates disclosure obligations. This Act serves as the primary legal basis for identifying and verifying participants in any token offerings or yield-bearing products that may be classified as securities by the U.S. Securities and Exchange Commission (SEC).
* **Bank Secrecy Act (BSA) and FinCEN Guidelines:**\
  Requires financial institutions and certain non-bank platforms to implement comprehensive anti-money laundering (AML) programs, including Customer Identification Programs (CIP), ongoing due diligence, and suspicious activity monitoring. AFI-aligned interfaces that touch fiat rails or investment flows are subject to these obligations where applicable.
* **SEC Guidance on Digital Assets:**\
  Incorporates the Howey Test to determine whether a digital asset qualifies as a security. This guidance informs AFI’s policy on when KYC procedures must be enforced to ensure that participants in potentially regulated instruments are properly identified and vetted.
* **Customer Identification Program (CIP):**\
  Mandated under the USA PATRIOT Act, CIP regulations require identification verification of all customers engaging with financial service providers. This includes collection of basic identity information, verification through reliable sources, and screening against relevant sanctions lists.
* **OFAC Sanctions Screening and AML Controls:**\
  AFI and its compliant interfaces will screen users against the Office of Foreign Assets Control (OFAC) lists and monitor for any involvement with high-risk jurisdictions or sanctioned entities, as part of broader AML controls aligned with U.S. law.

Through this regulatory alignment, AFI ensures that its ecosystem partners and users interacting through regulated channels meet all necessary compliance obligations while participating in a secure and transparent environment.

***

### **4. Identity Verification (KYC)**

AFI is a decentralized, non-custodial protocol. However, certain services accessed through affiliated frontends, such as fiat on/off ramps, token sales, or jurisdiction-sensitive features, may require identity verification ("KYC") in compliance with applicable laws.

KYC, where applicable, will be conducted by third-party service providers (e.g., **Sumsub, Veriff, or Jumio**) integrated by the relevant frontend operator. Users may be asked to provide basic identification details such as:

* **Full name**
* **Government-issued ID**
* **Country of residence or tax domicile**
* **Biometric verification (e.g., selfie)**

The scope of information requested may vary depending on the user’s jurisdiction, risk profile, and applicable regulations. All data is handled securely by the KYC provider in accordance with relevant data protection laws.

**AFI itself does not store or access your personal identification data.**

***

### **5. Screening & Risk Assessment**

To uphold the integrity of the AFI ecosystem and meet U.S. regulatory standards, including those established by the **SEC, FinCEN, and the Office of Foreign Assets Control (OFAC)**, all users who are subject to Know Your Customer (KYC) procedures will undergo comprehensive screening and continuous risk assessment. This ensures early detection of illicit activity, sanctions evasion, and potential securities law violations.

#### **A. Sanctions and Watchlist Screening**

All verified users will be screened against a combination of international and U.S. government-issued lists, including but not limited to:

* **U.S. OFAC Sanctions Lists** – Ensuring compliance with U.S. trade embargoes and financial restrictions.
* **Specially Designated Nationals (SDNs)** – Individuals and entities subject to asset freezes or transaction bans under U.S. law.
* **PEP (Politically Exposed Persons) Databases** – Screening for current or former government officials and their close associates who may pose a heightened corruption risk.
* **Adverse Media and Financial Crime Watchlists** – Monitoring for involvement in fraud, money laundering, terrorism financing, cybercrime, or other financial misconduct as reported in credible media or regulatory filings.

These checks are conducted both at onboarding and on an ongoing basis to capture changes in risk profiles.

#### **B. Risk Scoring Criteria**

Each user will be assigned a risk score by the third-party KYC provider or AFI’s compliance framework based on a combination of behavioral, jurisdictional, and financial factors. Risk assessments may include:

* **Jurisdiction of Origin** – Users from countries identified by FATF as high-risk or non-cooperative jurisdictions will receive elevated risk ratings.
* **Wallet Activity & On-Chain Behavior** – Interaction with known mixers, darknet addresses, or anomalous DeFi patterns may increase a user's risk profile.
* **Transaction Volume and Patterns** – Sudden spikes in activity, high-frequency trading, or transactions inconsistent with the user’s stated profile may trigger review.
* **Source of Funds** – Users must demonstrate that their funds derive from legitimate, traceable sources. Where unclear, AFI may request documentation such as bank statements, payslips, or investment records.

#### **C. Enhanced Due Diligence (EDD)**

Users flagged as high-risk through the above screening mechanisms may be required to undergo Enhanced Due Diligence, which can include:

* **Additional identity verification steps**
* **Interviews or declarations regarding source of wealth**
* **Manual review of supporting documents**
* **Continuous transaction monitoring**

In some cases, access to specific AFI services, such as participation in yield-generating products or token offerings, may be restricted or denied if the risk is deemed unacceptable.

**AFI retains the right to suspend or terminate access to its interfaces and partners for users who fail or refuse risk assessment procedures or whose activity raises legal or compliance concerns.**

***

### **6. Data Retention & Security**

AFI is committed to upholding the highest standards of data protection and privacy in line with U.S. regulatory requirements and international best practices. Although AFI operates as a decentralized, non-custodial protocol and does not directly collect or store user identity data, this section outlines the expectations and safeguards applicable to KYC-related information handled by third-party providers.

#### **A. Retention Period**

All Know Your Customer (KYC) records, including user-submitted identity documents, verification logs, screening results, and compliance notes, must be securely retained by the authorized KYC provider for a minimum of **five (5) years** from the date of the user’s last activity or transaction. This retention period aligns with:

* **U.S. Bank Secrecy Act (BSA) requirements**
* **Customer Identification Program (CIP) rules enforced by FinCEN**
* **SEC and state-level obligations for broker-dealers and investment platforms**

Retention ensures that historical user data is available for regulatory inquiries, audits, or legal investigations when needed.

#### **B. Data Storage & Protection**

All KYC data must be stored in environments that are:

* **Encrypted both in transit and at rest** using industry-standard cryptographic protocols (e.g., AES-256, TLS 1.2+)
* **Access-controlled**, allowing only authorized compliance personnel or designated officers to view or modify data
* **Monitored for unauthorized access, anomalies, or breaches** through continuous security auditing and intrusion detection systems

These security measures are critical in preventing data theft, identity misuse, or reputational harm to AFI and its ecosystem partners.

#### **C. Compliance with Privacy Regulations**

All data processing activities by KYC vendors must comply with:

* **The U.S. Privacy Act, GLBA (Gramm-Leach-Bliley Act), and relevant state-level privacy laws** (e.g., California Consumer Privacy Act – CCPA)
* **The General Data Protection Regulation (GDPR)** for users located in the European Union or other jurisdictions recognizing GDPR-equivalent protections
* **Any additional cross-border data transfer protocols**, such as Standard Contractual Clauses (SCCs), if required

#### **D. Role of Third-Party KYC Providers**

AFI does not collect, store, or process any user identity data directly. Instead, AFI engages or integrates with independent, compliance-certified KYC providers (e.g., **Sumsub, Veriff, Jumio**) who are responsible for:

* **End-to-end user verification**
* **Secure document handling and storage**
* **Sanctions and PEP screening**
* **Audit trail maintenance**

All KYC providers working with AFI must meet and maintain **SOC 2 Type II, ISO/IEC 27001**, or equivalent information security certifications, ensuring robust internal controls and accountability.

***

### **7. KYC Triggers and Timing**

AFI recognizes that not all interactions with a decentralized protocol require user identity verification. However, to align with **U.S. SEC compliance requirements** and applicable financial regulations, certain user actions and access points within the AFI ecosystem may necessitate the completion of a Know Your Customer (KYC) process. This section outlines the specific events ("**triggers**") and the timing for when KYC must be completed.

#### **A. Trigger Events Requiring KYC**

Users may be prompted to undergo KYC verification prior to performing any of the following actions:

1. **Accessing Fiat On/Off-Ramps or Banking Integrations**
   * Any attempt to convert fiat to digital assets (or vice versa) through integrated service providers will require KYC due to AML and anti-fraud obligations under the **U.S. Bank Secrecy Act (BSA)**.
   * This includes wire transfers, ACH connections, card processing, or bank-linked services.
2. **Participating in Token Offerings or Reward Distributions**
   * Users engaging in regulated token offerings (such as via a SAFT or yield-bearing instruments) must complete KYC as a prerequisite.
   * This also applies to token distributions categorized as securities under the **U.S. Securities Act of 1933** or **SEC guidance**.
   * Additionally, users receiving staking, governance, or liquidity rewards in excess of a defined threshold may be subject to KYC verification.
3. **Withdrawing Large Volumes of afiUSD or Vault Tokens**
   * To mitigate the risk of money laundering and ensure compliance with transaction monitoring obligations, users may be required to verify their identity before executing high-volume withdrawals from **AFI Vaults** or redeeming **afiUSD**.
   * Withdrawal limits triggering KYC may be adjusted based on jurisdiction, on-chain behavior, and user risk scores.
4. **Engaging in Governance, Liquidity, or Node Operations**
   * Any individual or entity acting in a governance capacity, such as node operator, vault manager, or protocol delegate, may be considered a key ecosystem actor and thus subject to KYC.
   * This includes participants who manage or influence treasury functions, validator operations, or cross-chain asset rebalancing.
5. **Accessing AFI from High-Risk or Restricted Jurisdictions**
   * Users attempting to interact with AFI from jurisdictions flagged as high-risk, OFAC-sanctioned, or under regulatory embargo may be blocked or required to pass identity verification before gaining access to any front-end platform or integration.
   * KYC is mandatory in such cases to ensure that AFI and its partners are not facilitating prohibited transactions or inadvertently violating international sanctions.

#### **B. Timing of KYC Implementation**

* **KYC must be completed** before the user accesses a restricted service, submits a regulated investment, or exceeds pre-set transaction thresholds.
* In some cases, **KYC may be progressively enforced**, for example, upon first interaction, upon reaching certain usage limits, or upon backend risk triggers (e.g., unusual transaction behavior).
* If a user **fails or refuses to complete KYC** when required, their access to certain features may be restricted or suspended until verification is successfully completed.

***

### **8. Restricted Jurisdictions**

To uphold AFI’s commitment to legal and regulatory compliance, especially with **U.S. Securities and financial crime laws**, access to KYC-enabled features and services will be denied or restricted for users residing in or operating from jurisdictions flagged for legal, regulatory, or financial risks. This measure is essential to avoid violations of U.S. sanctions, prevent exposure to high-risk territories, and maintain lawful operations across the AFI ecosystem.

#### **A. Denied or Restricted Access Applies to Users From:**

1. **U.S. Embargoed and Sanctioned Countries (as per OFAC)**
   * Individuals or entities based in countries subject to comprehensive U.S. economic and trade sanctions enforced by the **Office of Foreign Assets Control (OFAC)** are strictly prohibited from accessing AFI’s front-end interfaces or affiliated services.
   * Examples of currently embargoed jurisdictions include **North Korea, Iran, Cuba, Syria**, and certain regions of **Ukraine (Crimea, Donetsk, Luhansk)**.
   * IP address checks, geolocation filters, and OFAC list screenings will be employed to enforce this restriction.
2. **Countries Identified by the Financial Action Task Force (FATF) as High-Risk or Non-Cooperative**
   * Users located in jurisdictions appearing on the **FATF "grey list" or "blacklist"**, which identifies countries with strategic AML/CFT deficiencies, may be denied access or subject to **Enhanced Due Diligence (EDD)**.
   * AFI or its front-end partners reserve the right to suspend interactions from such jurisdictions until adequate risk controls are satisfied.
3. **Jurisdictions Where Cryptocurrency or DeFi Activities Are Explicitly Illegal**
   * Countries that have imposed blanket bans on the use, trading, or development of cryptocurrency or decentralized finance services will not be supported.
   * Examples may include countries like **Algeria, Bangladesh, Nepal, or Bolivia**, where DeFi participation could violate local laws and potentially expose AFI ecosystem partners to liability.
   * Users must comply with their local legal framework; **AFI does not solicit or encourage use where prohibited.**
4. **U.S. States With Specific Crypto Regulatory Restrictions**
   * In cases where individual **U.S. states** enforce stringent crypto regulations or licensing requirements (e.g., **New York’s BitLicense** regime), users from those states may face limitations or may be excluded from accessing investment-related or custodial features of the platform.
   * This is particularly relevant for front-ends or partners offering fiat conversions, token sales, or advisory tools targeting U.S. residents.

#### **B. Ongoing Review and Dynamic Enforcement**

* The list of restricted jurisdictions will be **continuously monitored and updated** based on changes in **OFAC, FATF**, and national regulatory advisories.
* AFI and its service partners may adopt a **risk-based approach** to jurisdictional access, dynamically adjusting KYC requirements, feature availability, or outright access denial in accordance with evolving geopolitical, legal, and financial crime trends.

***

### **9. Governance and Oversight**

To ensure that Know Your Customer (KYC) procedures across the AFI ecosystem are **effective, transparent**, and aligned with applicable laws and regulatory guidance, a structured **governance and oversight framework** has been established. This framework ensures that KYC implementation is not only compliant but also adaptive to evolving legal requirements and operational realities.

#### **A. KYC Compliance Lead**

A **KYC Compliance Lead** shall be formally appointed by the AFI-affiliated front-end entity, partner organization, or operator responsible for user-facing services. This individual or team will be charged with the **strategic and operational management** of the KYC program.

Key responsibilities of the KYC Compliance Lead include:

* **Oversight of KYC Processes**\
  Monitoring the execution of identity verification workflows by third-party providers to ensure consistency, accuracy, and adherence to applicable laws and internal standards.
* **Regulatory Coordination**\
  Liaising with legal counsel, compliance consultants, and (as necessary) government agencies, including the **U.S. Securities and Exchange Commission (SEC)**, to maintain up-to-date compliance in light of new interpretations, enforcement actions, or advisory opinions.
* **Internal Controls and Incident Management**\
  Ensuring the availability of escalation protocols in the event of suspicious activity, fraud alerts, sanctions matches, or KYC data breaches. The Compliance Lead will also supervise remediation efforts and implement corrective action plans where needed.
* **Training and Guidance**\
  Providing onboarding, updates, and operational support to relevant team members, ensuring that staff interacting with KYC systems understand their legal and procedural obligations.

#### **B. Audit and Review Procedures**

To maintain the **integrity and legal defensibility** of AFI’s KYC framework, formal audits and reviews shall be conducted on a regular basis. These assessments may be internal or conducted by external auditors, depending on partner requirements and jurisdictional needs.

**Audit Triggers and Frequency:**

* **Annual Review Cycle**\
  A comprehensive annual review shall be undertaken to evaluate the effectiveness of KYC systems, vendor performance, record retention practices, and regulatory alignment.
* **Regulatory Updates**\
  KYC policies and procedures shall be reassessed immediately upon changes to key legal frameworks (e.g., amendments to the U.S. Securities Act, BSA/AML guidelines, or FATF advisories) or publication of new regulatory guidance affecting digital asset compliance.
* **Protocol or Product Changes**\
  If AFI introduces new features (e.g., tokenized securities, fiat ramps, or investment tools), expands to new jurisdictions, or modifies user interaction pathways in a way that implicates compliance obligations, a targeted policy review shall be conducted prior to rollout.

***

### **10. User Rights and Appeals**

AFI is committed to upholding the **fundamental rights** of its users in connection with the processing of personal and identity-related data. While AFI itself does not collect or directly store KYC data, it ensures that third-party verification providers and affiliated frontend platforms maintain user rights in accordance with applicable data protection regulations.

#### **A. Access to KYC Records**

Users have the right to **request access** to their own KYC data that has been collected and stored by AFI’s designated third-party identity verification providers. This includes:

* **The full set of submitted documents and personal information**
* **Screening results** (e.g., sanctions or PEP flags)
* **Risk classification or EDD (Enhanced Due Diligence) status**, if applicable

Requests for access must be submitted through the appropriate support channels of the frontend platform or the designated KYC provider. Users may be required to verify their identity again to process such requests.

#### **B. Correction of Inaccurate Information**

If a user believes that any KYC information associated with their account is **incorrect, outdated, or incomplete**, they may submit a formal request for correction or update. The process generally involves:

* **Providing evidence to support the correction** (e.g., a new address proof or updated passport)
* **Undergoing re-verification** through the third-party provider

Corrections will only be accepted if they comply with the applicable jurisdiction’s laws and the provider’s internal verification standards.

#### **C. Appeals and Dispute Resolution**

Users who are **denied access** to AFI features due to a failed or incomplete KYC process may appeal the decision through a structured **ticketing or dispute resolution mechanism** provided by the frontend interface or its KYC partner.

The appeals process typically includes:

* **Submission of a dispute ticket or email** explaining the issue
* **A review by compliance personnel** within a fixed response window (e.g., 10 business days)
* **A final determination** based on submitted evidence and verification criteria

All appeal decisions are subject to **audit and documentation** requirements to ensure fairness and transparency.

#### **D. Legal Compliance**

All user rights related to KYC data access, correction, and appeal shall be exercised in accordance with:

* **Applicable data protection laws**, such as the **U.S. Privacy Act**, **California Consumer Privacy Act (CCPA)**, or the **European Union’s General Data Protection Regulation (GDPR)**
* **AFI’s Privacy Policy**, which outlines data processing roles, third-party access, and user consent mechanisms

Users should be aware that in certain cases (e.g., investigations, law enforcement requests, or sanctions compliance), their rights may be **limited or deferred as permitted under the law**.

***

### **11. Contact**

For KYC inquiries or support, contact:

📧 **Email**: [support@afiprotocol.xyz](mailto:support@afiprotocol.ai)\
🌐 **Website**: [https://afiprotocol.xyz](https://afiprotocol.xyz/)