# FAQs #### What is YieldFi? YieldFi is the **issuance**, **distribution**, and **intelligence layer** for tokenized yield vaults—so curators can launch products, partners can distribute them, and allocators can track risk and performance in real time. #### Who is YieldFi for? YieldFi is built for four types of users: **Capital Allocators** → transparent, one-click yield exposure with clear redemption terms\ **Curators / Asset Managers** → grow AUM without building issuance + distribution + reporting infra\ **Builders / Distribution Partners** → wallets, exchanges, custodians, fintechs, banks, wealth tech companies, LP Networks etc offering “Earn” products on their platforms\ **Portfolio Managers** → funds, risk teams, treasury teams, analysts, CFO functions analysing and monitoring their performance 24/7 #### What problem does YieldFi solve? Yield opportunities across crypto and traditional markets are fragmented, opaque, and difficult to access. YieldFi makes yield: * **Accessible** through tokenized vaults * **Distributable** via SDK and partners * **Measurable** with standardized NAV, APY, and risk analytics #### What types of vaults exist? YieldFi offers vaults across the below risk ladder: * **Treasury** / T-bills for corporate treasury / DAOs * Blue-chip DeFi **lending** for corporate treasury / DAOs / Family Offices, fintechs etc * **Fixed-income** style bands for Family Offices, liquid funds, fintechs * **Market-neutral** strategies for family offices, LPs, fintechs * **Directional** / higher risk trading strategy vaults for family offices, LPs #### Where does the yield come from? Yield depends on the vault and may include: * Treasury / cash-equivalent yield (rate-driven) * DeFi lending (borrow demand-driven) * Market-neutral strategies (funding, basis, arbitrage, private deals, private credit) Each vault’s transparency page shows the sources, venues, and drivers of APY. #### Is APY real or does it include points and incentives? Displayed APY reflects realized, mark-to-market yield, net of basis only. Unrealized incentives (points, airdrops, emissions) are not included in the APY and are additive if they materialize. #### What fees do I pay? Displayed APY is always net of Fees. Fees are vault-specific and fully disclosed on the vault fact sheet. A vault may charge: * Management and/or Performance fee * Deposit or Withdrawal fee To see the exact fee stack, visit the vault specific factsheet on . #### How do I get started? It’s a simple onboarding flow: 1. Visit yield.fi/vaults 2. Choose any vault 3. Connect wallet 4. Deposit → receive vault tokens instantly #### How long does redemption take? Redemption terms are vault-specific. Most vaults target same day to \~2 days, but the exact SLA, queue behaviour, and fees are disclosed on each vault’s product page. #### Do I need KYC/KYB? Who is eligible? While most of the vaults are permissionless, some vaults require compliance checks. You’ll see a lock icon on the vault if access is restricted. To unlock: * Click Get Access * Complete KYC / KYB (via a third-party provider like Sumsub) * Typical approval time: 1–2 days #### Are there minimums or maximums? Typically, there is no minimums, no maximums. Always check vault specific page to see if there are any minimums, maximums or supply caps. #### What does “tokenized yield product” mean? It means you receive an ERC-20 token that represents your position in a vault.\ You can typically: * Hold it * Redeem it * Use it in DeFi (e.g., as collateral), where supported Legally, this token represents a subordinated debt claim against the issuer, not ownership of assets. #### Who operates the vaults? Who is managing the capital? Vault strategies are run by external curators / asset managers / strategy operators, while YieldFi provides: * vault issuance + token mechanics * custody rails * monitoring + reporting * standardized disclosures Execution setup (typical): * capital is deployed within YieldFi-owned segregated MPC custody wallets * and/or segregated exchange sub-accounts (vault-specific) If funds are ever off-ramped to a manager’s fund structure, YieldFi performs enhanced due diligence, collecting fund documentation and operational/legal materials with required disclosures on vault factsheet. #### How does YieldFi handle custody and security? YieldFi use institutional setups such as: * MPC Custody wallets * Segregated exchange sub-accounts * Custody solutions and insurances wherever applicable/available * Operational controls Custody structures (where applicable) are vault-specific and disclosed.\ YieldFi itself is non-custodial by default unless explicitly stated in vault terms. #### What risks should I understand? Key risk categories: * Market risk (rates, spreads, volatility) * Liquidity risk (redemption queues) * Counterparty risk (exchanges, custodians, borrowers) * Smart contract / protocol risk * Operational risk * Regulatory / eligibility risk If a strategy loses money, NAV declines unless the vault explicitly includes protection mechanisms. Example: protocol concentration risk (illustrative) If a vault is 50% allocated to Aave lending, and Aave suffers a major exploit: * the *vault’s loss exposure* is proportional to that 50% sleeve * your realized impact is based on your share of the vault supply (Exact loss mechanics vary by strategy design, collateral types, and mitigation layers.) #### What happens in stressed markets or a black swan? Vault-specific behavior may include: * redemptions moving into a queue * reduced strategy risk exposure * orderly unwinds rather than forced liquidations Example: “exit during stress” (illustrative) Assume: * Vault TVL: $100M * You hold: $1M (1% of supply) * Instant liquidity capacity drops from 100% → 20% * Remaining redemptions go into queue for T+2 days Then you may receive: * $200k quickly (instant capacity) * $800k over the queue window, net of any unwind costs (vault-specific) If the underlying strategy’s NAV drops during unwinds, redemptions settle at the updated NAV. #### Is APY net of fees? Yes. Displayed APY is always net of fees. #### How is NAV (token price) calculated? NAV = (Assets − Liabilities) ÷ Token Supply. #### How often is NAV updated? Vault-specific. Commonly daily, sometimes less frequent (or event-driven). The frequency is disclosed in the vault fact sheet. NAV update is vested over epoch time period to avoid front-running. In case of drop in NAV, NAV update is instantaneous. #### Are YieldFi vault tokens equity, deposits, or stablecoins? No. They are subordinated debt instruments, not equity, not deposits, and not stablecoins. They represent a contractual claim against the issuer, subject to: * Terms & Conditions * Qualified subordination * Risk and investment disclaimers #### What does transparency look like? Where feasible, vaults standardize disclosure of: * NAV, APY and TVL history * Holdings and exposure * Redemption liquidity and queue * Operational monitoring * Attestations / audits (when applicable) #### Can I borrow against vault tokens? Potentially, yes—if supported by: * Integrated lending markets * Partner venues (e.g., Aave, Morpho, Euler) Availability depends on ecosystem support. #### What happens in stressed markets? Vault-specific behavior may include: * Slower redemptions (queues) * Reduced risk exposure * Orderly unwinds rather than forced liquidations If there are protection layers (buffer/insurance/guarantees), they apply only as defined in the vault fact sheet. #### Is YieldFi DeFi-native or institutional-grade? Both. Institutional structure and reporting with DeFi-native distribution and composability. #### What should I check before allocating? A good checklist: * Strategy and yield source * Redemption terms * Custody and counterparties * NAV policy and frequency * Risk controls * Disclosures and transparency * Jurisdiction and eligibility #### How can I integrate YieldFi vaults into my product? Via SDK: * List vaults in your app (filter out unwanted vaults / filter in desired vaults) * Display NAV/APY and key terms * Enable mint and redemption flows (Redemption typically follows a request → processing flow) #### Do you offer Vaults-as-a-Service? Any setup fees? Yes, you can launch white-label or co-branded vaults. There are no fixed or one-time setup fees. #### How is YieldFi different from other vault providers (e.g., Midas, Upshift)? YieldFi’s differentiation is scope + distribution + institutional-grade disclosure. Most vault providers are typically constrained by one or more of: * single-chain focus * lending-only yield * limited distribution pathways * non-standardized reporting across strategies YieldFi enables curators to deploy across: * EVM + non-EVM environments (via partners / vault design) * multiple DeFi protocols * top CEX/DEX venues * private LP deals * market-neutral strategies …while packaging everything into a tokenized product with: * standardized NAV/APY reporting * redemption policy disclosures * transparency pages designed for allocators + distributors #### Typical allocation sizes by segment (indicative) This varies by vault category and partner setup, but typical patterns: * Retail / power users: $100 – $50k * Crypto HNW / DeFi whales: $50k – $5M * Family Offices / Funds: $250k – $25M+ * Corporate treasury / DAOs: $500k – $100M+ * Distribution partners (wallets/exchanges/fintechs): pooled flows that can scale into 8–9 figures #### Want to integrate YieldFi into your product? YieldFi offers an SDK to: * list vaults in your app (with allowlist/filters) * display NAV/APY + terms * enable mint + redemption workflows # About YieldFi Capital Markets for the Onchain Economy YieldFi is the **issuance, distribution, and intelligence layer** for tokenized yield products, built for **capital allocators, curators or asset managers, distribution partners, and portfolio managers**. Today, almost every financial product lives offchain: opaque vehicles, delayed reporting, and fragmented distribution. YieldFi is building **programmable financial assets** that bring these markets onchain—where products become composable, auditable, and easy to integrate and distribute globally. Like stablecoins upgraded money for the internet, **programmable vault tokens** upgrade financial products: they can **settle 24/7**, plug into DeFi as **collateral**, route through partners via **embedded distribution**, and expose live signals that traditional funds can’t—**NAV, APY history, TVL, exposure, leverage, liquidity ladders, proof of reserves, VaR, CVaR etc**. This is the “stablecoin moment” for financial products: not just tokenizing ownership, but upgrading product behavior and transparency. YieldFi replaces monthly or quarterly, trust-me reporting with **real-time, verifiable analytics**, so allocators can monitor positions continuously and distributors can offer yield products with institutional-grade visibility from day one. ### Important Links
Websitewww.yield.fi
Prime Terminalprime.yield.fi
Docsdocs.yield.fi
Twitter / Xhttps://x.com/getyieldfi
Telegramhttps://t.me/getyieldfi
Discordhttps://discord.gg/hkhXWr9gN9
{% hint style="info" %} YieldFi-issued tokens are **structured as debt instruments**. As a tokenholder, you do **not** acquire any legal or beneficial ownership interest in the underlying assets, and you do **not** participate directly in the profits or losses of those assets. Instead, you hold a contractual claim against the issuer. Your claim is **contractually subordinated** under a **qualified subordination agreement**. In an insolvency scenario, this means tokenholder claims rank **below all non-subordinated creditors** but **above shareholders**. The issuer is not required (and may be prohibited) from making payments if doing so would cause or worsen insolvency, and tokenholders cannot demand payment in those circumstances. For the complete description of investor rights, subordination terms, and risk factors, please refer to the applicable **prospectus**. {% endhint %} # Who Is It For? YieldFi is designed for four core personas—each with a clear workflow and a dedicated entry point. ### **Capital Allocators** **Family offices**, **DAOs**, **treasuries**, **asset managers**, **protocols**, and **HNWI/UHNWI** use YieldFi to allocate capital without building a large in-house team or subscribing to fragmented third-party analytics tools. As a capital allocator, you get **stable yield** access with institutional-grade visibility: real-time **NAV, performance history, liquidity profile, risk metrics (VaR/CVaR), and proof of reserves**—so you can underwrite and monitor positions in real time, not quarterly. ### **Curators (a.k.a Asset Managers)** Curators use YieldFi Vaults to **collect and manage capital onchain** without standing up a traditional fund structure or carrying the same compliance and reporting overhead required for fund operations and NAV reporting. As a curator, you get a **friendly interface**, **institutional rails** for defi and cefi access and the ability to **set tiered fees for your services.** A composable ERC20 token and transparent performance layer helps you **scale AUM**—by letting allocators use the vault token as collateral across DeFi and evaluate returns, drawdowns, exposures, and liquidity in real time. ### **Distribution Partners** Wallets, Exchanges, Custodians, Fintechs, Banks, Wealth Tech Platforms and LP Networks integrate YieldFi to **embed compliant yield products into their UX** and earn distribution fees—without reinventing vault infrastructure, reporting, or risk tooling. As a distributor, you get an **easy to integrate SDK** and transparent **commission structure**. YieldFi products are designed to be **self-custodial** and **permissionless in access**, while remaining compliant at the product and distribution layer. ### **Portfolio Managers** Funds, risk teams, analysts, and CFO/treasury teams use YieldFi to analyze any set of wallets or yield bearing tokens for **yield opportunities, exposure concentration, liquidity constraints, and risk**. You care about **benchmarking**, missed-yield identification, and decision-grade risk intelligence—**drawdowns, VaR/CVaR, and liquidity ladders**—to manage portfolios with institutional discipline. # Value Proposition (Benefits) {% content-ref url="/pages/6BMSFfPoqlnxWRkeoO4a" %} [Capital Allocators](/value-proposition-benefits/capital-allocators) {% endcontent-ref %} {% content-ref url="/pages/Cj2bMqZBXU5TpZpawpcy" %} [Curators (Asset Managers)](/value-proposition-benefits/curators-asset-managers) {% endcontent-ref %} {% content-ref url="/pages/VmorV4epNU6cSACW5Xr4" %} [Distribution Partners](/value-proposition-benefits/distribution-partners) {% endcontent-ref %} {% content-ref url="/pages/5ogYISqzSPwVVPwwMmX2" %} [Portfolio Managers](/value-proposition-benefits/portfolio-managers) {% endcontent-ref %} # Capital Allocators ### Benefits for Capital Allocators 1. **Capital efficiency (native leverage + instant liquidity options)**\ Vault receipt tokens are programmable assets—you can **borrow against them**, use them as collateral, or loop strategically for capital efficiency or short-term liquidity, without liquidating the underlying position. 2. **Real-time transparency vs “trust-me” reporting**\ Instead of waiting for monthly/quarterly statements, allocators can track **NAV, performance, exposures, leverage, liquidity profile, and proof of reserves** continuously—making manager selection and ongoing monitoring meaningfully sharper. 3. **Institutional analytics built-in (no vendor sprawl)**\ YieldFi Prime gives institutional-grade reporting out of the box: **Sharpe/Sortino**, **VaR/CVaR**, drawdowns + recovery, liquidity ladders, Delta, concentration/exposure by asset/protocol/chain, and redemption SLA history—without subscribing to multiple third-party tools. 4. **Operational simplicity (one click, one standard, many strategies)**\ Onboarding is standardized: consistent issuance/redemption flows, unified reporting, and comparable metrics across managers—so allocators can run a portfolio of strategies without bespoke fund docs, data formats, or manual reconciliation. 5. **Composability + portfolio construction**\ Vault tokens can integrate into onchain portfolio construction (lending markets, structured products, tranching, hedging overlays), enabling strategies and risk management workflows that are hard to replicate offchain. # Curators (Asset Managers) ### Benefits for Curators (Asset Managers / Trading Teams) 1. **Permissionless capital formation (within compliance gates)**\ Launch once and access global distribution through YieldFi’s website + partner SDKs, while still enforcing **eligibility and jurisdiction constraints**. 2. **Institutional-grade transparency that compounds distribution**\ A manager’s edge becomes legible: real-time performance, exposures, liquidity profile, and risk metrics improve trust, reduce DD friction, and accelerate AUM growth. 3. **No fund ops stack required**\ Avoid building a full offchain fund machine (admin, NAV reporting, investor statements, data room overhead). YieldFi bundles issuance + accounting primitives + reporting. 4. **Scale distribution without bespoke integrations**\ Integrate once, then get surfaced across distributors (wallets, exchanges, custodians, fintechs). This is a structural advantage vs isolated SMA relationships. 5. **Brand building with a verifiable track record**\ Your vault is a living track record with comparable metrics—making performance marketing factual and auditable. 6. **Flexible monetization**\ Set **custom fee schedules** (management/performance/other) aligned to strategy and target market, and iterate faster than traditional fund structures. Offchain funds and SMAs can still win on **legacy allocators, bespoke mandates, and regulatory comfort,** but YieldFi vaults win when you value **speed, composability, transparency, and standardized analytics + distribution**. # Distribution Partners ### Benefits for Distribution Partners *(Wallets, Exchanges, Custodians, Fintechs, Banks, Wealth Platforms, LP Networks)* **New revenue line without recreating products**\ Embed YieldFi vaults as native Earn / Yield products and capture distribution fees, without building vault infrastructure, custody workflows, accounting, reporting, or risk systems from scratch. **SDK-first integration (fast time-to-market)**\ Integrate once via SDK and immediately access a growing catalog of vaults with standardized data (NAV, APY, risk, liquidity, terms). No bespoke product engineering for every strategy or manager. **Distribution with compliance controls**\ Vaults can enforce eligibility, jurisdiction restrictions, and greenlisting/KYC requirements where needed. This allows partners to offer yield products while maintaining internal compliance standards. **Better products for users (higher retention)**\ Instead of offering basic lending yields only, partners can offer a full yield curve: * Treasury-style products * Fixed-income style vaults * Market-neutral yield * Advanced strategies This improves user lifetime value, stickiness, and wallet AUM. **Transparent products reduce reputational risk**\ Every vault ships with standardized transparency (NAV/APY history, risk metrics, redemption terms, disclosures). Partners are not distributing “black box” products. # Portfolio Managers ### Benefits for Portfolio Managers *(Funds, Risk Teams, Treasury Teams, Analysts, CFO Functions)* **Unified visibility across wallets, tokens, and strategies**\ Analyze any combination of wallets and tokens as a single portfolio. Track NAV, performance, exposures, liquidity, and risk holistically rather than per-protocol or per-wallet. **Institutional-grade analytics without internal tooling**\ YieldFi Prime provides built-in analytics typically requiring Bloomberg + custom quant tooling: * Sharpe / Sortino Ratios * VaR / CVaR * Drawdowns + recovery * Liquidity ladders * Exposure by asset, protocol, chain * Concentration risk * Redemption SLA history No need to build internal dashboards or subscribe to fragmented tooling. **Benchmarking becomes trivial**\ Compare: * One vault vs another vault * Your portfolio vs any vault * Your strategy vs market-neutral alternatives * Wallet A vs Wallet B This enables data-driven allocation decisions instead of narrative-based decisions. **Risk management becomes continuous, not periodic**\ Instead of monthly reports, risk is observable **in real time**. Portfolio managers can react faster to: * Liquidity compression * Exposure drift * Drawdown acceleration * Concentration build-up **Better portfolio construction**\ Because vault tokens are standardized and analyzable, PMs can construct portfolios the way they would with ETFs or funds: * Blend risk tiers * Size positions * Manage correlation * Optimize risk-adjusted yield **Works across onchain and offchain exposure**\ Even if capital is deployed across multiple wallets, chains, or managers, YieldFi Prime can normalize the analytics layer into one coherent portfolio view. # Vault Types YieldFi lets you launch and distribute a full spectrum of **tokenized yield vaults**—from cash-management to hedge-fund style strategies—without rebuilding fund plumbing. Below are example product categories you can create on YieldFi, each backed by **real-time analytics** (NAV, APY history, TVL, exposure, liquidity ladder, proof of reserves, VaR/CVaR) and **institutional rails** (custody and controlled execution account structures). ### **Treasury Vaults** Ideal for corporates and DAO treasuries that want a conservative, cash-like allocation with **same-day liquidity**. Returns are linked to **T-Bill yields**, targeting **3%–4%** with a **stable NAV objective** and virtually no drawdowns. ### **Lending Vaults** Serves the same treasury audience but target a higher yield band by allocating to **blue-chip lending markets** such as Aave V4, Morpho, Euler, Maple etc. These vaults aim for **6%–8%** yield with **same-day liquidity** and a stable NAV objective with virtually no drawdowns. ### **Fixed Yield Vaults** They are cash-management style products for startups, SMEs, family offices, and HNWI seeking predictable returns with **<2-day liquidity**. They typically target **\~10%** yield with a stable NAV objective and virtually no drawdowns. ### **Market Neutral Vaults** Suited for allocators who want higher yields without directional exposure. Strategies include **basis/funding, arbitrage, RWA yield, lending/looping, private LP deals etc**, aiming for **12%–15%** yield with **tight risk controls**, a stable NAV objective and virtually no drawdowns. ### **Directional Strategy Vaults** Built for higher-risk mandates where trading teams deploy their strategies that mirrors how they typically run **SMA (separately managed account) mandates** for capital allocators—except packaged into a **tokenized vault** with automated accounting and transparent reporting, targeting **30%–35% yield**, with **defined risk controls** and drawdowns typical capped at 5-10%. Together, these categories cover most of the “yield” universe—cash management, credit-like lending, market neutral, and directional alpha. What’s intentionally left out from the broader capital-markets set are **pure equity index funds, long-duration bond funds, venture/private equity funds, distressed/activist strategies, commodity/real estate direct ownership vehicles, and highly illiquid private credit structures**—products where liquidity, valuation cadence, and legal wrappers typically require different market infrastructure than yield-first vaults. # Vault Use Cases YieldFi vaults are programmable, tokenized yield products that let teams launch, distribute, and monitor strategies with institutional-grade reporting from day one. They unlock several high-leverage use cases across managers, protocols, and fintech distribution, such as: ### **Capital Formation Vehicle** For **curators, asset managers, fund managers, strategy managers, and trading teams**, YieldFi vaults act as a “set it once, scale forever” capital formation layer. A manager launches a vault, defines strategy and risk parameters, and then keeps collecting capital **permissionlessly within compliance constraints**, with **automated NAV accounting** and transparent reporting. Compared to bespoke offchain fund operations, vaults can materially reduce overhead while enabling fundraising from both **onchain capital** and **fiat rails** (e.g., via **ISIN-based** distribution where applicable). ### **Pre-Deposit Campaigns** Protocols and ecosystems can launch pre-deposit vaults to **collect capital before mainnet launch** and put it to productive use—whether to **reward early users with yield**, **subsidize chain growth costs**, or **build a long-term treasury**. This turns idle pre-launch capital into a strategic resource instead of a passive waitlist. ### **Whitelabel Vaults** Teams can ship fully **whitelabeled yield products in days**, not months—without building vault contracts, custody workflows, accounting, reporting, or risk tooling. YieldFi provides: a whitelabeled UX, **real-time transparency** (NAV, APY history, TVL, exposure, liquidity, leverage, VaR/CVaR, proof of reserves), and **institutional rails** out of the box for DeFi execution and **exchange SMA/sub-accounts across major exchanges** for controlled permissions and clean accounting. This matters because most products fail on operations, not strategy. ### **Earn Products for Wallets, Exchanges & Fintechs** Wallets, Exchanges & Fintechs can embed “neobank-like” savings experiences using **Treasury Vaults** and **Lending Vaults**, offering **same-day liquidity expectations** where applicable—without building banking rails. # How It Works YieldFi vaults issue **ERC-20 vault tokens** that represent a pro-rata claim on a vault’s underlying assets and strategy performance. The vault’s value is tracked through a **Net Asset Value (NAV)** that is updated periodically as the strategy generates profits or losses, net of any applicable fees. Users interact with vaults through two core flows: Deposit (instantaneous) and Withdrawals (with a queue). ### Deposit (Instantaneous) When you deposit the supported asset into a YieldFi vault, the vault **mints ERC-20 vault tokens** to your wallet, representing your pro-rata claim on the vault. Mint pricing is defined by a vault **feature flag** such that deposit price is set at: * **Current NAV**, or * **Higher of Current NAV vs end of epoch NAV** The second option is designed to prevent anyone from depositing and withdrawing between NAV updates. ### Redemption (WithdrawQueue → Payout) To redeem, you submit a request that enters the **WithdrawQueue**. You may **cancel** the request any time before it is processed. Once processed, the vault burns the redeemed vault tokens and transfers the underlying assets to the specified **receiver wallet address**. Redemption pricing is defined by a vault **feature flag** such that redemption price is set at: * **Current NAV**, or * **Lower of Current NAV vs end of epoch NAV** The second option is designed to prevent bank run in case of loss in the vault strategy. ### Yield Distribution Yield is distributed by updating the vault NAV to reflect strategy performance, net of any **management fees** (if applicable). When performance is positive and the **new NAV is higher** than the High Water Mark, the increase is not applied as a single step. Instead, the NAV update is **vested over a defined epoch period**, which reduces the ability for anyone to front-run a known NAV jump by depositing right before it or redeeming right after it. When performance is negative and the **new NAV is lower** than the current NAV, the NAV update is applied **instantly**, ensuring losses are reflected immediately. Even in this loss scenario, front-running is mitigated because redemptions can be configured to process at the **lower of current NAV or end NAV**, which prevents users from escaping losses by withdrawing at a temporarily higher NAV before the end-of-epoch accounting is finalized. ### Compliance Gating (Greenlist) A vault may require a **Greenlist** from day one. When enabled, any user who wants to mint or redeem must complete **KYC/KYB** and **AML checks** to satisfy regulatory compliance requirements for that specific product. ### Redemption SLAs & Fees Each vault’s expected **redemption SLA** (processing time) and all applicable **fees** are disclosed on the vault’s factsheet at [**www.yield.fi/vaults**](http://www.yield.fi/vaults), so users can evaluate liquidity and costs before depositing. # Fees If the vault doesn’t earn for you, you don’t pay {% hint style="info" %} YieldFi fees are designed to be **fair, transparent, and performance-aligned**. Fees are deducted from **vault yield/profits**, not from principal. In simple terms: **if the vault doesn’t earn, you don’t pay.** Each vault’s fee model is set **in consultation with the curator (strategy manager)** and can include **management fees**, **performance fees**, and in some cases **asset-wise deposit/withdrawal fees** to cover real execution costs and discourage short-term mercenary behavior. {% endhint %} YieldFi vaults are built to be investor-aligned and performance-first. Fees are designed so they are paid only when the vault creates value, and curated in consultation with vault curators (strategy managers) to match each strategy’s economics and risk profile. To see the exact fee stack, visit the vault specific factsheet on . #### How Fees Are Decided * Fees for each vault are set in consultation with the curator (strategy manager) * A vault may charge: * Management Fee (if applicable) * Performance Fee (if applicable) * Deposit Fee (asset-wise, if any) * Withdrawal Fee (if any) #### Key Principle: Fees Come from Performance, Not Principal * Fees are deducted from vault yield/profits, not from the user’s pocket * No yield → no fees (management and partner add-on fees are not deducted if yield is insufficient) * Principal is not reduced to force fee collection ### Management Fee A periodic fee to cover the ongoing cost of running the vault, including: * Operations & execution * Monitoring & risk oversight * Reporting & vault infrastructure **How it works** * Management fees are accrued pro-rata (typically annualised) * Many curators choose 0% management fee for higher-yield strategies **Investor protection** * Management fees are charged only if yield generated in that period is greater than the pro-rata management fee * If yield is insufficient, the management fee is not charged * This ensures management fees never come out of principal and never reduce NAV during low-yield periods ### Performance Fee A performance fee is charged as a percentage of profits generated by the vault, calculated after accounting for the management fee (if any). This ensures performance fees apply only on net profits delivered to investors. Where it usually applies * Performance fees are typically not charged for low-yield commodity vaults, such as: * Treasury Vaults * Lending Vaults * Performance fees are more common in high-yield strategies, such as: * Market Neutral Vaults * Directional Trading Vaults #### Tiered Performance Fees (Optional) Performance fees can be tiered to incentivize curators to improve returns without increasing the vault’s risk. * Better performance can unlock higher fee tiers * But curators are incentivized to maintain a stable risk score #### Risk Score Discipline YieldFi vaults emphasize transparency through a visible risk score: * If the curator increases risk and the risk score goes up, users can see it transparently * Users may withdraw capital, reducing the curator’s AUM * Lower AUM reduces curator earnings — acting as a natural penalty for taking excessive risk #### High Water Mark Protection All performance fees follow a High Water Mark (HWM) rule to protect investors: * If NAV falls below its prior peak, no performance fee is charged * Performance fees resume only after NAV exceeds the previous high water mark * This prevents investors from paying performance fees twice on the same recovery ### Deposit Fees Some vaults may include asset-wise deposit fees, especially for assets with: * Low on-chain liquidity (leading to slippage) * Minting / redemption fees at the asset level * Low utility in DeFi, requiring conversion into a more usable asset for deployment Why this exists * Deposit fees cover real conversion costs such as: * Slippage * Minting / redemption fees * Asset conversion into an asset with better utility across DeFi/CeFi * This ensures existing vault users are not diluted or impacted by conversion costs triggered by new deposits *** ### Withdrawal Fees Withdrawals from a vault are processed in a single asset (as defined by the vault). Some vaults may apply withdrawal fees to protect long-term vault stability. Why this exists * Withdrawal fees discourage mercenary capital that: * deposits for a few days * exits immediately when possible * YieldFi vaults are designed for long-term, patient capital, where: * returns compound over time * stable capital improves execution and overall outcomes * Withdrawal fees help ensure the vault attracts investors aligned with compounding over time, rather than short-term churn # Flow of Funds This page describes the standard flow of funds where YieldFi issues multiple Vaults. Each Vault is a distinct product/strategy with segregated asset control and accounting using segregated MPC wallets and segregated exchange accounts per Vault. ### Structure at a glance YieldFi creates multiple Vaults (e.g., *Vault A / Vault B / Vault C*). Users deposit into a specific Vault, and YieldFi issues the Vault tokens to the user under that Vault’s terms. Core principle: assets, liabilities, cashflows, and reporting are Vault-specific, implemented via segregated MPC wallets and segregated exchange accounts per Vault. ### Parties and roles * Users: Deposit into a specific Vault and hold the Vault tokens. * Issuer — YieldFi: Creates Vaults, defines Vault terms (with Curator input), issues Vault tokens, and oversees service providers and controls. * Vault: Product-level pool with its own asset segregation, accounting, and terms. * Curator: Executes strategy for the Vault and manage risks w\.r.t. deployments, rebalances, and liquidations. * Segregated MPC Wallets (per Vault): On-chain wallets dedicated to each Vault (deposit, collateral/strategy, redemption/processing), used to receive, hold, and move assets. * Segregated Exchange Accounts (per Vault): Vault-specific exchange sub-accounts used for execution, hedging, and yield strategies (where relevant). * Administrator / Accounting / Paying Agent function (internal or outsourced): Maintains vault level assets and token supply, calculates NAV, processes mint/burn and redemptions, and produces reporting. ### Diagram — end-to-end flow of funds ``` Users | | (deposit request; eligibility/KYC gates as applicable) v Issuer: YieldFi | | creates Vaults + publishes Vault terms + appoints Curator v +-------------------+ +-------------------+ +-------------------+ | Vault A | | Vault B | | Vault C | | (Product/Strategy)| | (Product/Strategy)| | (Product/Strategy)| +-------------------+ +-------------------+ +-------------------+ | | | | | | | | | | | | | Segregated | Segregated | Segregated | MPC Wallets (A) | MPC Wallets (B) | MPC Wallets (C) | + Exchange Accts (A) | + Exchange Accts (B) | + Exchange Accts (C) | | | | | | v v v v v v Deploy into DeFi / Exchanges / Hedging / Yield Strategies (per Vault mandate) | v Strategy P&L returns to the same Vault’s MPC wallets / exchange accounts | v Fees -> Distributions (if any) -> Redemptions (per Vault rules) ``` ### Step-by-step asset flows #### Deposit and issuance (User → Vault) 1. User selects a Vault (e.g., *Vault A*) and initiates a deposit. 2. User transfers assets to Vault A’s dedicated deposit MPC address. 3. Operations/admin logic validates receipt and eligibility checks (as applicable). 4. YieldFi issues the Vault token/position to the user under Vault A and updates Vault-level accounting. #### Deployment / execution (Vault → DeFi / Exchanges) 1. Assets stay in Vault A's deposit MPC address. 2. If the strategy uses exchanges, assets may be transferred to Vault A’s segregated exchange accounts (or mirrored/hedged there). 3. Otherwise, Curator executes strategy actions for Vault A: * DeFi deployments (whitelisted protocols/endpoints as applicable), * exchange execution / hedging, * rebalances and risk actions. #### Income and P\&L collection (DeFi / Exchanges → Vault) Strategy income, realized P\&L, and principal flows return to: * Vault A collateral/strategy MPC wallets, and/or * Vault A exchange accounts, with periodic sweeps back to MPC wallets where applicable. #### Fees and expenses (paid from the Vault) Vault-level management and/or performance fees (as applicable) are accrued and settled from Vault A assets only. #### Distributions (if the Vault pays out) If Vault A supports periodic payout, YieldFi processes distributions from Vault A’s redemption / processing MPC wallet to user wallets, per Vault terms. #### Redemption (Vault → User) 1. User submits a redemption request for Vault A (per redemption rules, cooldown period, and limits). 2. YieldFi calculates redemption amount based on Vault A’s NAV/price and applies fees (if applicable). 3. Vault A sources liquidity by: * using on-hand liquidity buffers, and/or * unwinding DeFi positions, and/or * closing exchange hedges and transferring assets back to MPC wallets. 4. YieldFi pays the user from Vault A’s dedicated redemption/processing MPC wallet and burns/reduces the user’s Vault token/position. {% hint style="info" %} In summary, Segregation is enforced at the Vault level through a dedicated MPC wallet set per Vault (deposit, collateral/strategy, and redemption/processing), plus segregated exchange sub-accounts with clear Vault attribution. YieldFi maintains Vault-specific books and records—positions, P\&L, NAV, and token supply/user balances—and prohibits cross-Vault transfers. {% endhint %} # Operational Control This page describes the operational control model where YieldFi operates multiple Vaults. The model replaces traditional administrator and agency functions with a software-driven control layer, uses MPC wallets and exchange sub-accounts for custody and execution, and makes the Curator the sole risk manager for each Vault. ### Operating model YieldFi creates multiple Vaults (e.g., Vault A / Vault B / Vault C). Each Vault is a distinct product with its own terms, asset segregation, accounting, and reporting. Operational control is enforced through (i) Vault-level mandates, (ii) software modules that implement lifecycle rules, and (iii) segregated MPC wallets and exchange sub-accounts per Vault. ### Control objectives • Maintain clear accountability for decision-making and execution\ • Enforce Vault-level segregation across assets, liabilities, cashflows, and reporting\ • Control asset movements with explicit permissions, logs, and verifiable execution trails\ • Produce consistent NAV, reporting, and user lifecycle processing at the Vault level ### Governance and decision rights **YieldFi**\ • Approves creation, modification, and termination of Vaults\ • Publishes Vault terms, including deposit assets, fees, redemption SLAs, valuation policy, and risk limits in consultation with the Curator\ • Approves Curator appointment and maintains a Vault-specific mandate for the Curator\ • Oversees whitelisting of DeFi protocols and execution endpoints based on Curator requirements **Curator**\ • Operates strategy execution within the Vault mandate\ • Initiates deployments, rebalances, hedges, liquidations, and position unwinds\ • Manages Vault-level risk within defined limits and escalation triggers\ • Provides strategy rationale and post-trade reporting inputs into the software control layer ### Roles and responsibilities (software + custody/execution control) **Software Module — Vault Lifecycle & User Operations**\ • Processes deposits and redemptions per Vault terms (windows, limits, queues)\ • Mints/burns Vault tokens and maintains user balance ledger\ • Enforces eligibility/KYC gating where applicable\ • Produces user confirmations and lifecycle event logs **Software Module — Accounting, NAV & Reporting**\ • Maintains Vault-level books (positions, cash, liabilities, P\&L, fees)\ • Calculates NAV per Vault methodology and frequency\ • Reconciles token supply vs Vault net assets and flags breaks\ • Produces reporting packs (NAV history, performance, holdings, fees) **Software Module — Payment Waterfall & Fee Engine**\ • Accrues and settles Vault-level fees per terms\ • Enforces the Vault’s payment priority (fees → payouts/redemptions)\ • Generates an audit-ready trail of all calculations and settlements **Segregated MPC Wallets (per Vault)** * Segregated on-chain wallets per Vault, typically including:\ • deposit wallet(s)\ • collateral/strategy wallet(s)\ • redemption/processing wallet(s) * Execute transfers based on authorized instructions and policy checks\ • Preserve immutable transaction history for all on-chain movements **Exchange sub-accounts (per Vault)**\ • Segregated exchange sub-accounts per Vault used for execution, hedging, and yield strategies\ • Enforce Vault attribution at the venue level (positions, margin, financing, P\&L)\ • Produce account statements for reconciliation back into Vault accounting ### Vault segregation in operations • Each Vault uses a dedicated MPC wallet set and dedicated exchange sub-accounts\ • The software modules maintain Vault-specific ledgers and reporting outputs\ • Asset movements only occur within the Vault’s approved pathways (MPC ↔ DeFi, MPC ↔ exchange sub-account)\ • Cross-Vault transfers are prohibited ### Asset movement controls **Instruction controls**\ • Curator initiates strategy actions and transfers within the Vault mandate\ • Software enforces policy checks (whitelisted endpoints, limits, timing rules, role permissions) before execution\ • High-risk actions (new endpoint, large transfer, emergency unwind) trigger elevated checks and escalation **Authorization controls**\ • Role-based access control across software modules and signing policies\ • Maker-checker approvals for sensitive actions (config changes, whitelist changes, large moves)\ • Full logging of who approved what, when, and why **Reconciliations**\ • Reconcile MPC wallet balances and transactions against internal Vault ledger\ • Reconcile exchange sub-account balances, positions, and P\&L against internal Vault ledger\ • Exceptions are tracked with status, owner, and resolution notes ### NAV, pricing, and reporting controls • Each Vault has a defined valuation policy (sources, frequency, cutoffs, fallback rules)\ • The NAV module produces daily/periodic NAV and flags pricing anomalies\ • Manual overrides (if any) are permissioned, justified, logged, and reviewable\ • Reporting outputs remain Vault-specific: NAV, performance, holdings, fees, and token supply reconciliation ### Fees and settlement controls • Fees accrue and settle at the Vault level, not across Vaults\ • Distributions (if supported) and redemptions are paid from the Vault’s redemption/processing MPC wallet\ • Any off-chain settlements (e.g., exchange financing costs) are allocated back to the Vault ledger with supporting records ### Change management and escalation • Vault term changes and risk-limit changes follow a controlled workflow (proposal → review → approval → versioned release)\ • Whitelist changes (protocols/endpoints) are versioned and auditable\ • Escalation triggers are defined per Vault (limit breach, liquidity stress, exchange margin events, oracle/pricing anomalies)\ • Incidents produce a post-event report and result in control updates where required # Bankruptcy Remote Structure This page explains how YieldFi structures user assets and Vault operations to achieve bankruptcy-remoteness by design—i.e., to isolate user assets and Vault liabilities from the operating company’s balance sheet and from unrelated creditors, to the maximum extent practical given the legal and operational setup. ### Objective • Ring-fence each Vault’s assets and liabilities from YieldFi’s corporate assets and liabilities\ • Reduce the risk of commingling, set-off, or creditor attachment in an insolvency scenario\ • Ensure Vault cashflows are applied only to Vault obligations, based on a defined recourse perimeter\ • Provide governance, controls, and documentation that support legal enforceability ### Core building blocks #### Asset segregation at the wallet and account level • Each Vault operates with a dedicated MPC wallet set (deposit, collateral/strategy, redemption/processing)\ • Each Vault uses dedicated exchange sub-accounts with explicit Vault attribution\ • Vault assets are tracked and reported on a Vault-by-Vault basis (positions, NAV, token supply, liabilities) #### Vault-level ring-fencing of liabilities • Vault liabilities (fees, execution costs, hedging, operational expenses) are allocated to the Vault under the Vault terms\ • No cross-Vault support: assets of one Vault are not used to satisfy another Vault’s obligations\ • Cash movement pathways are constrained to the Vault’s approved lifecycle flows (deposit → strategy → redemption) #### Contractual recourse perimeter (who can claim what) • Strategy counterparties and service providers contract with YieldFi on Vault-scoped terms, intended to limit recourse to the relevant Vault assets where applicable\ • User terms define the Vault’s payment waterfall and the method of mint/redemption and fee charging\ • Transfers, execution, and protocol interactions are constrained to whitelisted endpoints, whitelisted assets and controlled roles #### Operational separation from corporate treasury • YieldFi maintains separate operational treasury distinct from Vault assets\ • Corporate expenses are funded from corporate treasury—not from Vault assets—except for Vault-attributable expenses explicitly disclosed in Vault terms ### Diagram — bankruptcy-remote intent ``` YieldFi (Operating Company) (people, IP, product, software, ops treasury, vendor contracts) | | no commingling of funds v ---------------------------------------------------------------- Vault A (ring-fenced pool) Vault B (ring-fenced pool) Vault C - MPC wallets + exch accts - MPC wallets + exch accts - ... - Vault NAV + token supply - Vault NAV + token supply - Vault liabilities only - Vault liabilities only ---------------------------------------------------------------- | | | v v v Users of Vault A Users of Vault B Users of Vault C ``` ### Control framework supporting remoteness • Segregation controls: Dedicated wallets/accounts, Vault-level ledgers, and prohibition on cross-Vault transfers\ • Permissioned asset movement: Role-based controls, maker-checker for sensitive actions, and immutable on-chain audit trails\ • Reconciliation and attestations: Reconcile MPC + exchange balances to Vault ledgers and token supply; investigate and document exceptions\ • Versioned Vault terms: Controlled changes to fees, valuation policy, and risk limits with clear governance # Primary & Secondary Liquidity We support DeFi integrations through two liquidity mechanisms: a **primary liquidity** path implemented through native mint and redemption, and a **secondary liquidity** path implemented through venue-based trading (being added in partnership with a trading venue). This structure mirrors how liquidity is provided in traditional markets through **mutual fund primary liquidity** and **ETF secondary liquidity**, while remaining compatible with vault-specific redemption mechanics. ### Primary Liquidity: Native Mint and Redemption Every yToken is issued and redeemed through YieldFi’s native facility. * **Mint (issuance):** yTokens are minted when a user deposits the vault’s accepted deposit asset(s). The amount of yTokens minted is determined by the vault’s issuance logic and NAV reference at the time of processing. * **Redeem:** yTokens are redeemed when a user burns yTokens to receive the vault’s designated redeem asset. Redemption proceeds are determined by the vault’s redemption logic and NAV reference at the time of processing. Primary mint/redemption functions as the **canonical liquidity path** for yTokens. It is the mechanism that anchors yToken valuation to the vault’s NAV methodology and provides a standardized entry/exit route across all vaults. ### Secondary Liquidity: Trading Venue Liquidity (Coming Soon) YieldFi is adding secondary liquidity for yTokens through partnerships with a **trading venue**. Secondary liquidity is implemented as **secondary market trading** of yTokens, enabling holders to buy or sell yTokens on a venue without using the mint/redemption process for that transaction. This is particularly relevant for vaults that operate with **2+ day cooling periods**, where secondary trading can provide an alternative path for users who prefer immediate liquidity rather than waiting for the redemption cycle. ### Liquidity Model Used by DeFi Builders For DeFi integrations—especially lending markets—liquidity is evaluated based on two properties: 1. the presence of a **canonical exit route** (primary mint/redemption), and 2. the availability of **secondary trading** (venue liquidity) where faster exits are required or preferred. YieldFi’s model supports both properties without requiring YieldFi to maintain continuous AMM liquidity for each yToken. # Liquidation Services YieldFi runs **Liquidation Services** to make vault tokens safely usable across DeFi markets—especially for **lending and borrowing** use cases. When yield-bearing vault tokens are accepted as collateral on protocols like **Aave (including V4-style deployments as they roll out), Morpho, Euler, Silo**, and similar markets, the health of the lending market depends on one thing: positions at risk must be liquidated quickly and reliably. Relying solely on secondary **DEX liquidity** for vault tokens is often inefficient, because deep pools typically require continuous, expensive liquidity incentives and can still fail under stress. YieldFi’s approach is to provide **specialized liquidation execution** as an alternative to subsidized DEX depth. Liquidation bots monitor supported lending markets for accounts approaching liquidation thresholds. When a position becomes liquidatable, the liquidation service steps in to purchase the collateral (vault tokens) and repay the borrower’s debt—restoring the market’s solvency. The acquired vault tokens are then redeemed through the vault’s redemption rails, converting them back into the underlying assets. This makes liquidation more predictable because it ties liquidity to the vault’s redeemability and operational SLAs rather than relying on volatile DEX pool depth. Liquidation SLAs are targeted to support liquidating up to **10% of a vault’s TVL at any time** (subject to venue limits and vault-specific constraints). Capacity is actively managed and continuously rebalanced. For example, if the liquidation bot executes a **$1M** liquidation on a Morpho market, it will promptly redeem the acquired collateral and recycle proceeds to **top up its available capital**, ensuring the next liquidation can be executed on time. This loop keeps lending markets healthy, reduces the need for mercenary liquidity mining, and enables vault tokens to function as robust collateral primitives. # Price Oracles ### Price Oracle (for Lending Markets) Lending markets need a reliable price oracle to value collateral accurately, enforce LTV limits, calculate health factors, and trigger liquidations safely. YieldFi vault tokens are designed to be first-class collateral assets, so each **vault ERC-20 token** exposes an onchain price feed that tracks the vault’s underlying value and can be consumed directly by lending protocols or by adapter contracts. #### Pricing Methodology Each vault token tracks a **reference value** that reflects the economic value of its underlying assets and strategy performance (net of applicable fees). As this reference value changes, the oracle updates the price, so the token’s onchain price follows the same source of truth as used for vault accounting. To strengthen transparency, we use a **proof-of-reserve design** for the oracle infrastructure. When assets or collateral sit offchain, **independent third parties** verify balances and provide attestations. This gives additional assurance that underlying collateral supports the token’s reference value. For **canonical settlement**, the vault processes redemptions at the designated onchain oracle price. This keeps issuance and redemption consistent with the same price that lending markets rely on. #### Oracle Interface (Chainlink-Compatible) Each vault token implements a Chainlink-style interface via: * `latestRoundData()` → returns `(roundId, answer, startedAt, updatedAt, answeredInRound)`\ This enables standard oracle plumbing, staleness checks (via `updatedAt`), and compatibility with existing DeFi integrations. #### NAV-Based Pricing (ERC-4626 Semantics) For direct valuation of shares against underlying assets: * `convertToAssets(uint256 shares)` → pass `1e18` shares to get the underlying asset amount implied by NAV (i.e., “price per token” in asset units). #### Simplified Rate Read For protocols that want a single standardized value: * `getRate()` → returns the current price/rate in **18 decimals**. Together, these functions provide a transparent, reference-driven oracle that lending markets can depend on for consistent collateral valuation and risk management. {% hint style="info" %} The Oracle Price and related verification procedures are provided for reference purposes only. They do not create any legal entitlement to the underlying assets or represent a guaranteed value. Redemption amounts are set at the issuer determined reference and may differ from the oracle reference price. Please review the Legal Documents and Risk Disclaimer. {% endhint %} # Transparency & Analytics Yield Prime is YieldFi’s analytics and transparency layer—built to provide “crystal ball” visibility into any yield-bearing token. Because YieldFi tokens are tokenized representations of vaults, comparing **token vs token** is effectively the same as comparing **fund vs fund**, using institutional metrics such as **APY, TVL, NAV, exposure, liquidity, leverage, and risk (VaR/CVaR)**. Prime also lets you bundle one or more wallets into a **virtual portfolio**, then benchmark that portfolio against any token or index and receive optimization insights to maximize **risk-adjusted yield** without compromising liquidity. ### **Portfolio (Virtual Portfolios)** Prime can aggregate positions across any number of wallets into a single portfolio view. It normalizes holdings by token balances and prices, then produces time-series performance (NAV-style), plus breakdowns for exposure, liquidity, and risk. This turns scattered wallet activity into a single allocator-grade report. ### **Token Analysis & Benchmarking.** Prime decomposes a token (or virtual portfolio) into its underlying assets and compares it against benchmarks or other tokens. It flags **idle assets** (unproductive balances), estimates a **yield profile** and identifies **missed opportunities**, maps **exposure** by asset/protocol/chain, and runs **liquidity analysis** to show what portion can be redeemed over time. Risk is summarized through **VaR/CVaR** to compare downside across managers and strategies. #### **Performance & Core Metrics.** Prime displays **APY** as a monthly performance history chart, tracks **NAV** including drawdown events and historical **recovery periods**, and monitors **TVL** as a proxy for scale, flows, and capacity. #### **Proof of Reserves.** Prime reconciles onchain balances and custody attestations (where applicable) to provide a reserves view. It publishes an update cadence, and clearly states limitations—e.g., external venues, reporting lags, or offchain legs that require attestations. #### **Exposure, Leverage, Liquidity & SLAs.** Exposure is reported token-wise, protocol-wise, and chain-wise. Leverage is computed position-by-position and interpreted through its impact on drawdowns and liquidation risk. Liquidity is expressed as a **liquidity ladder**—what percentage can be redeemed in how many days—under stated assumptions and stress behavior. Prime also surfaces **redemption SLA history**, enabling transparent monitoring of operational performance. {% hint style="info" %} While reference rates or strategy indicators may be published for transparency, these are for informational purposes only and do not create any right, entitlement, or claim to the underlying, nor any guarantee of value, nor do they constitute a defined investment strategy or policy. {% endhint %} # Revenue Share Model Curator • Distributor • YieldFi YieldFi's revenue share model splits **Total Vault Revenue (TVR)** across all parties in proportion to the value they create. Everyone earns a **% of the same revenue pool**, making the economics transparent, scalable, and easy to reconcile. {% hint style="info" %} **Key Highlights** * Single revenue pool: everyone earns from Total Vault Revenue (TVR). * Simple reconciliation: Curator % + Distributor % + YieldFi % = 100% of TVR. * Curator can also be distributor: a curator may distribute the vault directly; in that case, they earn both curator share + distributor share. * NAV integrity: YieldFi always mint and redeem vault tokens at NAV. * Distributor add-on fee is one-time at deposit: optional partner monetisation is collected once at the time of deposit, not as an ongoing AUM fee. {% endhint %} ### Definitions **TVR** = Management Fees + Performance Fees * Both are deducted only from vault yield/profits * If there is no yield, fees are not deducted **Avg. Monthly AUM** * AUM is measured as average AUM for the month **Referral Attribution** * Distributor attribution is tracked using a **referral code**, applied either via SDK or set in backend for large-value deals. ### Revenue Split Overview (One Pie) TVR is split between: * Curator (Strategy Operator) — earns for generating yield and managing risk * Distributor (Distribution Partner) — earns for bringing and retaining capital * YieldFi (Platform) — earns for vault infrastructure, tokenisation, issuance/redemption, monitoring, and reporting ### Curator Revenue Share (Strategy Value) Curators earn a share of TVR based on strategy quality and institutional readiness. #### Curator Tier Table (Share of TVR) | Curator Tier | Typical Profile | Curator Share (% of TVR) | | ----------------- | -------------------------------------------------------- | -----------------------: | | **Emerging** | New strategy or limited track record | **55%** | | **Standard** | Proven operator and stable execution | **63%** | | **Institutional** | Strong track record + institutional-grade reporting/risk | **70%** | ### Distributor Revenue Share (Distribution Value) Distributors earn a share of TVR based on the average monthly AUM they bring and retain. Distributor revenue attribution is tracked using a referral code, which can be applied at the SDK level or set in YieldFi’s backend directly for large-value distribution arrangements. #### Distributor Tier Table (Share of TVR) | Distributor Tier | Avg. Monthly AUM (Partner-Attributed) | Distributor Share (% of TVR) | Partner Add-On Fee Cap (One-Time at Deposit) | Commercial / Support Benefits | | -------------------- | ------------------------------------: | ---------------------------: | --------------------------------------------: | ------------------------------------------------------------------ | | **Tier 1 — Starter** | $0 → $2M | **8%** | **50 bps** | Basic integration, monthly payouts | | **Tier 2 — Growth** | $2M → $10M | **12%** | **75 bps** | Dedicated BD + integration support, early access to vault launches | | **Tier 3 — Scale** | $10M+ | **15%** | **150 bps** *(only if disclosed & compliant)* | Co-marketing, custom reporting, priority support + SLA | #### Distributor Add-On Fee (Optional, One-Time at Deposit) Distributors may optionally charge a one-time add-on fee at the time of deposit. * 100% owned by the distributor * Collected only via SDK deposit flow, or collected directly by the distributor from their user * Governed by the tier-based bps cap in the table above * YieldFi mints at NAV on the net deposited amount after applying any one-time add-on fee ### YieldFi Revenue Share (Platform Value) YieldFi earns the remaining share of TVR after curator and distributor payouts. #### YieldFi Share (Share of TVR) YieldFi Share = 100% − Curator Share − Distributor Share ### Fee Disclosure (Required) Partners must disclose fees clearly in the deposit flow and confirm that fees are taken only from yield/profits and never from user's principal amount. Deposit screen line (recommended): > “Fees are taken only from yield/profits — if the vault doesn’t earn, you don’t pay.” Disclosure format: * YieldFi Management Fee: X% p.a. (deducted from yield only) * YieldFi Performance Fee: Y% of profits (only when profits are generated) * Distributor Add-On Fee (if any): Z bps one-time at deposit (deducted upfront at deposit) * YieldFi mints and redeems at NAV, and deposit tokens are minted on the net deposited amount after applying any one-time distributor add-on fee. # Integration SDK ## YieldFi SDK Documentation Welcome to the official YieldFi SDK documentation! This SDK provides a comprehensive TypeScript/JavaScript interface for interacting with YieldFi services, smart contracts, and blockchain protocols. ### What is YieldFi SDK? The YieldFi SDK is a powerful, type-safe library that enables developers to: * **Authenticate users** via EVM wallet signatures * **Interact with vaults** - query vault information, protocol statistics, and transaction history * **Manage partner transactions** and referrals through the Glassbook API * **Interact with smart contracts** - Manager, YToken, VyToken, YVault contracts * **Access utilities** - contract addresses, whitelisted tokens, and JWT management ### Key Features * **Full TypeScript Support** - Complete type definitions for all APIs * **Wallet Authentication** - Seamless EVM wallet integration * **Role-Based Access** - Automatic filtering based on user roles * **Comprehensive API Coverage** - Vault, Glassbook, Forms, and Curator Handoff APIs * **Smart Contract Types** - Type-safe contract interactions with ethers.js * **Error Handling** - Specialized error classes for different scenarios * **Token Management** - Built-in utilities for JWT and token validation * **Multi-Chain Support** - Works across all YieldFi supported chains ### Quick Example ```typescript import { YieldFiSDK } from "yieldfi-sdk"; // Initialize SDK const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); // Authenticate user const nonce = await sdk.auth.generateNonce({ address: "0x..." }); const signature = await wallet.signMessage(nonce.message); const authResponse = await sdk.auth.login({ address: "0x...", signature, message: nonce.message, }); // Query vaults const vaults = await sdk.vault.getVaults({ chainId: 1 }); const vault = await sdk.vault.getVaultByKey("yusd", 1); // Get transactions (requires authentication) const transactions = await sdk.vault.getTransactions( { chainId: 1, page: 1, pageSize: 20 }, authResponse.accessToken ); ``` ### Documentation Structure This documentation is organized into the following sections: #### Getting Started Learn how to install and configure the SDK, and get your first integration working. #### Authentication Understand how to authenticate users with Ethereum wallets and manage tokens. #### API Reference Complete reference for all available APIs: * Vault API - Query vaults, protocol stats, and transactions * Glassbook API - Partner transactions and referrals * Forms API - Dynamic form handling * Curator Handoff API - Curator workflow management #### Contract Interactions Learn how to interact with YieldFi smart contracts using type-safe interfaces. #### Utilities Access contract addresses, whitelisted tokens, and JWT utilities. #### Error Handling Understand error types and best practices for handling errors. #### Examples & Guides Step-by-step guides and complete examples for common use cases. #### Advanced Topics Deep dive into advanced features like dependency injection and custom configurations. ### Version Current SDK Version: **0.3.0** ### Support * [Full Documentation](https://docs.yield.fi) * [Discord Community](https://discord.gg/yieldfi) * [GitHub Issues](https://github.com/yieldfi/yieldfi-sdk/issues) ### License GPL-3.0 with restrictive distribution clause. See LICENSE for details. *** **Ready to get started?** Head over to the Installation Guide! # FAQ {% stepper %} {% step %} ### General #### What is the YieldFi SDK? The YieldFi SDK is a TypeScript/JavaScript library for interacting with YieldFi services, smart contracts, and blockchain protocols. #### What version of Node.js do I need? Node.js 18.0.0 or higher is required. #### Do I need TypeScript? No, but TypeScript is recommended for the best developer experience. The SDK is written in TypeScript and provides full type definitions. {% endstep %} {% step %} ### Authentication #### How do I authenticate users? Users authenticate using EVM wallet signatures. See the Wallet Authentication Guide. #### Where are tokens stored? The SDK does not store tokens internally. You must manage token storage in your application (localStorage, sessionStorage, HTTP-only cookies, etc.). #### How do I refresh tokens? Use the `refresh()` method with a refresh token. See Token Management. #### What happens when a token expires? When an access token expires, use the refresh token to get a new one. If the refresh token is also expired, the user needs to login again. {% endstep %} {% step %} ### API Usage #### Which APIs require authentication? Most transaction endpoints, Glassbook, Forms, and Curator Handoff APIs require authentication. Most vault query endpoints are public. See API Reference Overview. #### How does role-based filtering work? Regular users automatically see only their own transactions. Admins, moderators, managers, and LPs can see all transactions. See Vault API - Transactions. #### How do I handle pagination? Most list endpoints support pagination with `page` and `pageSize` parameters. See individual API documentation for details. {% endstep %} {% step %} ### Contract Interactions #### How do I get contract ABIs? Contract ABIs are not included in the SDK. You can get them from: * Official YieldFi documentation * Block explorers (Etherscan, Arbiscan, etc.) * Contract source code repositories #### Can I use the SDK without ethers.js? The SDK provides TypeScript types for contract interactions, but you'll need ethers.js (or another compatible library) for actual contract calls. {% endstep %} {% step %} ### Errors #### How do I handle errors? Use try-catch blocks and check error types. See Error Handling. #### What's the difference between AuthenticationError and NetworkError? * `AuthenticationError`: Invalid credentials, expired tokens, malformed JWTs * `NetworkError`: Network issues, timeouts, HTTP errors {% endstep %} {% step %} ### Support #### Where can I get help? * 📖 Documentation * 💬 [Discord Community](https://discord.gg/yieldfi) * 🐛 [GitHub Issues](https://github.com/yieldfi/yieldfi-sdk/issues) #### How do I report a bug? Open an issue on [GitHub](https://github.com/yieldfi/yieldfi-sdk/issues) with: * SDK version * Node.js version * Steps to reproduce * Error messages * Code example (if applicable) {% endstep %} {% endstepper %} # Getting Started {% hint style="info" %} Integrate YieldFi vaults seamlessly via our SDK. If you have any questions or run into issues during setup, feel free to raise them in our [Discord channel](https://discord.gg/hkhXWr9gN9) or reach out directly on Telegram at **SGYield**. {% endhint %} ## Quick Start Get started with the YieldFi SDK in just a few minutes. This guide will walk you through the essential steps to integrate the SDK into your application. ### Step 1: Initialize the SDK First, create an instance of the YieldFi SDK: ```typescript import { YieldFiSDK } from "yieldfi-sdk"; // Initialize SDK (async) const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", partnerId: "your-partner-id", // Optional: for tracking }); ``` ### Step 2: Authenticate a User The SDK uses Ethereum wallet signatures for authentication. Here's the complete flow: ```typescript // 1. Generate a nonce for the user's address const nonce = await sdk.auth.generateNonce({ address: "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb", }); // 2. Sign the message with the user's wallet // Using ethers.js v6 import { ethers } from "ethers"; const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const signature = await signer.signMessage(nonce.message); // Or using MetaMask directly const signature = await window.ethereum.request({ method: "personal_sign", params: [nonce.message, userAddress], }); // 3. Login with the signature const authResponse = await sdk.auth.login({ address: "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb", signature, message: nonce.message, }); // 4. Store tokens (you must manage storage yourself) localStorage.setItem("accessToken", authResponse.accessToken); localStorage.setItem("refreshToken", authResponse.refreshToken); localStorage.setItem("user", JSON.stringify(authResponse.user)); ``` ### Step 3: Query Vaults Now you can query vault information: ```typescript // Get all vaults const vaults = await sdk.vault.getVaults({ chainId: 1, // Ethereum page: 1, pageSize: 20, }); console.log(`Found ${vaults.pagination.total} vaults`); // Get a specific vault by key const vault = await sdk.vault.getVaultByKey("yusd", 1); console.log(`Vault: ${vault.vault.name}`); console.log(`TVL: ${vault.vault.metrics.tvl}`); console.log(`APY: ${vault.vault.metrics.apy7d}%`); ``` ### Step 4: Query Transactions (Authenticated) To query transactions, you need an authenticated user: ```typescript const accessToken = localStorage.getItem("accessToken"); // Get user's transactions const transactions = await sdk.vault.getTransactions( { chainId: 1, type: "deposit", status: "PROCESSED", page: 1, pageSize: 20, }, accessToken ); console.log(`Found ${transactions.pagination.total} transactions`); transactions.data.forEach((tx) => { console.log(`Transaction ${tx.id}: ${tx.type} - ${tx.status}`); }); ``` ### Step 5: Handle Errors Always wrap SDK calls in try-catch blocks: ```typescript import { AuthenticationError, NetworkError, ValidationError, } from "yieldfi-sdk"; try { const vault = await sdk.vault.getVaultByKey("yusd", 1); } catch (error) { if (error instanceof AuthenticationError) { console.error("Authentication failed:", error.message); // Redirect to login } else if (error instanceof NetworkError) { console.error("Network error:", error.message); // Show retry option } else if (error instanceof ValidationError) { console.error("Invalid input:", error.message); // Show validation error to user } else { console.error("Unexpected error:", error); } } ``` ### Complete Example Here's a complete example combining all the steps: ```typescript import { YieldFiSDK } from "yieldfi-sdk"; import { ethers } from "ethers"; async function initializeApp() { // 1. Initialize SDK const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); // 2. Check if user is already authenticated const storedToken = localStorage.getItem("accessToken"); if (storedToken) { try { // Verify token is still valid by making an authenticated request const transactions = await sdk.vault.getTransactions( { chainId: 1, page: 1, pageSize: 1 }, storedToken ); console.log("User is authenticated"); } catch (error) { // Token expired or invalid, clear storage localStorage.removeItem("accessToken"); localStorage.removeItem("refreshToken"); console.log("Session expired, please login again"); } } // 3. Authenticate user (if not already authenticated) if (!storedToken) { const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const address = await signer.getAddress(); const nonce = await sdk.auth.generateNonce({ address }); const signature = await signer.signMessage(nonce.message); const authResponse = await sdk.auth.login({ address, signature, message: nonce.message, }); localStorage.setItem("accessToken", authResponse.accessToken); localStorage.setItem("refreshToken", authResponse.refreshToken); localStorage.setItem("user", JSON.stringify(authResponse.user)); } // 4. Query vaults const vaults = await sdk.vault.getVaults({ chainId: 1 }); console.log(`Available vaults: ${vaults.pagination.total}`); return sdk; } // Initialize the app initializeApp().then((sdk) => { console.log("SDK initialized successfully!"); }); ``` ### Next Steps * Configuration Guide - Learn about advanced configuration options * Authentication Guide - Deep dive into authentication flows * API Reference - Explore all available APIs # Configuration The YieldFi SDK can be configured with various options to customize its behavior. This guide covers all available configuration options. ### Basic Configuration The minimum required configuration is the `gatewayUrl`: ```typescript import { YieldFiSDK } from "yieldfi-sdk"; const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); ``` ### Configuration Options #### `gatewayUrl` (Required) The base URL of the YieldFi gateway service. ```typescript const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", // Production // gatewayUrl: "https://gw-staging.yield.fi", // Staging }); ``` #### `partnerId` (Optional) Partner identifier for tracking and analytics. Used for partner transaction attribution. ```typescript const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", partnerId: "my-partner-id", }); ``` #### `timeout` (Optional) Request timeout in milliseconds. Default: `60000` (60 seconds). ```typescript const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", timeout: 30000, // 30 seconds }); ``` #### `retryAttempts` (Optional) Number of retry attempts for failed requests. Default: `3`. ```typescript const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", retryAttempts: 5, // Retry up to 5 times }); ``` #### `retryDelay` (Optional) Delay between retry attempts in milliseconds. Default: `1000` (1 second). ```typescript const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", retryDelay: 2000, // Wait 2 seconds between retries }); ``` #### `debug` (Optional) Enable debug logging. Default: `false`. ```typescript const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", debug: true, // Enable debug logs }); ``` #### `environment` (Optional) Environment identifier. Options: `'development'`, `'production'`, or `'test'`. Default: `'production'`. ```typescript const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", environment: "development", // or "production" or "test" }); ``` ### Complete Configuration Example Here's an example with all configuration options: ```typescript const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", partnerId: "my-partner-id", timeout: 30000, retryAttempts: 3, retryDelay: 1000, debug: process.env.NODE_ENV === "development", environment: process.env.NODE_ENV === "production" ? "production" : "development", }); ``` ### Environment-Based Configuration A common pattern is to configure the SDK based on your environment: ```typescript const getSDKConfig = () => { const isDevelopment = process.env.NODE_ENV === "development"; const isProduction = process.env.NODE_ENV === "production"; return { gatewayUrl: isDevelopment ? "http://localhost:3000" : isProduction ? "https://gw.yield.fi" : "https://gw-staging.yield.fi", partnerId: process.env.REACT_APP_PARTNER_ID, timeout: 60000, retryAttempts: 3, retryDelay: 1000, debug: isDevelopment, environment: isProduction ? "production" : "development", }; }; const sdk = await YieldFiSDK.create(getSDKConfig()); ``` ### Using the Factory Function Alternatively, you can use the factory function: ```typescript import { createYieldFiSDK } from "yieldfi-sdk"; const sdk = await createYieldFiSDK({ gatewayUrl: "https://gw.yield.fi", partnerId: "my-partner-id", }); ``` ### Configuration Schema The SDK uses Zod for configuration validation. Invalid configurations will throw a `ConfigurationError`: ```typescript import { ConfigurationError } from "yieldfi-sdk"; try { const sdk = await YieldFiSDK.create({ gatewayUrl: "", // Invalid: empty URL }); } catch (error) { if (error instanceof ConfigurationError) { console.error("Invalid configuration:", error.message); console.error("Details:", error.details); } } ``` ### Next Steps * Authentication Guide - Learn about authentication flows * API Reference - Explore available APIs # Installation The YieldFi SDK is available as an npm package and can be installed in your project using npm, yarn, or pnpm. ### Prerequisites * **Node.js**: Version 18.0.0 or higher * **Package Manager**: npm, yarn, or pnpm * **TypeScript**: Recommended (SDK is written in TypeScript) ### Install via npm ```bash npm install yieldfi-sdk ``` ### Install via yarn ```bash yarn add yieldfi-sdk ``` ### Install via pnpm ```bash pnpm add yieldfi-sdk ``` ### Verify Installation After installation, verify that the SDK is properly installed: ```typescript import { YieldFiSDK } from "yieldfi-sdk"; console.log(YieldFiSDK.getVersion()); // "0.3.0" ``` ### TypeScript Support The SDK is written in TypeScript and includes full type definitions. No additional `@types` packages are required. If you're using TypeScript, ensure your `tsconfig.json` includes: ```json { "compilerOptions": { "module": "ESNext", "target": "ES2020", "lib": ["ES2020"], "moduleResolution": "node", "esModuleInterop": true, "skipLibCheck": true } } ``` ### Next Steps * Quick Start Guide - Get up and running in minutes * Configuration - Learn about SDK configuration options # Authentication The YieldFi SDK uses EVM wallet signatures for user authentication. This provides a secure, non-custodial authentication mechanism that doesn't require passwords or API keys. ### Authentication Flow The authentication process follows these steps: 1. **Generate Nonce** - Request a unique message to sign 2. **Sign Message** - User signs the message with their wallet 3. **Login** - Submit signature to receive access and refresh tokens 4. **Store Tokens** - Store tokens in your application (localStorage, sessionStorage, etc.) 5. **Use Tokens** - Include access token in authenticated API requests 6. **Refresh** - Refresh access token when it expires ### Key Concepts #### Wallet-Based Authentication Users authenticate using their Ethereum wallet (MetaMask, WalletConnect, etc.). No passwords or usernames are required. #### Token Management **Important:** The SDK does **not** store tokens internally. You are responsible for: * Storing tokens securely * Retrieving tokens when needed * Refreshing expired tokens * Clearing tokens on logout #### Access Tokens Access tokens are JWT tokens that authenticate API requests. They have a limited lifetime (typically 15 minutes) and must be refreshed periodically. #### Refresh Tokens Refresh tokens are used to obtain new access tokens without requiring the user to sign again. They have a longer lifetime (typically 7 days). ### Quick Example ```typescript import { YieldFiSDK } from "yieldfi-sdk"; import { ethers } from "ethers"; const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); // 1. Generate nonce const nonce = await sdk.auth.generateNonce({ address: "0x...", }); // 2. Sign with wallet const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const signature = await signer.signMessage(nonce.message); // 3. Login const authResponse = await sdk.auth.login({ address: "0x...", signature, message: nonce.message, }); // 4. Store tokens localStorage.setItem("accessToken", authResponse.accessToken); localStorage.setItem("refreshToken", authResponse.refreshToken); ``` ### Next Steps * Wallet Authentication - Detailed guide on wallet authentication * Token Management - How to manage and refresh tokens * User Consent - Managing user consent records # Authentication This guide covers the complete wallet authentication flow using EVM wallets. ### Step-by-Step Authentication #### Step 1: Generate Nonce First, request a nonce (unique message) for the user's address: ```typescript import { YieldFiSDK } from "yieldfi-sdk"; const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); // Generate nonce for user's address const nonce = await sdk.auth.generateNonce({ address: "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb", }); console.log(nonce.message); // "Sign this message to authenticate with YieldFi.\n\nAddress: 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb\nNonce: abc123..." ``` #### Step 2: Sign Message with Wallet Sign the message using the user's wallet. Here are examples for different wallet providers: **Using ethers.js v6** ```typescript import { ethers } from "ethers"; // Connect to MetaMask or other EIP-1193 provider const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const address = await signer.getAddress(); // Sign the message const signature = await signer.signMessage(nonce.message); ``` **Using MetaMask Directly** ```typescript // Request account access const accounts = await window.ethereum.request({ method: "eth_requestAccounts", }); const address = accounts[0]; // Sign the message const signature = await window.ethereum.request({ method: "personal_sign", params: [nonce.message, address], }); ``` **Using WalletConnect** ```typescript import { WalletConnectConnector } from "@web3-react/walletconnect-connector"; // After connecting with WalletConnect const provider = new ethers.providers.Web3Provider(connector.provider); const signer = provider.getSigner(); const signature = await signer.signMessage(nonce.message); ``` #### Step 3: Login with Signature Submit the signature to complete authentication: ```typescript const authResponse = await sdk.auth.login({ address: address, signature: signature, message: nonce.message, }); console.log(authResponse.accessToken); // JWT access token console.log(authResponse.refreshToken); // Refresh token console.log(authResponse.user); // User information ``` #### Step 4: Store Tokens Store the tokens securely in your application: ```typescript // Browser localStorage (for web apps) localStorage.setItem("accessToken", authResponse.accessToken); localStorage.setItem("refreshToken", authResponse.refreshToken); localStorage.setItem("user", JSON.stringify(authResponse.user)); // Or sessionStorage (cleared on tab close) sessionStorage.setItem("accessToken", authResponse.accessToken); // Or secure HTTP-only cookies (for server-side apps) // Set via your backend API ``` ### Complete Example Here's a complete React component example: ```typescript import { useState } from "react"; import { YieldFiSDK } from "yieldfi-sdk"; import { ethers } from "ethers"; function LoginButton() { const [loading, setLoading] = useState(false); const [error, setError] = useState(null); const handleLogin = async () => { try { setLoading(true); setError(null); // Initialize SDK const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); // Connect to wallet const provider = new ethers.BrowserProvider(window.ethereum); await provider.send("eth_requestAccounts", []); const signer = await provider.getSigner(); const address = await signer.getAddress(); // Generate nonce const nonce = await sdk.auth.generateNonce({ address }); // Sign message const signature = await signer.signMessage(nonce.message); // Login const authResponse = await sdk.auth.login({ address, signature, message: nonce.message, }); // Store tokens localStorage.setItem("accessToken", authResponse.accessToken); localStorage.setItem("refreshToken", authResponse.refreshToken); localStorage.setItem("user", JSON.stringify(authResponse.user)); console.log("Login successful!", authResponse.user); } catch (err: any) { setError(err.message || "Login failed"); console.error("Login error:", err); } finally { setLoading(false); } }; return (
{error &&

{error}

}
); } ``` ### Error Handling Handle common authentication errors: ```typescript import { AuthenticationError, ValidationError, NetworkError, } from "yieldfi-sdk"; try { const authResponse = await sdk.auth.login({ address, signature, message: nonce.message, }); } catch (error) { if (error instanceof AuthenticationError) { // Invalid signature, expired nonce, etc. console.error("Authentication failed:", error.message); } else if (error instanceof ValidationError) { // Invalid input (missing address, signature, etc.) console.error("Validation error:", error.message); } else if (error instanceof NetworkError) { // Network issues console.error("Network error:", error.message); } } ``` ### Security Best Practices 1. **Always verify the message** - Users should verify the message they're signing matches what they expect 2. **Use HTTPS** - Always use HTTPS in production to protect tokens 3. **Secure storage** - Consider using secure storage mechanisms (HTTP-only cookies for server-side apps) 4. **Token expiration** - Implement token refresh logic (see Token Management) 5. **Logout on errors** - Clear tokens if authentication fails ### Next Steps * Token Management - Learn how to refresh and manage tokens * User Consent - Manage user consent records # Token Management This guide covers how to manage authentication tokens, including storage, refresh, and expiration handling. ### Token Types #### Access Token * **Purpose**: Authenticate API requests * **Lifetime**: Typically 15 minutes * **Format**: JWT (JSON Web Token) * **Usage**: Include in `Authorization` header for authenticated requests #### Refresh Token * **Purpose**: Obtain new access tokens without re-authentication * **Lifetime**: Typically 7 days * **Format**: Opaque token string * **Usage**: Exchange for new access token when current one expires ### Storing Tokens The SDK does **not** store tokens internally. You must manage token storage in your application. #### Browser Storage Options **localStorage (Persistent)** ```typescript // Store tokens localStorage.setItem("accessToken", authResponse.accessToken); localStorage.setItem("refreshToken", authResponse.refreshToken); // Retrieve tokens const accessToken = localStorage.getItem("accessToken"); const refreshToken = localStorage.getItem("refreshToken"); // Clear tokens localStorage.removeItem("accessToken"); localStorage.removeItem("refreshToken"); ``` **Pros**: Persists across browser sessions\ **Cons**: Accessible to JavaScript (XSS risk) **sessionStorage (Session-only)** ```typescript // Store tokens sessionStorage.setItem("accessToken", authResponse.accessToken); // Retrieve tokens const accessToken = sessionStorage.getItem("accessToken"); ``` **Pros**: Cleared when tab closes\ **Cons**: Still accessible to JavaScript **HTTP-Only Cookies (Recommended for Server-Side)** For server-side applications, use HTTP-only cookies set by your backend: ```typescript // Backend sets cookies after login // Frontend automatically includes cookies in requests // Cookies are not accessible to JavaScript (XSS protection) ``` ### Checking Token Expiration Use JWT utilities to check token expiration: ```typescript import { isTokenExpired, getTimeUntilExpiration } from "yieldfi-sdk"; const accessToken = localStorage.getItem("accessToken"); // Check if token is expired if (isTokenExpired(accessToken)) { console.log("Token is expired, need to refresh"); } // Check with buffer (refresh if expiring in 5 minutes) if (isTokenExpired(accessToken, 300)) { console.log("Token expiring soon, refreshing proactively"); } // Get time until expiration const secondsLeft = getTimeUntilExpiration(accessToken); console.log(`Token expires in ${secondsLeft} seconds`); ``` ### Refreshing Tokens When an access token expires, use the refresh token to get a new one: ```typescript import { YieldFiSDK } from "yieldfi-sdk"; const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const refreshToken = localStorage.getItem("refreshToken"); try { // Refresh access token const newTokens = await sdk.auth.refresh({ refreshToken: refreshToken, }); // Update stored tokens localStorage.setItem("accessToken", newTokens.accessToken); localStorage.setItem("refreshToken", newTokens.refreshToken); } catch (error) { // Refresh token expired or invalid // Redirect to login localStorage.removeItem("accessToken"); localStorage.removeItem("refreshToken"); // Redirect to login page } ``` #### Alternative: Refresh with API Key You can also refresh using an API key: ```typescript const newTokens = await sdk.auth.refresh({ apiKey: "yfi_...", }); ``` ### Automatic Token Refresh Implement automatic token refresh to improve user experience: ```typescript import { isTokenExpired } from "yieldfi-sdk"; async function getValidAccessToken(): Promise { let accessToken = localStorage.getItem("accessToken"); const refreshToken = localStorage.getItem("refreshToken"); // Check if token is expired or expiring soon (5 minute buffer) if (!accessToken || isTokenExpired(accessToken, 300)) { if (!refreshToken) { // No refresh token, user needs to login again return null; } try { // Refresh the token const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const newTokens = await sdk.auth.refresh({ refreshToken }); accessToken = newTokens.accessToken; // Update stored tokens localStorage.setItem("accessToken", newTokens.accessToken); localStorage.setItem("refreshToken", newTokens.refreshToken); } catch (error) { // Refresh failed, clear tokens localStorage.removeItem("accessToken"); localStorage.removeItem("refreshToken"); return null; } } return accessToken; } // Use in API calls async function makeAuthenticatedRequest() { const accessToken = await getValidAccessToken(); if (!accessToken) { // Redirect to login return; } // Make API call with valid token const transactions = await sdk.vault.getTransactions( { chainId: 1, page: 1, pageSize: 20 }, accessToken ); } ``` ### Token Refresh Interceptor For applications using HTTP clients, implement a token refresh interceptor: ```typescript import axios from "axios"; import { YieldFiSDK } from "yieldfi-sdk"; const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); // Create axios instance const apiClient = axios.create({ baseURL: "https://gw.yield.fi", }); // Request interceptor: Add access token apiClient.interceptors.request.use(async (config) => { const accessToken = await getValidAccessToken(); if (accessToken) { config.headers.Authorization = `Bearer ${accessToken}`; } return config; }); // Response interceptor: Handle 401 and refresh token apiClient.interceptors.response.use( (response) => response, async (error) => { const originalRequest = error.config; // If 401 and haven't retried yet if (error.response?.status === 401 && !originalRequest._retry) { originalRequest._retry = true; const refreshToken = localStorage.getItem("refreshToken"); if (refreshToken) { try { const newTokens = await sdk.auth.refresh({ refreshToken }); localStorage.setItem("accessToken", newTokens.accessToken); localStorage.setItem("refreshToken", newTokens.refreshToken); // Retry original request with new token originalRequest.headers.Authorization = `Bearer ${newTokens.accessToken}`; return apiClient(originalRequest); } catch (refreshError) { // Refresh failed, redirect to login localStorage.removeItem("accessToken"); localStorage.removeItem("refreshToken"); window.location.href = "/login"; return Promise.reject(refreshError); } } } return Promise.reject(error); } ); ``` ### Logout To logout, revoke tokens on the server and clear local storage: ```typescript import { YieldFiSDK } from "yieldfi-sdk"; const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const accessToken = localStorage.getItem("accessToken"); try { // Revoke tokens on server await sdk.auth.logout(accessToken); } catch (error) { // Even if logout fails, clear local tokens console.error("Logout error:", error); } finally { // Always clear local storage localStorage.removeItem("accessToken"); localStorage.removeItem("refreshToken"); localStorage.removeItem("user"); } ``` ### Security Considerations 1. **Never expose refresh tokens** - Keep them server-side if possible 2. **Use HTTPS** - Always use HTTPS to protect tokens in transit 3. **Implement CSRF protection** - Use CSRF tokens for state-changing operations 4. **Token rotation** - Consider rotating refresh tokens on each refresh 5. **Monitor token usage** - Log and monitor token refresh patterns for anomalies ### Next Steps * User Consent - Manage user consent records * API Reference - Learn about authenticated APIs # Consent The YieldFi SDK provides comprehensive APIs for managing user consent records. Consent records are immutable for audit compliance - once recorded, they cannot be deleted or revoked. ### Consent Types The SDK supports the following consent types: * `TERMS_OF_SERVICE` - User acceptance of terms of service (required) * `PRIVACY_POLICY` - User acceptance of privacy policy (required) * `MARKETING` - User consent for marketing communications (optional) * `ANALYTICS` - User consent for analytics tracking (optional) * `COOKIES` - User consent for cookie usage (optional) ### Recording Consent Record user consent when they accept terms, policies, or opt-in to features: ```typescript import { YieldFiSDK, ConsentType } from "yieldfi-sdk"; const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const accessToken = localStorage.getItem("accessToken"); // Record terms of service acceptance const consent = await sdk.auth.recordConsent(accessToken, { consentType: ConsentType.TERMS_OF_SERVICE, version: "1.0", granted: true, metadata: { documentHash: "0xabc123...", sourceUrl: "https://yield.fi/terms", }, }); console.log(`Consent recorded: ${consent.consent.id}`); ``` ### Getting Consent Records #### Get Specific Consent Get a specific consent record by type and optional version: ```typescript // Get latest consent for a type const termsConsent = await sdk.auth.getConsent( accessToken, ConsentType.TERMS_OF_SERVICE ); // Get specific version const termsConsentV1 = await sdk.auth.getConsent( accessToken, ConsentType.TERMS_OF_SERVICE, "1.0" ); ``` #### Get All User Consents Get the complete audit trail of all consent records: ```typescript const allConsents = await sdk.auth.getUserConsents(accessToken); console.log(`User has ${allConsents.count} consent records`); allConsents.data.forEach((consent) => { console.log(`${consent.consentType} v${consent.version}: ${consent.granted ? "Granted" : "Denied"}`); console.log(`Recorded at: ${consent.recordedAt}`); }); ``` #### Get Consent Status Summary Get the latest status for each consent type: ```typescript const statuses = await sdk.auth.getConsentStatuses(accessToken); // Check if user has consented to marketing const marketingStatus = statuses.data.find( (s) => s.consentType === ConsentType.MARKETING ); if (marketingStatus?.granted) { // User has consented, can send marketing emails sendMarketingEmail(); } else { // Show consent banner showConsentBanner(); } ``` ### Complete Example: Consent Flow Here's a complete example of implementing a consent flow: ```typescript import { YieldFiSDK, ConsentType } from "yieldfi-sdk"; import { useState, useEffect } from "react"; function ConsentManager() { const [consentStatuses, setConsentStatuses] = useState(null); const [loading, setLoading] = useState(true); useEffect(() => { loadConsentStatuses(); }, []); const loadConsentStatuses = async () => { try { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const accessToken = localStorage.getItem("accessToken"); const statuses = await sdk.auth.getConsentStatuses(accessToken); setConsentStatuses(statuses); } catch (error) { console.error("Failed to load consent statuses:", error); } finally { setLoading(false); } }; const recordConsent = async ( consentType: ConsentType, granted: boolean ) => { try { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const accessToken = localStorage.getItem("accessToken"); await sdk.auth.recordConsent(accessToken, { consentType, version: "1.0", granted, metadata: { sourceUrl: window.location.href, }, }); // Reload consent statuses await loadConsentStatuses(); } catch (error) { console.error("Failed to record consent:", error); } }; if (loading) { return
Loading consent statuses...
; } const termsStatus = consentStatuses?.data.find( (s: any) => s.consentType === ConsentType.TERMS_OF_SERVICE ); const marketingStatus = consentStatuses?.data.find( (s: any) => s.consentType === ConsentType.MARKETING ); return (

Consent Management

{/* Terms of Service */} {!termsStatus?.granted && (

Please accept our Terms of Service

)} {/* Marketing Consent */} {!marketingStatus && (

Would you like to receive marketing communications?

)} {/* Show current statuses */}

Current Consent Status

{consentStatuses?.data.map((status: any) => (
{status.consentType}:{" "} {status.granted ? "✅ Granted" : "❌ Denied"} (v{status.version})
))}
); } ``` ### Important Notes 1. **Immutability**: Consent records cannot be deleted or revoked once created. This ensures audit compliance. 2. **Versioning**: Each consent type can have multiple versions (e.g., Terms v1.0, v2.0). Always record consent for the current version. 3. **Audit Trail**: All consent records include: * Timestamp * IP address * User agent * Metadata (document hash, source URL, etc.) 4. **Authentication Required**: All consent APIs require a valid access token. 5. **Required Consents**: Terms of Service and Privacy Policy are typically required before users can use the platform. ### Next Steps * API Reference - Explore all available APIs * Examples - See complete examples # API Reference The YieldFi SDK provides several API modules for interacting with different YieldFi services. This section covers all available APIs. ### Available APIs #### Vault API Query vault information, protocol statistics, whitelisted assets, and transaction history. **Key Features:** * Protocol statistics and metrics * Vault listings and details * Whitelisted asset management * Transaction history with role-based filtering #### Glassbook API Manage partner transactions (PTX) and referrals. **Key Features:** * Create and query partner transactions * Referral code management * Referral statistics and tracking ### Authentication Most APIs require authentication. See the Authentication Guide for details. **Public APIs** (no authentication required): * `sdk.vault.getProtocolStats()` * `sdk.vault.getStrategies()` * `sdk.vault.getVaults()` * `sdk.vault.getVaultByKey()` * `sdk.vault.getVaultBySymbol()` * `sdk.vault.getVaultDetails()` * `sdk.vault.getVaultFaqs()` * `sdk.vault.getWhitelistedAssets()` * `sdk.vault.getWhitelistedAsset()` * `sdk.vault.checkAssetWhitelisted()` **Protected APIs** (authentication required): * All transaction endpoints * All Glassbook endpoints * All Forms endpoints * All Curator Handoff endpoints * Private vault access * Admin operations (whitelist management, etc.) ### Common Patterns #### Pagination Many APIs support pagination: ```typescript const result = await sdk.vault.getVaults({ page: 1, pageSize: 20, }); console.log(`Page ${result.pagination.page} of ${result.pagination.totalPages}`); console.log(`Total: ${result.pagination.total}`); ``` #### Filtering APIs support various filters: ```typescript const transactions = await sdk.vault.getTransactions( { chainId: 1, type: "deposit", status: "PROCESSED", startDate: "2024-01-01T00:00:00.000Z", endDate: "2024-01-31T23:59:59.999Z", }, accessToken ); ``` #### Error Handling Always handle errors: ```typescript import { AuthenticationError, NetworkError, ValidationError, } from "yieldfi-sdk"; try { const vault = await sdk.vault.getVaultByKey("yusd", 1); } catch (error) { if (error instanceof AuthenticationError) { // Handle auth errors } else if (error instanceof NetworkError) { // Handle network errors } else if (error instanceof ValidationError) { // Handle validation errors } } ``` ### Next Steps * Vault API - Query vaults and transactions * Glassbook API - Partner transactions and referrals # Vault API The Vault API provides access to vault information, protocol statistics, whitelisted assets, and transaction history. Most endpoints are public, but some require authentication for private vaults and admin operations. ### Protocol Statistics #### Get Protocol Stats Get protocol-level statistics including total TVL, max APY, and user counts. ```typescript // Public endpoint - no authentication required const stats = await sdk.vault.getProtocolStats(); console.log(`Total TVL: ${stats.stats.totalTvl}`); console.log(`Max APY: ${stats.stats.maxApy}`); console.log(`Total Users: ${stats.stats.totalUsers}`); console.log(`Total Fund Managers: ${stats.stats.totalFundManagers}`); console.log(`YPO: ${stats.stats.ypo}`); ``` #### Get Strategies Get distinct strategy types available across all vaults. ```typescript // Public endpoint const strategies = await sdk.vault.getStrategies(); console.log(`Available strategies: ${strategies.strategies.join(", ")}`); // Example output: ["DeFi", "Trading", "Lending", ...] ``` #### Refresh Protocol Stats Refresh protocol statistics (requires authentication). ```typescript const accessToken = localStorage.getItem("accessToken"); const refreshedStats = await sdk.vault.refreshProtocolStats(accessToken); ``` ### Vault Information #### Get All Vaults Get a paginated list of vaults with optional filters. ```typescript // Public endpoint const vaults = await sdk.vault.getVaults({ chainId: 1, // Ethereum status: "active", // Optional: 'active', 'inactive', etc. strategy: "DeFi", // Optional: filter by strategy page: 1, pageSize: 20, }); console.log(`Found ${vaults.pagination.total} vaults`); vaults.data.forEach((vault) => { console.log(`${vault.vaultKey}: ${vault.name} - TVL: ${vault.metrics.tvl}`); }); ``` **Filter Options:** * `chainId` - Filter by blockchain chain ID * `status` - Filter by vault status * `strategy` - Filter by strategy type * `page` - Page number (default: 1) * `pageSize` - Items per page (default: 20, max: 100) #### Get Vault by Key Get a specific vault by its key and chain ID. ```typescript // Public endpoint const vault = await sdk.vault.getVaultByKey("yusd", 1); // Ethereum console.log(`Vault: ${vault.vault.name}`); console.log(`Symbol: ${vault.vault.symbol}`); console.log(`TVL: ${vault.vault.metrics.tvl}`); console.log(`APY (7d): ${vault.vault.metrics.apy7d}%`); console.log(`Description: ${vault.vault.description}`); ``` #### Get Vault by Symbol Get a vault by its symbol and chain ID. ```typescript // Public endpoint const vault = await sdk.vault.getVaultBySymbol("yUSD", 1); console.log(`Vault Key: ${vault.vault.vaultKey}`); ``` #### Get Private Vault Get a private vault (requires authentication). ```typescript const accessToken = localStorage.getItem("accessToken"); const privateVault = await sdk.vault.getPrivateVaultByKey( "private-vault-key", "0x1234567890123456789012345678901234567890", // User address "user", // User role 1, // Chain ID accessToken ); ``` #### Get Vault Details Get detailed vault information including fact sheet data. ```typescript // Public endpoint const details = await sdk.vault.getVaultDetails("yusd", 1); console.log(`Manager: ${details.vault.manager}`); console.log(`Partner: ${details.vault.partner?.name}`); console.log(`Rewards: ${details.vault.rewards?.length} reward tokens`); ``` #### Get Vault FAQs Get frequently asked questions for a vault. ```typescript // Public endpoint const faqs = await sdk.vault.getVaultFaqs("yusd", 1); faqs.faqs.forEach((faq) => { console.log(`Q: ${faq.question}`); console.log(`A: ${faq.answer}`); }); ``` ### Whitelisted Assets #### Get Whitelisted Assets Get all whitelisted assets for a vault. ```typescript // Public endpoint const assets = await sdk.vault.getWhitelistedAssets("yusd", 1, false); console.log(`Vault has ${assets.assets.length} whitelisted assets`); assets.assets.forEach((asset) => { console.log(`${asset.symbol}: ${asset.address}`); console.log(`Deposit Enabled: ${asset.depositRedeemEnabled & 1 === 1}`); console.log(`Redeem Enabled: ${asset.depositRedeemEnabled & 2 === 2}`); }); ``` **Parameters:** * `vaultKey` - Vault key identifier * `chainId` - Blockchain chain ID * `includeInactive` - Include inactive assets (default: false) #### Get Whitelisted Asset Get a specific whitelisted asset. ```typescript // Public endpoint const asset = await sdk.vault.getWhitelistedAsset( "yusd", "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // USDC address 1 // Ethereum ); console.log(`Asset: ${asset.asset.symbol} (${asset.asset.name})`); console.log(`Decimals: ${asset.asset.decimals}`); ``` #### Check Asset Whitelisted Check if an asset is whitelisted for a vault. ```typescript // Public endpoint const checkResult = await sdk.vault.checkAssetWhitelisted( "yusd", "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", 1 ); if (checkResult.isWhitelisted) { console.log("Asset is whitelisted"); console.log(`Deposit Enabled: ${checkResult.depositEnabled}`); console.log(`Redeem Enabled: ${checkResult.redeemEnabled}`); } else { console.log("Asset is not whitelisted"); } ``` #### Add Whitelisted Asset Add a new whitelisted asset (requires admin authentication). ```typescript const accessToken = localStorage.getItem("accessToken"); const newAsset = await sdk.vault.addWhitelistedAsset( accessToken, "yusd", { assetAddress: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", assetSymbol: "USDC", assetName: "USD Coin", assetDecimals: 6, depositRedeemEnabled: 2, // 0 = none, 1 = deposit, 2 = both }, 1 // Chain ID ); ``` #### Remove Whitelisted Asset Remove a whitelisted asset (requires admin authentication). ```typescript const accessToken = localStorage.getItem("accessToken"); await sdk.vault.removeWhitelistedAsset( accessToken, "yusd", "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", 1 ); ``` ### Transactions All transaction endpoints require authentication and implement role-based filtering: * **Regular users**: Automatically filtered to show only their own transactions * **Admins/Moderators/Managers/LPs**: Can see all transactions #### Get Transactions Get transactions with pagination and filters. ```typescript const accessToken = localStorage.getItem("accessToken"); const transactions = await sdk.vault.getTransactions( { chainId: 1, vaultAddress: "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB", type: "deposit", // 'deposit' or 'redemption' status: "PROCESSED", // 'PENDING', 'PROCESSED', 'CANCELLED', 'NO-RETRY', 'FAILED' page: 1, pageSize: 20, startDate: "2024-01-01T00:00:00.000Z", endDate: "2024-01-31T23:59:59.999Z", // Admins can also filter by: // userAddress: "0x...", // receiverAddress: "0x...", // assetAddress: "0x...", }, accessToken ); console.log(`Found ${transactions.pagination.total} transactions`); console.log(`Page ${transactions.pagination.page} of ${transactions.pagination.totalPages}`); transactions.data.forEach((tx) => { console.log(`Transaction ${tx.id}:`); console.log(` Type: ${tx.type}`); console.log(` Status: ${tx.status}`); console.log(` Amount: ${tx.amount}`); console.log(` User: ${tx.userAddress}`); console.log(` Timestamp: ${tx.timestamp}`); }); ``` **Filter Parameters:** * `chainId` - Filter by blockchain chain ID * `vaultAddress` - Filter by vault address * `userAddress` - Filter by user address (admins only - regular users are automatically filtered) * `receiverAddress` - Filter by receiver address * `assetAddress` - Filter by asset address * `type` - Filter by transaction type: `'deposit'` or `'redemption'` * `status` - Filter by status: `'PENDING'`, `'PROCESSED'`, `'CANCELLED'`, `'NO-RETRY'`, or `'FAILED'` * `startDate` - Filter by start date (ISO 8601 format) * `endDate` - Filter by end date (ISO 8601 format) * `page` - Page number (default: 1) * `pageSize` - Items per page (default: 20, max: 100) #### Get Transaction by ID Get a specific transaction by its ID. ```typescript const accessToken = localStorage.getItem("accessToken"); // Regular users: can only access their own transactions // Admins: can access any transaction const transaction = await sdk.vault.getTransactionById(1, accessToken); console.log(`Transaction ${transaction.transaction.id}:`); console.log(` Type: ${transaction.transaction.type}`); console.log(` Status: ${transaction.transaction.status}`); console.log(` Hash: ${transaction.transaction.txnHash}`); ``` #### Get Transaction by Hash Get a transaction by its blockchain transaction hash. ```typescript const accessToken = localStorage.getItem("accessToken"); const transaction = await sdk.vault.getTransactionByHash( "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef", 1, // Chain ID accessToken ); console.log(`Transaction found: ${transaction.transaction.id}`); ``` #### Get Transaction Filter Options Get available filter options for transactions. ```typescript const accessToken = localStorage.getItem("accessToken"); const filterOptions = await sdk.vault.getTransactionFilterOptions(accessToken); console.log("Available chain IDs:", filterOptions.filters.chainIds); console.log("Available statuses:", filterOptions.filters.statuses); console.log("Available types:", filterOptions.filters.types); ``` ### Complete Example Here's a complete example combining multiple Vault API calls: ```typescript import { YieldFiSDK } from "yieldfi-sdk"; async function vaultDashboard() { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); // 1. Get protocol statistics const stats = await sdk.vault.getProtocolStats(); console.log(`Protocol TVL: $${stats.stats.totalTvl}`); // 2. Get available strategies const strategies = await sdk.vault.getStrategies(); console.log(`Strategies: ${strategies.strategies.join(", ")}`); // 3. Get all vaults const vaults = await sdk.vault.getVaults({ chainId: 1, page: 1, pageSize: 10, }); // 4. Get details for each vault for (const vaultListItem of vaults.data) { const vault = await sdk.vault.getVaultByKey(vaultListItem.vaultKey, 1); console.log(`\n${vault.vault.name}:`); console.log(` TVL: $${vault.vault.metrics.tvl}`); console.log(` APY: ${vault.vault.metrics.apy7d}%`); // 5. Get whitelisted assets const assets = await sdk.vault.getWhitelistedAssets( vaultListItem.vaultKey, 1, false ); console.log(` Whitelisted Assets: ${assets.assets.length}`); } // 6. Get user transactions (if authenticated) const accessToken = localStorage.getItem("accessToken"); if (accessToken) { const transactions = await sdk.vault.getTransactions( { chainId: 1, page: 1, pageSize: 10, }, accessToken ); console.log(`\nYour Transactions: ${transactions.pagination.total}`); } } vaultDashboard(); ``` ### Next Steps * Glassbook API - Partner transactions and referrals * Examples - More vault operation examples # Glassbook API The Glassbook API provides endpoints for managing partner transactions (PTX) and referrals. All endpoints require authentication. ### Partner Transactions (PTX) #### Create Partner Transaction Create a new partner transaction record. ```typescript const accessToken = localStorage.getItem("accessToken"); const ptx = await sdk.glassbook.createPartnerTransaction(accessToken, { transactionHash: "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef", chainId: "1", // Ethereum }); console.log(`PTX created: ${ptx.ptx.id}`); console.log(`Status: ${ptx.ptx.status}`); ``` #### Get Partner Transactions Get all partner transactions with pagination and filters. ```typescript const accessToken = localStorage.getItem("accessToken"); const transactions = await sdk.glassbook.getPartnerTransactions(accessToken, { page: 1, pageSize: 10, chainId: "1", // Optional filter }); console.log(`Found ${transactions.pagination.total} transactions`); transactions.data.forEach((tx) => { console.log(`PTX ${tx.id}: ${tx.transactionHash} - ${tx.status}`); }); ``` #### Get My Partner Transactions Get the authenticated user's partner transactions. ```typescript const accessToken = localStorage.getItem("accessToken"); const myTransactions = await sdk.glassbook.getMyPartnerTransactions(accessToken); console.log(`You have ${myTransactions.pagination.total} partner transactions`); ``` #### Get Partner Transaction by ID Get a specific partner transaction by its ID. ```typescript const accessToken = localStorage.getItem("accessToken"); const transaction = await sdk.glassbook.getPartnerTransactionById(accessToken, 123); console.log(`Transaction: ${transaction.ptx.transactionHash}`); console.log(`Status: ${transaction.ptx.status}`); ``` ### Referrals #### Get My Referral Get the authenticated user's referral information. ```typescript const accessToken = localStorage.getItem("accessToken"); const myReferral = await sdk.glassbook.getMyReferral(accessToken); console.log(`Your referral code: ${myReferral.referral.code}`); console.log(`Referred by: ${myReferral.referral.referredBy || "None"}`); ``` #### Get My Referral Stats Get referral statistics for the authenticated user. ```typescript const accessToken = localStorage.getItem("accessToken"); const stats = await sdk.glassbook.getMyReferralStats(accessToken); console.log(`Total referred: ${stats.stats.totalReferred}`); console.log(`Active referrals: ${stats.stats.activeReferred}`); ``` #### Get My Referred Addresses Get addresses that were referred by the authenticated user. ```typescript const accessToken = localStorage.getItem("accessToken"); const referred = await sdk.glassbook.getMyReferredAddresses(accessToken, 1, 10); console.log(`You referred ${referred.pagination.total} addresses`); referred.data.forEach((address) => { console.log(` ${address.address} - Joined: ${address.joinedAt}`); }); ``` #### Create Referral Create a new referral with a custom code. ```typescript const accessToken = localStorage.getItem("accessToken"); const referral = await sdk.glassbook.createReferral(accessToken, { code: "MYCODE123", referredBy: "REFERRER_CODE", // Optional: if user was referred }); console.log(`Referral created: ${referral.referral.code}`); ``` #### Check Referral Code Availability Check if a referral code is available. ```typescript const accessToken = localStorage.getItem("accessToken"); const availability = await sdk.glassbook.checkReferralCodeAvailability( accessToken, "MYCODE123" ); if (availability.available) { console.log("Code is available!"); } else { console.log("Code is already taken"); } ``` #### Get Referral by Code Get referral information by code. ```typescript const accessToken = localStorage.getItem("accessToken"); const referral = await sdk.glassbook.getReferralByCode(accessToken, "MYCODE123"); console.log(`Referral code: ${referral.referral.code}`); console.log(`Owner: ${referral.referral.address}`); ``` #### Get Referral by Address Get referral information by address. ```typescript const accessToken = localStorage.getItem("accessToken"); const referral = await sdk.glassbook.getReferralByAddress( accessToken, "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb" ); console.log(`Referral code: ${referral.referral.code}`); ``` ### Complete Example ```typescript import { YieldFiSDK } from "yieldfi-sdk"; async function referralFlow() { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const accessToken = localStorage.getItem("accessToken"); // 1. Get or create referral code let myReferral; try { myReferral = await sdk.glassbook.getMyReferral(accessToken); console.log(`Your existing code: ${myReferral.referral.code}`); } catch (error) { // No referral exists, create one const code = `USER${Date.now()}`; const available = await sdk.glassbook.checkReferralCodeAvailability( accessToken, code ); if (available.available) { myReferral = await sdk.glassbook.createReferral(accessToken, { code, }); console.log(`Created new code: ${myReferral.referral.code}`); } } // 2. Get referral stats const stats = await sdk.glassbook.getMyReferralStats(accessToken); console.log(`Total referred: ${stats.stats.totalReferred}`); // 3. Get referred addresses const referred = await sdk.glassbook.getMyReferredAddresses(accessToken, 1, 10); console.log(`Referred addresses: ${referred.data.length}`); // 4. Create partner transaction const ptx = await sdk.glassbook.createPartnerTransaction(accessToken, { transactionHash: "0x...", chainId: "1", }); console.log(`PTX created: ${ptx.ptx.id}`); } referralFlow(); ``` ### Next Steps * Forms API - Dynamic form handling * Examples - More examples # Contracts ## v3 Contracts The YieldFi SDK provides TypeScript types for type-safe smart contract interactions with YieldFi v3 contracts using ethers.js. This section covers how to interact with YieldFi v3 smart contracts. ### Available V3 Contracts * **Manager V3** - Core protocol manager contract for deposits and withdrawals * **Vault** - ERC-4626 vault token contracts (represents vault shares) ### V3 Contract ABIs V3 contract ABIs are included in the SDK package: ```typescript import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; ``` ### Quick Start #### Using Wagmi ```typescript import { connectManagerV3, connectVault, getContractAddresses, Chain, } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useAccount, useWalletClient } from "wagmi"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; function ContractExample() { const { address } = useAccount(); const { data: walletClient } = useWalletClient(); const connectContracts = async () => { if (!walletClient || !address) { throw new Error("Wallet not connected"); } // Setup provider and signer from wagmi const provider = new ethers.BrowserProvider(walletClient); const signer = await provider.getSigner(); // Get contract addresses const contracts = getContractAddresses(Chain.ETHEREUM); // Connect to Manager V3 const managerV3 = connectManagerV3( contracts.manager, ManagerV3ABI, signer ); // Connect to a specific Vault (get address from Vault API) const vaultAddress = "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB"; const vault = connectVault(vaultAddress, VaultABI, provider); return { managerV3, vault }; }; } ``` #### Using Browser Provider ```typescript import { connectManagerV3, connectVault, getContractAddresses, Chain, } from "yieldfi-sdk"; import { ethers } from "ethers"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; // Connect to browser wallet if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); // Get contract addresses const contracts = getContractAddresses(Chain.ETHEREUM); // Connect to Manager V3 const managerV3 = connectManagerV3( contracts.manager, ManagerV3ABI, signer ); // Connect to a specific Vault (get address from Vault API) const vaultAddress = "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB"; const vault = connectVault(vaultAddress, VaultABI, provider); ``` ### V3 Contract Architecture #### Manager V3 The Manager V3 contract handles: * **Deposits**: Users deposit assets, receive vault shares * **Redemption Requests**: Users request redemption, shares are locked * **Redemption Processing**: Operators process redemptions from queue * **Queue Management**: Track and manage redemption queue #### Vault Contract (ERC-4626) The Vault contract is an ERC-4626 compliant vault token: * Represents shares in a vault * Supports standard ERC-4626 operations * Shares can be locked for redemption requests * Provides conversion between shares and assets ### Next Steps * Manager Contract - Manager V3 contract operations * Vault Contract - Vault contract operations (ERC-4626) * Examples - Complete integration examples # Vault (V3) The Vault contract is an ERC-4626 compliant vault token contract that represents shares in a YieldFi v3 vault. ### Connecting to Vault #### Using Wagmi ```typescript import { connectVault } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useAccount, useWalletClient } from "wagmi"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; function VaultExample() { const { address } = useAccount(); const { data: walletClient } = useWalletClient(); const connectVaultContract = async (vaultAddress: string) => { if (!walletClient) { throw new Error("Wallet not connected"); } const provider = new ethers.BrowserProvider(walletClient); const signer = await provider.getSigner(); // For read-only operations, use provider const vaultReadOnly = connectVault(vaultAddress, VaultABI, provider); // For write operations, use signer const vault = connectVault(vaultAddress, VaultABI, signer); return { vault, vaultReadOnly }; }; } ``` #### Using Browser Provider ```typescript import { connectVault } from "yieldfi-sdk"; import { ethers } from "ethers"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; // For read-only operations if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const vaultAddress = "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB"; // Connect to Vault contract (read-only) const vault = connectVault(vaultAddress, VaultABI, provider); // For write operations, get signer const signer = await provider.getSigner(); const vaultWithSigner = connectVault(vaultAddress, VaultABI, signer); ``` ### ERC-20 Operations #### Get Balance ```typescript const balance = await vault.balanceOf(userAddress); console.log(`Shares: ${ethers.formatUnits(balance, 18)}`); ``` #### Transfer Shares ```typescript await vault.transfer(recipient, shares); ``` #### Approve Spending ```typescript await vault.approve(spender, shares); ``` #### Get Allowance ```typescript const allowance = await vault.allowance(owner, spender); ``` ### ERC-4626 Operations #### Deposit Assets Deposit assets directly to the vault (alternative to using Manager). ```typescript // Approve asset spending await assetToken.approve(vault.target, amount); // Deposit assets const shares = await vault.deposit(amount, receiver); console.log(`Received ${ethers.formatUnits(shares, 18)} shares`); ``` #### Redeem Shares Redeem shares for assets. ```typescript const assets = await vault.redeem(shares, receiver, owner); console.log(`Received ${ethers.formatUnits(assets, 6)} assets`); ``` #### Mint Shares Mint shares by depositing assets. ```typescript const assets = await vault.mint(shares, receiver); console.log(`Deposited ${ethers.formatUnits(assets, 6)} assets`); ``` #### Withdraw Assets Withdraw assets by redeeming shares. ```typescript const shares = await vault.withdraw(assets, receiver, owner); console.log(`Redeemed ${ethers.formatUnits(shares, 18)} shares`); ``` ### Conversion Functions #### Convert Shares to Assets ```typescript const assets = await vault.convertToAssets(shares); console.log(`Shares convert to: ${ethers.formatUnits(assets, 6)} assets`); ``` #### Convert Assets to Shares ```typescript const shares = await vault.convertToShares(assets); console.log(`Assets convert to: ${ethers.formatUnits(shares, 18)} shares`); ``` ### Preview Functions Preview the amount you'll receive before executing operations. #### Preview Deposit ```typescript const shares = await vault.previewDeposit(amount); console.log(`Depositing ${ethers.formatUnits(amount, 6)} will give ${ethers.formatUnits(shares, 18)} shares`); ``` #### Preview Mint ```typescript const assets = await vault.previewMint(shares); console.log(`Minting ${ethers.formatUnits(shares, 18)} shares requires ${ethers.formatUnits(assets, 6)} assets`); ``` #### Preview Redeem ```typescript const assets = await vault.previewRedeem(shares); console.log(`Redeeming ${ethers.formatUnits(shares, 18)} shares will give ${ethers.formatUnits(assets, 6)} assets`); ``` #### Preview Withdraw ```typescript const shares = await vault.previewWithdraw(assets); console.log(`Withdrawing ${ethers.formatUnits(assets, 6)} assets requires redeeming ${ethers.formatUnits(shares, 18)} shares`); ``` ### Vault-Specific Functions #### Get Asset Address ```typescript const assetAddress = await vault.asset(); console.log(`Vault Asset: ${assetAddress}`); ``` #### Get Total Assets ```typescript const totalAssets = await vault.totalAssets(); console.log(`Total Assets: ${ethers.formatUnits(totalAssets, 6)}`); ``` #### Get Total Supply ```typescript const totalSupply = await vault.totalSupply(); console.log(`Total Shares: ${ethers.formatUnits(totalSupply, 18)}`); ``` #### Get Rate Get the current exchange rate (assets per share). ```typescript const rate = await vault.getRate(); console.log(`Rate: ${ethers.formatUnits(rate, 18)}`); ``` #### Locked Shares Get locked shares for a user (shares locked in redemption queue). ```typescript const locked = await vault.lockedShares(userAddress); console.log(`Locked Shares: ${ethers.formatUnits(locked, 18)}`); ``` #### Lock Shares (Internal) Lock shares for redemption (typically called by Manager). ```typescript // Usually called by Manager contract await vault.lockShares(userAddress, shares); ``` #### Unlock Shares (Internal) Unlock shares (typically called by Manager when cancelling redemption). ```typescript // Usually called by Manager contract await vault.unlockShares(userAddress, shares); ``` ### Vault Information #### Get Vault Details ```typescript const name = await vault.name(); const symbol = await vault.symbol(); const decimals = await vault.decimals(); const manager = await vault.manager(); console.log(`Vault: ${name} (${symbol})`); console.log(`Decimals: ${decimals}`); console.log(`Manager: ${manager}`); ``` ### Complete Example #### Using Wagmi ```typescript import { connectVault } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useAccount, useWalletClient } from "wagmi"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; function VaultExample() { const { address } = useAccount(); const { data: walletClient } = useWalletClient(); const vaultInfo = async (vaultAddress: string) => { if (!walletClient || !address) { throw new Error("Wallet not connected"); } const provider = new ethers.BrowserProvider(walletClient); const vault = connectVault(vaultAddress, VaultABI, provider); // Get vault info const name = await vault.name(); const symbol = await vault.symbol(); const assetAddress = await vault.asset(); console.log(`Vault: ${name} (${symbol})`); console.log(`Asset: ${assetAddress}`); // Get balances const shares = await vault.balanceOf(address); const locked = await vault.lockedShares(address); const assets = await vault.convertToAssets(shares); console.log(`\nYour Vault Position:`); console.log(` Active Shares: ${ethers.formatUnits(shares, 18)}`); console.log(` Locked Shares: ${ethers.formatUnits(locked, 18)}`); console.log(` Total Assets: ${ethers.formatUnits(assets, 6)}`); // Get vault totals const totalAssets = await vault.totalAssets(); const totalSupply = await vault.totalSupply(); const rate = await vault.getRate(); console.log(`\nVault Totals:`); console.log(` Total Assets: ${ethers.formatUnits(totalAssets, 6)}`); console.log(` Total Shares: ${ethers.formatUnits(totalSupply, 18)}`); console.log(` Rate: ${ethers.formatUnits(rate, 18)} assets/share`); // Preview operations const depositAmount = ethers.parseUnits("100", 6); const previewShares = await vault.previewDeposit(depositAmount); console.log(`\nPreview:`); console.log(` Depositing ${ethers.formatUnits(depositAmount, 6)} assets`); console.log(` Would receive: ${ethers.formatUnits(previewShares, 18)} shares`); }; return ( ); } ``` #### Using Browser Provider ```typescript import { connectVault } from "yieldfi-sdk"; import { ethers } from "ethers"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; async function vaultExample() { if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const userAddress = await signer.getAddress(); const vaultAddress = "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB"; const vault = connectVault(vaultAddress, VaultABI, provider); // Get vault info const name = await vault.name(); const symbol = await vault.symbol(); const assetAddress = await vault.asset(); console.log(`Vault: ${name} (${symbol})`); console.log(`Asset: ${assetAddress}`); // Get balances const shares = await vault.balanceOf(userAddress); const locked = await vault.lockedShares(userAddress); const assets = await vault.convertToAssets(shares); console.log(`\nYour Vault Position:`); console.log(` Active Shares: ${ethers.formatUnits(shares, 18)}`); console.log(` Locked Shares: ${ethers.formatUnits(locked, 18)}`); console.log(` Total Assets: ${ethers.formatUnits(assets, 6)}`); // Get vault totals const totalAssets = await vault.totalAssets(); const totalSupply = await vault.totalSupply(); const rate = await vault.getRate(); console.log(`\nVault Totals:`); console.log(` Total Assets: ${ethers.formatUnits(totalAssets, 6)}`); console.log(` Total Shares: ${ethers.formatUnits(totalSupply, 18)}`); console.log(` Rate: ${ethers.formatUnits(rate, 18)} assets/share`); // Preview operations const depositAmount = ethers.parseUnits("100", 6); const previewShares = await vault.previewDeposit(depositAmount); console.log(`\nPreview:`); console.log(` Depositing ${ethers.formatUnits(depositAmount, 6)} assets`); console.log(` Would receive: ${ethers.formatUnits(previewShares, 18)} shares`); } vaultExample(); ``` ### Type Safety The SDK provides TypeScript types for type-safe contract interactions: #### Using Wagmi ```typescript import type { VaultContract } from "yieldfi-sdk"; import { Contract } from "ethers"; import { useWalletClient } from "wagmi"; function TypedVaultExample() { const { data: walletClient } = useWalletClient(); const useTypedVault = async (vaultAddress: string) => { if (!walletClient) return; const provider = new ethers.BrowserProvider(walletClient); const signer = await provider.getSigner(); const vault = new Contract( vaultAddress, VaultABI, signer ) as unknown as VaultContract; // Full type safety and IntelliSense await vault.balanceOf(/* ... */); await vault.convertToAssets(/* ... */); await vault.deposit(/* ... */); }; } ``` #### Using Browser Provider ```typescript import type { VaultContract } from "yieldfi-sdk"; import { Contract } from "ethers"; const provider = new ethers.BrowserProvider(window.ethereum); const vault = new Contract( vaultAddress, VaultABI, provider ) as unknown as VaultContract; // Full type safety and IntelliSense await vault.balanceOf(/* ... */); await vault.convertToAssets(/* ... */); ``` # Manager (V3) The Manager V3 contract is the core protocol contract for deposits and withdrawals in YieldFi v3. ### Connecting to Manager V3 #### Using Wagmi ```typescript import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useAccount, useWalletClient } from "wagmi"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; function ManagerV3Example() { const { address } = useAccount(); const { data: walletClient } = useWalletClient(); const connectManager = async () => { if (!walletClient || !address) { throw new Error("Wallet not connected"); } const provider = new ethers.BrowserProvider(walletClient); const signer = await provider.getSigner(); const contracts = getContractAddresses(Chain.ETHEREUM); const managerV3 = connectManagerV3( contracts.manager, ManagerV3ABI, signer ); return managerV3; }; } ``` #### Using Browser Provider ```typescript import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; // Connect to browser wallet if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); // Get contract address const contracts = getContractAddresses(Chain.ETHEREUM); // Connect to Manager V3 const managerV3 = connectManagerV3( contracts.manager, ManagerV3ABI, signer // or provider for read-only operations ); ``` ### Common Operations #### Deposit Assets Deposit assets to a vault and receive vault shares. ```typescript // 1. Approve asset spending await assetToken.approve(managerV3.target, amount); // 2. Deposit via Manager V3 const shares = await managerV3.deposit( vaultAddress, // Vault address assetAddress, // Asset to deposit amount, // Amount to deposit receiver, // Receiver address minShares, // Minimum shares to receive (slippage protection, can be 0) referralCode // Referral code (bytes32, can be ethers.ZeroHash) ); // Returns: shares received (bigint) ``` **Parameters:** * `vault` - Vault contract address * `asset` - Asset token address to deposit * `amount` - Amount of asset to deposit * `receiver` - Address that will receive vault shares * `minShares` - Minimum shares to receive (slippage protection) * `referralCode` - Referral code (bytes32) #### Request Redemption Request redemption from a vault. Shares are locked (not burned) until processed. ```typescript await managerV3.requestRedemption( vaultAddress, // Vault address shares, // Amount of shares to redeem owner, // Owner of shares receiver // Receiver address (can be different from owner) ); // Shares are locked in redemption queue // Use cancelRedemption() to unlock if needed ``` **Parameters:** * `vault` - Vault contract address * `shares` - Amount of shares to redeem * `owner` - Owner of the shares * `receiver` - Address that will receive redemption assets #### Cancel Redemption Cancel a pending redemption request and unlock shares. ```typescript await managerV3.cancelRedemption( vaultAddress, // Vault address queueIndex // Queue index of redemption to cancel ); ``` #### Process Redemption (Operator Only) Process a redemption from the queue. Typically called by vault operators. ```typescript await managerV3.processRedemption( vaultAddress, // Vault address queueIndex, // Queue index to process gasFeeShares // Gas fee in shares (can be 0) ); ``` ### View Functions #### Get Redemption Queue Length ```typescript const queueLength = await managerV3.getRedemptionQueueLength(vaultAddress); console.log(`Queue length: ${queueLength}`); ``` #### Get Redemption Queue Entry ```typescript const entry = await managerV3.getRedemptionQueueEntry(vaultAddress, queueIndex); console.log(`Owner: ${entry.owner}`); console.log(`Locked Shares: ${entry.lockedShares}`); console.log(`NAV at Request: ${entry.navAtRequest}`); ``` #### Get Standard Debt Get total locked shares (standard debt) for a vault. ```typescript const standardDebt = await managerV3.getStandardDebt(vaultAddress); console.log(`Standard Debt: ${ethers.formatUnits(standardDebt, 18)} shares`); ``` #### Get NAV Get current Net Asset Value (NAV) for a vault. ```typescript const nav = await managerV3.getNAV(vaultAddress); console.log(`NAV: ${ethers.formatUnits(nav, 18)}`); ``` #### Check Whitelisting ```typescript const isWhitelisted = await managerV3.isWhitelisted(vaultAddress, assetAddress); console.log(`Asset whitelisted: ${isWhitelisted}`); ``` #### Get Vault Asset Get the base asset address for a vault. ```typescript const assetAddress = await managerV3.getVaultAsset(vaultAddress); console.log(`Vault Asset: ${assetAddress}`); ``` ### Type Safety The SDK provides TypeScript types for type-safe contract interactions: ```typescript import type { ManagerV3 } from "yieldfi-sdk"; import { Contract } from "ethers"; const managerV3 = new Contract( contracts.manager, ManagerV3ABI, signer ) as unknown as ManagerV3; // Full type safety and IntelliSense await managerV3.deposit(/* ... */); await managerV3.requestRedemption(/* ... */); ``` ### Complete Example #### Using Wagmi ```typescript import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useAccount, useWalletClient } from "wagmi"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; function ManagerV3Example() { const { address } = useAccount(); const { data: walletClient } = useWalletClient(); const managerV3Flow = async () => { if (!walletClient || !address) { throw new Error("Wallet not connected"); } const provider = new ethers.BrowserProvider(walletClient); const signer = await provider.getSigner(); const contracts = getContractAddresses(Chain.ETHEREUM); const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, signer); const vaultAddress = "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB"; const assetAddress = "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"; // USDC // Check if asset is whitelisted const whitelisted = await managerV3.isWhitelisted(vaultAddress, assetAddress); console.log(`Asset whitelisted: ${whitelisted}`); // Get vault info const vaultAsset = await managerV3.getVaultAsset(vaultAddress); const nav = await managerV3.getNAV(vaultAddress); console.log(`Vault Asset: ${vaultAsset}`); console.log(`NAV: ${ethers.formatUnits(nav, 18)}`); // Deposit const assetToken = new ethers.Contract( assetAddress, [ "function approve(address spender, uint256 amount) returns (bool)", "function balanceOf(address account) view returns (uint256)", ], signer ); const amount = ethers.parseUnits("100", 6); await assetToken.approve(managerV3.target, amount); const shares = await managerV3.deposit( vaultAddress, assetAddress, amount, address, 0n, ethers.ZeroHash ); console.log(`Received ${ethers.formatUnits(shares, 18)} shares`); // Request redemption await managerV3.requestRedemption( vaultAddress, shares / 2n, address, address ); // Check queue const queueLength = await managerV3.getRedemptionQueueLength(vaultAddress); console.log(`Queue length: ${queueLength}`); }; return ; } ``` #### Using Browser Provider ```typescript import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; async function managerV3Example() { if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const userAddress = await signer.getAddress(); const contracts = getContractAddresses(Chain.ETHEREUM); const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, signer); const vaultAddress = "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB"; const assetAddress = "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"; // USDC // Check if asset is whitelisted const whitelisted = await managerV3.isWhitelisted(vaultAddress, assetAddress); console.log(`Asset whitelisted: ${whitelisted}`); // Get vault info const vaultAsset = await managerV3.getVaultAsset(vaultAddress); const nav = await managerV3.getNAV(vaultAddress); console.log(`Vault Asset: ${vaultAsset}`); console.log(`NAV: ${ethers.formatUnits(nav, 18)}`); // Deposit const assetToken = new ethers.Contract( assetAddress, [ "function approve(address spender, uint256 amount) returns (bool)", "function balanceOf(address account) view returns (uint256)", ], signer ); const amount = ethers.parseUnits("100", 6); await assetToken.approve(managerV3.target, amount); const shares = await managerV3.deposit( vaultAddress, assetAddress, amount, userAddress, 0n, ethers.ZeroHash ); console.log(`Received ${ethers.formatUnits(shares, 18)} shares`); // Request redemption await managerV3.requestRedemption( vaultAddress, shares / 2n, userAddress, userAddress ); // Check queue const queueLength = await managerV3.getRedemptionQueueLength(vaultAddress); console.log(`Queue length: ${queueLength}`); } managerV3Example(); ``` # YToken (Legacy) > **Note**: This page documents legacy YToken contracts. For v3 contracts, see Vault Contract. YToken contracts are yield-bearing ERC-4626 vault tokens (yUSD, yBTC, yETH, etc.) from earlier versions. ### Connecting to YToken #### Using Wagmi ```typescript import { connectYToken, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useAccount, useWalletClient } from "wagmi"; function YTokenExample() { const { address } = useAccount(); const { data: walletClient } = useWalletClient(); const connectYTokenContract = async () => { if (!walletClient || !address) { throw new Error("Wallet not connected"); } const provider = new ethers.BrowserProvider(walletClient); const signer = await provider.getSigner(); const contracts = getContractAddresses(Chain.ETHEREUM); const yUSD = connectYToken( contracts.yUSD, yTokenAbi, // Your YToken ABI signer ); return yUSD; }; } ``` #### Using Browser Provider ```typescript import { connectYToken, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const contracts = getContractAddresses(Chain.ETHEREUM); const yUSD = connectYToken( contracts.yUSD, yTokenAbi, // Your YToken ABI signer ); ``` ### ERC-20 Operations ```typescript // Get balance const balance = await yUSD.balanceOf(userAddress); // Transfer await yUSD.transfer(recipient, amount); // Approve await yUSD.approve(spender, amount); ``` ### ERC-4626 Operations ```typescript // Deposit assets const shares = await yUSD.deposit(amount, receiver); // Redeem shares await yUSD.redeem(shares, receiver, owner); // Get conversion rates const assetsPerShare = await yUSD.convertToAssets(shares); const sharesPerAsset = await yUSD.convertToShares(amount); ``` ### View Methods ```typescript // Get total assets const totalAssets = await yUSD.totalAssets(); // Get total supply const totalSupply = await yUSD.totalSupply(); // Get asset address const asset = await yUSD.asset(); ``` ### Migration to V3 For new integrations, use v3 contracts: * **Manager V3** - See Manager Contract * **Vault Contract** - See Vault Contract # VyToken (Legacy) > **Note**: This page documents legacy VyToken contracts. For v3 contracts, see Vault Contract. VyToken contracts are volatile yield token contracts (vyUSD, vyBTC, vyETH) with enhanced yield optimization from earlier versions. ### Connecting to VyToken #### Using Wagmi ```typescript import { connectVyToken, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useAccount, useWalletClient } from "wagmi"; function VyTokenExample() { const { address } = useAccount(); const { data: walletClient } = useWalletClient(); const connectVyTokenContract = async () => { if (!walletClient || !address) { throw new Error("Wallet not connected"); } const provider = new ethers.BrowserProvider(walletClient); const signer = await provider.getSigner(); const contracts = getContractAddresses(Chain.ETHEREUM); const vyUSD = connectVyToken( contracts.vyUSD, vyTokenAbi, // Your VyToken ABI signer ); return vyUSD; }; } ``` #### Using Browser Provider ```typescript import { connectVyToken, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const contracts = getContractAddresses(Chain.ETHEREUM); const vyUSD = connectVyToken( contracts.vyUSD, vyTokenAbi, // Your VyToken ABI signer ); ``` ### VyToken-Specific Operations #### Deposit YToken ```typescript // Approve yToken spending await yUSD.approve(vyUSD.target, amount); // Deposit yToken directly await vyUSD.depositYToken(receiver, amount); ``` #### View Methods ```typescript // Get underlying yToken const yToken = await vyUSD.yToken(); // Get guardrail multiplier const guardrail = await vyUSD.guardrailMultiplier(); // Get total yToken deposited const totalYToken = await vyUSD.totalYToken(); ``` ### Inherited Operations VyToken inherits all YToken operations (ERC-20 and ERC-4626): ```typescript // ERC-20 const balance = await vyUSD.balanceOf(userAddress); await vyUSD.transfer(recipient, amount); // ERC-4626 const shares = await vyUSD.deposit(amount, receiver); await vyUSD.redeem(shares, receiver, owner); ``` ### Migration to V3 For new integrations, use v3 contracts: * **Manager V3** - See Manager Contract * **Vault Contract** - See Vault Contract # Error Handling ## Overview The YieldFi SDK provides specialized error classes for different error scenarios. All errors extend from `SDKError` and include detailed information. ### Error Types * `SDKError` - Base error class * `AuthenticationError` - Authentication failures * `NetworkError` - Network and HTTP errors * `ValidationError` - Input validation errors * `ConfigurationError` - SDK configuration errors ### Quick Example ```typescript import { AuthenticationError, NetworkError, ValidationError, } from "yieldfi-sdk"; try { const vault = await sdk.vault.getVaultByKey("yusd", 1); } catch (error) { if (error instanceof AuthenticationError) { console.error("Auth failed:", error.message); } else if (error instanceof NetworkError) { console.error("Network error:", error.statusCode); } else if (error instanceof ValidationError) { console.error("Validation error:", error.message); } } ``` ### Next Steps * Error Types - Detailed error type reference * Best Practices - Error handling best practices # Error Types The SDK provides specialized error classes for different error scenarios. All errors extend from `SDKError`. ### SDKError (Base Class) Base error class that all SDK errors extend from. **Properties:** * `message: string` - Human-readable error message * `code: string` - Error code for programmatic handling * `details?: any` - Additional error context ### AuthenticationError Thrown when authentication fails. **Common Causes:** * Invalid credentials * Expired tokens * Malformed JWT tokens * Invalid signature **Example:** ```typescript import { AuthenticationError } from "yieldfi-sdk"; try { await sdk.auth.login(credentials); } catch (error) { if (error instanceof AuthenticationError) { console.error("Auth failed:", error.message); console.error("Code:", error.code); console.error("Details:", error.details); } } ``` ### NetworkError Thrown for network-related errors. **Properties:** * `statusCode?: number` - HTTP status code * `response?: any` - Response data (if available) **Common Causes:** * Network connectivity issues * Request timeouts * HTTP errors (4xx, 5xx) * Server unavailable **Example:** ```typescript import { NetworkError } from "yieldfi-sdk"; try { await sdk.vault.getVaultByKey("yusd", 1); } catch (error) { if (error instanceof NetworkError) { console.error("Network error:", error.message); console.error("Status code:", error.statusCode); if (error.statusCode === 503) { console.error("Service unavailable, please try again later"); } } } ``` ### ValidationError Thrown when input validation fails. **Common Causes:** * Missing required parameters * Invalid parameter types * Out-of-range values * Invalid format **Example:** ```typescript import { ValidationError } from "yieldfi-sdk"; try { await sdk.vault.getVaults({ page: -1, // Invalid: page must be >= 1 }); } catch (error) { if (error instanceof ValidationError) { console.error("Validation error:", error.message); console.error("Invalid field:", error.details?.field); } } ``` ### ConfigurationError Thrown when SDK configuration is invalid. **Common Causes:** * Missing required configuration * Invalid configuration values * Invalid gateway URL format **Example:** ```typescript import { ConfigurationError } from "yieldfi-sdk"; try { await YieldFiSDK.create({ gatewayUrl: "", // Invalid: empty URL }); } catch (error) { if (error instanceof ConfigurationError) { console.error("Configuration error:", error.message); console.error("Details:", error.details); } } ``` ### Complete Error Handling Example ```typescript import { SDKError, AuthenticationError, NetworkError, ValidationError, ConfigurationError, } from "yieldfi-sdk"; async function handleApiCall() { try { const vault = await sdk.vault.getVaultByKey("yusd", 1); return vault; } catch (error) { if (error instanceof AuthenticationError) { // Handle authentication errors console.error("Authentication failed:", error.message); // Redirect to login or refresh token return null; } else if (error instanceof NetworkError) { // Handle network errors console.error("Network error:", error.message); if (error.statusCode === 503) { // Service unavailable - show retry option return { retry: true }; } // Show error message to user return null; } else if (error instanceof ValidationError) { // Handle validation errors console.error("Invalid input:", error.message); // Show validation error to user return null; } else if (error instanceof ConfigurationError) { // Handle configuration errors console.error("SDK configuration error:", error.message); // This should not happen in production return null; } else if (error instanceof SDKError) { // Handle other SDK errors console.error("SDK error:", error.code, error.message); return null; } else { // Handle unexpected errors console.error("Unexpected error:", error); return null; } } } ``` ### Error Codes Common error codes you may encounter: * `AUTH_FAILED` - Authentication failed * `TOKEN_EXPIRED` - Token expired * `INVALID_TOKEN` - Invalid token format * `NETWORK_ERROR` - Network request failed * `TIMEOUT` - Request timeout * `VALIDATION_ERROR` - Input validation failed * `NOT_FOUND` - Resource not found * `FORBIDDEN` - Access forbidden * `SERVER_ERROR` - Server error # Best Practices Follow these best practices for robust error handling in your application. ### Always Use Try-Catch Wrap SDK calls in try-catch blocks: ```typescript try { const vault = await sdk.vault.getVaultByKey("yusd", 1); } catch (error) { // Handle error } ``` ### Check Error Types Use `instanceof` to check error types: ```typescript import { AuthenticationError, NetworkError, ValidationError, } from "yieldfi-sdk"; try { await sdk.auth.login(credentials); } catch (error) { if (error instanceof AuthenticationError) { // Handle auth errors } else if (error instanceof NetworkError) { // Handle network errors } else if (error instanceof ValidationError) { // Handle validation errors } } ``` ### Provide User-Friendly Messages Translate technical errors to user-friendly messages: ```typescript function getUserFriendlyError(error: SDKError): string { if (error instanceof AuthenticationError) { return "Please login again"; } else if (error instanceof NetworkError) { if (error.statusCode === 503) { return "Service temporarily unavailable. Please try again later."; } return "Network error. Please check your connection."; } else if (error instanceof ValidationError) { return "Please check your input and try again."; } return "An error occurred. Please try again."; } ``` ### Implement Retry Logic For network errors, implement retry logic: ```typescript async function withRetry( fn: () => Promise, maxRetries = 3 ): Promise { for (let i = 0; i < maxRetries; i++) { try { return await fn(); } catch (error) { if (error instanceof NetworkError && i < maxRetries - 1) { await new Promise((resolve) => setTimeout(resolve, 1000 * (i + 1))); continue; } throw error; } } throw new Error("Max retries exceeded"); } // Usage const vault = await withRetry(() => sdk.vault.getVaultByKey("yusd", 1) ); ``` ### Handle Token Expiration Always handle token expiration gracefully: ```typescript async function makeAuthenticatedRequest( apiCall: (token: string) => Promise ): Promise { let accessToken = localStorage.getItem("accessToken"); if (!accessToken || isTokenExpired(accessToken)) { accessToken = await refreshToken(); if (!accessToken) { throw new AuthenticationError("Please login again"); } } try { return await apiCall(accessToken); } catch (error) { if (error instanceof AuthenticationError) { // Token invalid, try refresh once accessToken = await refreshToken(); if (accessToken) { return await apiCall(accessToken); } } throw error; } } ``` ### Log Errors Appropriately Log errors for debugging but don't expose sensitive information: ```typescript try { await sdk.auth.login(credentials); } catch (error) { // Log full error for debugging (server-side or dev only) console.error("Login error:", error); // Show user-friendly message showError("Login failed. Please try again."); // Don't expose: // - Token values // - Internal error details // - Stack traces (to users) } ``` ### Handle Loading States Show loading states during API calls: ```typescript const [loading, setLoading] = useState(false); const [error, setError] = useState(null); async function fetchVaults() { setLoading(true); setError(null); try { const vaults = await sdk.vault.getVaults({ chainId: 1 }); return vaults; } catch (err: any) { setError(err.message); throw err; } finally { setLoading(false); } } ``` ### Graceful Degradation Handle partial failures gracefully: ```typescript async function loadDashboard() { const results = await Promise.allSettled([ sdk.vault.getProtocolStats(), sdk.vault.getVaults({ chainId: 1 }), sdk.vault.getStrategies(), ]); const stats = results[0].status === "fulfilled" ? results[0].value : null; const vaults = results[1].status === "fulfilled" ? results[1].value : null; const strategies = results[2].status === "fulfilled" ? results[2].value : null; // Show available data, indicate missing data return { stats, vaults, strategies }; } ``` # Examples & Guides This section provides complete, working examples for common use cases with the YieldFi SDK. ### Available Examples * Complete Authentication Flow - Full wallet authentication implementation * Vault Operations - Querying vaults and managing assets * Transaction History - Working with transaction data * Contract Integration - Integrating with smart contracts ### Quick Example ```typescript import { YieldFiSDK } from "yieldfi-sdk"; // Initialize and authenticate const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi" }); // ... authentication code ... // Query vaults const vaults = await sdk.vault.getVaults({ chainId: 1 }); // Get transactions const transactions = await sdk.vault.getTransactions( { chainId: 1 }, accessToken ); ``` ### Next Steps Browse the examples above for complete implementation guides! # Authentication Flow This example demonstrates a complete authentication flow with token management and error handling. ### React Component Example ```typescript import { useState, useEffect } from "react"; import { YieldFiSDK, AuthenticationError, NetworkError } from "yieldfi-sdk"; import { ethers } from "ethers"; function AuthExample() { const [sdk, setSdk] = useState(null); const [user, setUser] = useState(null); const [loading, setLoading] = useState(false); const [error, setError] = useState(null); useEffect(() => { initializeSDK(); checkExistingAuth(); }, []); const initializeSDK = async () => { try { const sdkInstance = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); setSdk(sdkInstance); } catch (err: any) { setError(`Failed to initialize SDK: ${err.message}`); } }; const checkExistingAuth = async () => { const accessToken = localStorage.getItem("accessToken"); if (!accessToken || !sdk) return; try { // Verify token is still valid by making a test request const transactions = await sdk.vault.getTransactions( { chainId: 1, page: 1, pageSize: 1 }, accessToken ); // Token is valid, load user info const userStr = localStorage.getItem("user"); if (userStr) { setUser(JSON.parse(userStr)); } } catch (err) { // Token expired or invalid, clear storage localStorage.removeItem("accessToken"); localStorage.removeItem("refreshToken"); localStorage.removeItem("user"); } }; const handleLogin = async () => { if (!sdk) { setError("SDK not initialized"); return; } try { setLoading(true); setError(null); // 1. Connect to wallet if (!window.ethereum) { throw new Error("MetaMask not installed"); } const provider = new ethers.BrowserProvider(window.ethereum); await provider.send("eth_requestAccounts", []); const signer = await provider.getSigner(); const address = await signer.getAddress(); // 2. Generate nonce const nonce = await sdk.auth.generateNonce({ address }); // 3. Sign message const signature = await signer.signMessage(nonce.message); // 4. Login const authResponse = await sdk.auth.login({ address, signature, message: nonce.message, }); // 5. Store tokens and user info localStorage.setItem("accessToken", authResponse.accessToken); localStorage.setItem("refreshToken", authResponse.refreshToken); localStorage.setItem("user", JSON.stringify(authResponse.user)); setUser(authResponse.user); console.log("Login successful!"); } catch (err: any) { if (err instanceof AuthenticationError) { setError(`Authentication failed: ${err.message}`); } else if (err instanceof NetworkError) { setError(`Network error: ${err.message}`); } else { setError(`Login failed: ${err.message}`); } } finally { setLoading(false); } }; const handleLogout = async () => { if (!sdk) return; try { const accessToken = localStorage.getItem("accessToken"); if (accessToken) { await sdk.auth.logout(accessToken); } } catch (err) { console.error("Logout error:", err); } finally { localStorage.removeItem("accessToken"); localStorage.removeItem("refreshToken"); localStorage.removeItem("user"); setUser(null); } }; if (!sdk) { return
Initializing SDK...
; } return (
{user ? (

Logged in as: {user.address}

Role: {user.role}

) : (
{error &&

{error}

}
)}
); } export default AuthExample; ``` ### Token Refresh Utility ```typescript import { YieldFiSDK, isTokenExpired } from "yieldfi-sdk"; async function getValidAccessToken(): Promise { let accessToken = localStorage.getItem("accessToken"); const refreshToken = localStorage.getItem("refreshToken"); // Check if token is expired or expiring soon (5 minute buffer) if (!accessToken || isTokenExpired(accessToken, 300)) { if (!refreshToken) { return null; } try { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const newTokens = await sdk.auth.refresh({ refreshToken }); accessToken = newTokens.accessToken; localStorage.setItem("accessToken", newTokens.accessToken); localStorage.setItem("refreshToken", newTokens.refreshToken); return accessToken; } catch (error) { localStorage.removeItem("accessToken"); localStorage.removeItem("refreshToken"); return null; } } return accessToken; } ``` ### Usage in API Calls ```typescript async function fetchUserTransactions() { const accessToken = await getValidAccessToken(); if (!accessToken) { // Redirect to login window.location.href = "/login"; return; } try { const transactions = await sdk.vault.getTransactions( { chainId: 1, page: 1, pageSize: 20 }, accessToken ); return transactions; } catch (error) { if (error instanceof AuthenticationError) { // Token invalid, clear and redirect localStorage.clear(); window.location.href = "/login"; } throw error; } } ``` # Contract Integration Examples for integrating with YieldFi v3 smart contracts. The v3 contracts use a Manager contract for deposits/redemptions and Vault contracts (ERC-4626) for vault tokens. ### Getting V3 Contract ABIs V3 contract ABIs are included in the SDK package: ```typescript import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; ``` Or import from the abis directory in your project: ```typescript import ManagerV3ABI from "./abis/v3/Manager.json"; import VaultABI from "./abis/v3/Vault.json"; ``` ### Deposit to Vault Deposit assets to a v3 vault using the Manager contract. 
import {
  connectManagerV3,
  connectVault,
  getContractAddresses,
  Chain,
} from "yieldfi-sdk";
import { ethers } from "ethers";
import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json";

// Request Redemption (V3)

//Request redemption from a v3 vault. Shares are locked in a queue until processed.

//### Using Wagmi

import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk";
import { ethers } from "ethers";
import { useAccount, useWalletClient } from "wagmi";
import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json";

function RedemptionButton() {
  const { address } = useAccount();
  const { data: walletClient } = useWalletClient();

  const requestRedemption = async (
    vaultAddress: string,
    shares: bigint,
    receiver?: string
  ) => {
    if (!walletClient || !address) {
      throw new Error("Wallet not connected");
    }

    const provider = new ethers.BrowserProvider(walletClient);
    const signer = await provider.getSigner();

    const contracts = getContractAddresses(Chain.ETHEREUM);
    const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, signer);

    // Request redemption (shares are locked, not burned)
    const redeemTx = await managerV3.requestRedemption(
      vaultAddress,
      shares,
      address, // Owner
      receiver || address // Receiver (defaults to owner)
    );

    const receipt = await redeemTx.wait();
    console.log(`Redemption requested: ${receipt.hash}`);
    return receipt;
  };

  return (
    <button
      onClick={() =>
        requestRedemption(
          "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB",
          ethers.parseUnits("100", 18)
        )
      }
    >
      Request Redemption
    </button>
  );
}
#### Using Browser Provider ```typescript import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; async function requestRedemptionV3( vaultAddress: string, shares: bigint, receiver?: string ) { if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const userAddress = await signer.getAddress(); const contracts = getContractAddresses(Chain.ETHEREUM); const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, signer); // Request redemption (shares are locked, not burned) const redeemTx = await managerV3.requestRedemption( vaultAddress, shares, userAddress, // Owner receiver || userAddress // Receiver (defaults to owner) ); const receipt = await redeemTx.wait(); console.log(`Redemption requested: ${receipt.hash}`); return receipt; } // Usage requestRedemptionV3( "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB", ethers.parseUnits("100", 18) ); ``` ### Check Vault Balance (V3) Check vault token balance and convert between shares and assets. #### Using Wagmi ```typescript import { connectVault } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useAccount, useWalletClient } from "wagmi"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; function VaultBalance() { const { address } = useAccount(); const { data: walletClient } = useWalletClient(); const checkVaultBalance = async (vaultAddress: string) => { if (!walletClient || !address) { throw new Error("Wallet not connected"); } const provider = new ethers.BrowserProvider(walletClient); const vault = connectVault(vaultAddress, VaultABI, provider); // Get user's share balance const shares = await vault.balanceOf(address); console.log(`Shares: ${ethers.formatUnits(shares, 18)}`); // Get total assets and supply const totalAssets = await vault.totalAssets(); const totalSupply = await vault.totalSupply(); console.log(`Total Assets: ${ethers.formatUnits(totalAssets, 6)}`); console.log(`Total Supply: ${ethers.formatUnits(totalSupply, 18)}`); // Convert shares to assets (ERC-4626 method) const assets = await vault.convertToAssets(shares); console.log(`Your Assets: ${ethers.formatUnits(assets, 6)}`); // Get asset address const assetAddress = await vault.asset(); console.log(`Asset Address: ${assetAddress}`); // Get vault info const name = await vault.name(); const symbol = await vault.symbol(); const decimals = await vault.decimals(); console.log(`Vault: ${name} (${symbol}) - ${decimals} decimals`); return { shares, assets, totalAssets, totalSupply, assetAddress, }; }; return ( ); } ``` #### Using Browser Provider ```typescript import { connectVault } from "yieldfi-sdk"; import { ethers } from "ethers"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; async function checkVaultBalance(vaultAddress: string) { if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const userAddress = await signer.getAddress(); // Connect to Vault contract (ERC-4626) const vault = connectVault(vaultAddress, VaultABI, provider); // Get user's share balance const shares = await vault.balanceOf(userAddress); console.log(`Shares: ${ethers.formatUnits(shares, 18)}`); // Get total assets and supply const totalAssets = await vault.totalAssets(); const totalSupply = await vault.totalSupply(); console.log(`Total Assets: ${ethers.formatUnits(totalAssets, 6)}`); console.log(`Total Supply: ${ethers.formatUnits(totalSupply, 18)}`); // Convert shares to assets (ERC-4626 method) const assets = await vault.convertToAssets(shares); console.log(`Your Assets: ${ethers.formatUnits(assets, 6)}`); // Get asset address const assetAddress = await vault.asset(); console.log(`Asset Address: ${assetAddress}`); // Get vault info const name = await vault.name(); const symbol = await vault.symbol(); const decimals = await vault.decimals(); console.log(`Vault: ${name} (${symbol}) - ${decimals} decimals`); return { shares, assets, totalAssets, totalSupply, assetAddress, }; } // Usage checkVaultBalance("0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB"); ``` ### Check Redemption Queue (V3) Check redemption queue status and entries. #### Using Wagmi ```typescript import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useWalletClient } from "wagmi"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; function RedemptionQueue() { const { data: walletClient } = useWalletClient(); const checkRedemptionQueue = async (vaultAddress: string) => { if (!walletClient) { throw new Error("Wallet not connected"); } const provider = new ethers.BrowserProvider(walletClient); const contracts = getContractAddresses(Chain.ETHEREUM); const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, provider); // Get queue length const queueLength = await managerV3.getRedemptionQueueLength(vaultAddress); console.log(`Redemption Queue Length: ${queueLength}`); // Get standard debt (total locked shares) const standardDebt = await managerV3.getStandardDebt(vaultAddress); console.log(`Standard Debt (Locked Shares): ${ethers.formatUnits(standardDebt, 18)}`); // Get next queue index const nextIndex = await managerV3.nextQueueIndex(vaultAddress); console.log(`Next Queue Index: ${nextIndex}`); // Get a specific queue entry if (queueLength > 0n) { const queueEntry = await managerV3.getRedemptionQueueEntry(vaultAddress, 0); console.log(`Queue Entry 0:`); console.log(` Owner: ${queueEntry.owner}`); console.log(` Receiver: ${queueEntry.receiver}`); console.log(` Locked Shares: ${ethers.formatUnits(queueEntry.lockedShares, 18)}`); console.log(` NAV at Request: ${ethers.formatUnits(queueEntry.navAtRequest, 18)}`); console.log(` Timestamp: ${new Date(Number(queueEntry.timestamp) * 1000).toLocaleString()}`); } return { queueLength, standardDebt, nextIndex, }; }; return ( ); } ``` #### Using Browser Provider ```typescript import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; async function checkRedemptionQueue(vaultAddress: string) { if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const contracts = getContractAddresses(Chain.ETHEREUM); const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, provider); // Get queue length const queueLength = await managerV3.getRedemptionQueueLength(vaultAddress); console.log(`Redemption Queue Length: ${queueLength}`); // Get standard debt (total locked shares) const standardDebt = await managerV3.getStandardDebt(vaultAddress); console.log(`Standard Debt (Locked Shares): ${ethers.formatUnits(standardDebt, 18)}`); // Get next queue index const nextIndex = await managerV3.nextQueueIndex(vaultAddress); console.log(`Next Queue Index: ${nextIndex}`); // Get a specific queue entry if (queueLength > 0n) { const queueEntry = await managerV3.getRedemptionQueueEntry(vaultAddress, 0); console.log(`Queue Entry 0:`); console.log(` Owner: ${queueEntry.owner}`); console.log(` Receiver: ${queueEntry.receiver}`); console.log(` Locked Shares: ${ethers.formatUnits(queueEntry.lockedShares, 18)}`); console.log(` NAV at Request: ${ethers.formatUnits(queueEntry.navAtRequest, 18)}`); console.log(` Timestamp: ${new Date(Number(queueEntry.timestamp) * 1000).toLocaleString()}`); } return { queueLength, standardDebt, nextIndex, }; } // Usage checkRedemptionQueue("0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB"); ``` ### Cancel Redemption (V3) Cancel a pending redemption request. #### Using Wagmi ```typescript import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useAccount, useWalletClient } from "wagmi"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; function CancelRedemptionButton() { const { address } = useAccount(); const { data: walletClient } = useWalletClient(); const cancelRedemption = async (vaultAddress: string, queueIndex: bigint) => { if (!walletClient || !address) { throw new Error("Wallet not connected"); } const provider = new ethers.BrowserProvider(walletClient); const signer = await provider.getSigner(); const contracts = getContractAddresses(Chain.ETHEREUM); const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, signer); // Cancel redemption (unlocks shares) const cancelTx = await managerV3.cancelRedemption(vaultAddress, queueIndex); const receipt = await cancelTx.wait(); console.log(`Redemption cancelled: ${receipt.hash}`); return receipt; }; return ( ); } ``` #### Using Browser Provider ```typescript import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; async function cancelRedemption(vaultAddress: string, queueIndex: bigint) { if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const contracts = getContractAddresses(Chain.ETHEREUM); const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, signer); // Cancel redemption (unlocks shares) const cancelTx = await managerV3.cancelRedemption(vaultAddress, queueIndex); const receipt = await cancelTx.wait(); console.log(`Redemption cancelled: ${receipt.hash}`); return receipt; } // Usage cancelRedemption( "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB", 0n // Queue index ); ``` ### Process Redemption (V3) - Admin/Operator Only Process a redemption from the queue. This is typically called by vault operators. #### Using Wagmi ```typescript import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useAccount, useWalletClient } from "wagmi"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; function ProcessRedemptionButton() { const { address } = useAccount(); const { data: walletClient } = useWalletClient(); const processRedemption = async ( vaultAddress: string, queueIndex: bigint, gasFeeShares: bigint = 0n ) => { if (!walletClient || !address) { throw new Error("Wallet not connected"); } const provider = new ethers.BrowserProvider(walletClient); const signer = await provider.getSigner(); const contracts = getContractAddresses(Chain.ETHEREUM); const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, signer); // Process redemption (burns locked shares, transfers assets) const processTx = await managerV3.processRedemption( vaultAddress, queueIndex, gasFeeShares ); const receipt = await processTx.wait(); console.log(`Redemption processed: ${receipt.hash}`); return receipt; }; return ( ); } ``` #### Using Browser Provider ```typescript import { connectManagerV3, getContractAddresses, Chain } from "yieldfi-sdk"; import { ethers } from "ethers"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; async function processRedemption( vaultAddress: string, queueIndex: bigint, gasFeeShares: bigint = 0n ) { if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const contracts = getContractAddresses(Chain.ETHEREUM); const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, signer); // Process redemption (burns locked shares, transfers assets) const processTx = await managerV3.processRedemption( vaultAddress, queueIndex, gasFeeShares ); const receipt = await processTx.wait(); console.log(`Redemption processed: ${receipt.hash}`); return receipt; } // Usage (operator only) processRedemption( "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB", 0n, // Queue index 0n // No gas fee ); ``` ### Complete V3 Integration Example Complete example showing deposit, balance check, and redemption flow using wagmi: ```typescript import { connectManagerV3, connectVault, getContractAddresses, Chain, } from "yieldfi-sdk"; import { ethers } from "ethers"; import { useAccount, useWalletClient } from "wagmi"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; function VaultOperations() { const { address } = useAccount(); const { data: walletClient } = useWalletClient(); const completeV3VaultFlow = async ( vaultAddress: string, assetAddress: string ) => { if (!walletClient || !address) { throw new Error("Wallet not connected"); } const provider = new ethers.BrowserProvider(walletClient); const signer = await provider.getSigner(); const contracts = getContractAddresses(Chain.ETHEREUM); // Connect to contracts const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, signer); const vault = connectVault(vaultAddress, VaultABI, provider); const assetToken = new ethers.Contract( assetAddress, [ "function approve(address spender, uint256 amount) returns (bool)", "function balanceOf(address account) view returns (uint256)", "function decimals() view returns (uint8)", ], signer ); // 1. Check current vault balance const currentShares = await vault.balanceOf(address); const currentAssets = await vault.convertToAssets(currentShares); console.log(`Current Vault Balance:`); console.log(` Shares: ${ethers.formatUnits(currentShares, 18)}`); console.log(` Assets: ${ethers.formatUnits(currentAssets, 6)}`); // 2. Deposit assets const depositAmount = ethers.parseUnits("100", 6); // 100 USDC const assetBalance = await assetToken.balanceOf(address); if (assetBalance < depositAmount) { console.log("Insufficient asset balance"); return; } // Calculate minimum shares with slippage protection const previewShares = await vault.previewDeposit(depositAmount); const minShares = (previewShares * 95n) / 100n; // 5% slippage tolerance // Approve and deposit const approveTx = await assetToken.approve(managerV3.target, depositAmount); await approveTx.wait(); const depositTx = await managerV3.deposit( vaultAddress, assetAddress, depositAmount, address, minShares, ethers.ZeroHash // referralCode ); await depositTx.wait(); console.log(`Deposit successful: ${depositTx.hash}`); // 3. Check new balance const newShares = await vault.balanceOf(address); const newAssets = await vault.convertToAssets(newShares); console.log(`New Vault Balance:`); console.log(` Shares: ${ethers.formatUnits(newShares, 18)}`); console.log(` Assets: ${ethers.formatUnits(newAssets, 6)}`); // 4. Request redemption (redeem half) const redeemShares = newShares / 2n; const redeemTx = await managerV3.requestRedemption( vaultAddress, redeemShares, address, address ); await redeemTx.wait(); console.log(`Redemption requested: ${redeemTx.hash}`); // 5. Check redemption queue const queueLength = await managerV3.getRedemptionQueueLength(vaultAddress); console.log(`Redemption Queue Length: ${queueLength}`); // 6. Check updated balance (shares are locked, not burned) const lockedShares = await vault.lockedShares(address); const activeShares = await vault.balanceOf(address); console.log(`Active Shares: ${ethers.formatUnits(activeShares, 18)}`); console.log(`Locked Shares: ${ethers.formatUnits(lockedShares, 18)}`); // 7. Cancel redemption (optional) if (queueLength > 0n) { const cancelTx = await managerV3.cancelRedemption( vaultAddress, queueLength - 1n ); await cancelTx.wait(); console.log(`Redemption cancelled: ${cancelTx.hash}`); } }; return (
); } ``` #### Using Browser Provider Directly ```typescript import { connectManagerV3, connectVault, getContractAddresses, Chain, } from "yieldfi-sdk"; import { ethers } from "ethers"; import ManagerV3ABI from "yieldfi-sdk/abis/v3/Manager.json"; import VaultABI from "yieldfi-sdk/abis/v3/Vault.json"; async function completeV3VaultFlow() { if (!window.ethereum) { throw new Error("No wallet found"); } const provider = new ethers.BrowserProvider(window.ethereum); const signer = await provider.getSigner(); const userAddress = await signer.getAddress(); const contracts = getContractAddresses(Chain.ETHEREUM); const vaultAddress = "0x5bE91d34FeFbB7554497a74e25dC6df96bFef5DB"; const assetAddress = "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"; // USDC // Connect to contracts const managerV3 = connectManagerV3(contracts.manager, ManagerV3ABI, signer); const vault = connectVault(vaultAddress, VaultABI, provider); const assetToken = new ethers.Contract( assetAddress, [ "function approve(address spender, uint256 amount) returns (bool)", "function balanceOf(address account) view returns (uint256)", ], signer ); // 1. Check current vault balance const currentShares = await vault.balanceOf(userAddress); const currentAssets = await vault.convertToAssets(currentShares); console.log(`Current Vault Balance:`); console.log(` Shares: ${ethers.formatUnits(currentShares, 18)}`); console.log(` Assets: ${ethers.formatUnits(currentAssets, 6)}`); // 2. Deposit assets const depositAmount = ethers.parseUnits("100", 6); const assetBalance = await assetToken.balanceOf(userAddress); if (assetBalance < depositAmount) { console.log("Insufficient asset balance"); return; } // Calculate minimum shares with slippage protection const previewShares = await vault.previewDeposit(depositAmount); const minShares = (previewShares * 95n) / 100n; // 5% slippage tolerance // Approve and deposit await assetToken.approve(managerV3.target, depositAmount); const depositTx = await managerV3.deposit( vaultAddress, assetAddress, depositAmount, userAddress, minShares, ethers.ZeroHash ); await depositTx.wait(); console.log(`Deposit successful: ${depositTx.hash}`); // 3. Check new balance const newShares = await vault.balanceOf(userAddress); const newAssets = await vault.convertToAssets(newShares); console.log(`New Vault Balance:`); console.log(` Shares: ${ethers.formatUnits(newShares, 18)}`); console.log(` Assets: ${ethers.formatUnits(newAssets, 6)}`); // 4. Request redemption const redeemShares = newShares / 2n; const redeemTx = await managerV3.requestRedemption( vaultAddress, redeemShares, userAddress, userAddress ); await redeemTx.wait(); console.log(`Redemption requested: ${redeemTx.hash}`); // 5. Check redemption queue const queueLength = await managerV3.getRedemptionQueueLength(vaultAddress); console.log(`Redemption Queue Length: ${queueLength}`); // 6. Check locked shares const lockedShares = await vault.lockedShares(userAddress); const activeShares = await vault.balanceOf(userAddress); console.log(`Active Shares: ${ethers.formatUnits(activeShares, 18)}`); console.log(`Locked Shares: ${ethers.formatUnits(lockedShares, 18)}`); } completeV3VaultFlow(); ``` ### V3 Contract Features #### Manager V3 Contract * **Deposit**: Deposit assets to vaults with slippage protection (`minShares`) * **Request Redemption**: Request redemption (shares are locked, not burned) * **Cancel Redemption**: Cancel pending redemption requests * **Process Redemption**: Process redemptions from queue (operator only) * **Redemption Queue**: Query queue entries and status #### Vault Contract (ERC-4626) * **Standard ERC-4626**: Full ERC-4626 vault interface * **Share Locking**: Shares can be locked for redemption requests * **Asset Conversion**: `convertToAssets()` and `convertToShares()` methods * **Preview Functions**: Preview deposit/redeem amounts ### Getting Contract Addresses ```typescript import { getContractAddresses, Chain } from "yieldfi-sdk"; const contracts = getContractAddresses(Chain.ETHEREUM); console.log(`Manager V3: ${contracts.manager}`); // Vault addresses are specific to each vault // Get them from the Vault API or registry ``` ### Type Safety The SDK provides full TypeScript types for v3 contracts: ```typescript import type { ManagerV3, VaultContract } from "yieldfi-sdk"; import { Contract } from "ethers"; import { useWalletClient } from "wagmi"; function TypedContractExample() { const { data: walletClient } = useWalletClient(); const useTypedContracts = async () => { if (!walletClient) return; const provider = new ethers.BrowserProvider(walletClient); const signer = await provider.getSigner(); const managerV3 = new Contract( contracts.manager, ManagerV3ABI, signer ) as unknown as ManagerV3; const vault = new Contract( vaultAddress, VaultABI, provider ) as unknown as VaultContract; // Full type safety and IntelliSense await managerV3.deposit(/* ... */); await vault.balanceOf(/* ... */); }; } ``` ### Wallet Integration Best Practices #### Always Check Wallet Connection ```typescript if (!window.ethereum) { throw new Error("Please install a wallet like MetaMask"); } // Or with wagmi const { isConnected } = useAccount(); if (!isConnected) { throw new Error("Please connect your wallet"); } ``` #### Handle User Rejection ```typescript try { const tx = await managerV3.deposit(/* ... */); await tx.wait(); } catch (error: any) { if (error.code === 4001) { // User rejected the transaction console.log("Transaction rejected by user"); } else { throw error; } } ``` #### Request Account Access ```typescript // Request account access if needed await window.ethereum.request({ method: "eth_requestAccounts" }); // Or with wagmi, use useConnect hook const { connect } = useConnect(); ``` # Transaction History Examples for working with transaction history. ### Get User Transactions ```typescript import { YieldFiSDK } from "yieldfi-sdk"; async function getUserTransactions() { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const accessToken = localStorage.getItem("accessToken"); if (!accessToken) { console.log("Please login first"); return; } // Get user's transactions (automatically filtered by authenticated address) const transactions = await sdk.vault.getTransactions( { chainId: 1, page: 1, pageSize: 20, }, accessToken ); console.log(`Found ${transactions.pagination.total} transactions\n`); transactions.data.forEach((tx) => { console.log(`Transaction ${tx.id}:`); console.log(` Type: ${tx.type}`); console.log(` Status: ${tx.status}`); console.log(` Amount: ${tx.amount} ${tx.assetSymbol}`); console.log(` Vault: ${tx.vaultAddress}`); console.log(` Timestamp: ${new Date(tx.timestamp).toLocaleString()}`); console.log(` Hash: ${tx.txnHash}`); console.log(""); }); } getUserTransactions(); ``` ### Filter Transactions ```typescript async function filterTransactions() { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const accessToken = localStorage.getItem("accessToken"); // Get deposits only const deposits = await sdk.vault.getTransactions( { chainId: 1, type: "deposit", status: "PROCESSED", startDate: "2024-01-01T00:00:00.000Z", endDate: "2024-01-31T23:59:59.999Z", }, accessToken ); console.log(`Deposits in January: ${deposits.pagination.total}`); // Get redemptions only const redemptions = await sdk.vault.getTransactions( { chainId: 1, type: "redemption", status: "PROCESSED", }, accessToken ); console.log(`Total redemptions: ${redemptions.pagination.total}`); } filterTransactions(); ``` ### Get Transaction by Hash ```typescript async function getTransactionByHash(txnHash: string, chainId: number) { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const accessToken = localStorage.getItem("accessToken"); try { const transaction = await sdk.vault.getTransactionByHash( txnHash, chainId, accessToken ); console.log(`Transaction Found:`); console.log(` ID: ${transaction.transaction.id}`); console.log(` Type: ${transaction.transaction.type}`); console.log(` Status: ${transaction.transaction.status}`); console.log(` Amount: ${transaction.transaction.amount}`); console.log(` User: ${transaction.transaction.userAddress}`); } catch (error) { console.error("Transaction not found or access denied"); } } getTransactionByHash( "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef", 1 ); ``` ### Get Filter Options ```typescript async function showFilterOptions() { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const accessToken = localStorage.getItem("accessToken"); const filterOptions = await sdk.vault.getTransactionFilterOptions(accessToken); console.log("Available Filters:"); console.log(` Chain IDs: ${filterOptions.filters.chainIds.join(", ")}`); console.log(` Statuses: ${filterOptions.filters.statuses.join(", ")}`); console.log(` Types: ${filterOptions.filters.types.join(", ")}`); } showFilterOptions(); ``` ### Transaction Summary ```typescript async function transactionSummary() { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const accessToken = localStorage.getItem("accessToken"); // Get all transactions const allTransactions = await sdk.vault.getTransactions( { chainId: 1, page: 1, pageSize: 100, // Get more for summary }, accessToken ); // Calculate summary const summary = { total: allTransactions.pagination.total, deposits: allTransactions.data.filter((tx) => tx.type === "deposit").length, redemptions: allTransactions.data.filter((tx) => tx.type === "redemption").length, processed: allTransactions.data.filter((tx) => tx.status === "PROCESSED").length, pending: allTransactions.data.filter((tx) => tx.status === "PENDING").length, }; console.log("=== Transaction Summary ==="); console.log(`Total: ${summary.total}`); console.log(`Deposits: ${summary.deposits}`); console.log(`Redemptions: ${summary.redemptions}`); console.log(`Processed: ${summary.processed}`); console.log(`Pending: ${summary.pending}`); } transactionSummary(); ``` # Vault Operations Complete examples for common vault operations. ### Display Vault List ```typescript import { YieldFiSDK } from "yieldfi-sdk"; async function displayVaultList() { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); // Get all vaults const vaults = await sdk.vault.getVaults({ chainId: 1, page: 1, pageSize: 20, }); console.log(`Found ${vaults.pagination.total} vaults\n`); vaults.data.forEach((vault) => { console.log(`${vault.name} (${vault.symbol})`); console.log(` Key: ${vault.vaultKey}`); console.log(` TVL: $${vault.metrics.tvl}`); console.log(` APY (7d): ${vault.metrics.apy7d}%`); console.log(` Strategy: ${vault.strategy}`); console.log(""); }); } displayVaultList(); ``` ### Get Vault Details ```typescript async function getVaultDetails(vaultKey: string, chainId: number) { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); // Get vault information const vault = await sdk.vault.getVaultByKey(vaultKey, chainId); console.log(`Vault: ${vault.vault.name}`); console.log(`Description: ${vault.vault.description}`); console.log(`Manager: ${vault.vault.manager}`); // Get whitelisted assets const assets = await sdk.vault.getWhitelistedAssets(vaultKey, chainId, false); console.log(`\nWhitelisted Assets (${assets.assets.length}):`); assets.assets.forEach((asset) => { console.log(` ${asset.symbol}: ${asset.address}`); }); // Get FAQs const faqs = await sdk.vault.getVaultFaqs(vaultKey, chainId); if (faqs.faqs.length > 0) { console.log(`\nFAQs:`); faqs.faqs.forEach((faq) => { console.log(` Q: ${faq.question}`); console.log(` A: ${faq.answer}\n`); }); } } getVaultDetails("yusd", 1); ``` ### Check Asset Whitelisting ```typescript async function checkAsset(vaultKey: string, assetAddress: string, chainId: number) { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); const checkResult = await sdk.vault.checkAssetWhitelisted( vaultKey, assetAddress, chainId ); if (checkResult.isWhitelisted) { console.log("✅ Asset is whitelisted"); console.log(`Deposit Enabled: ${checkResult.depositEnabled ? "Yes" : "No"}`); console.log(`Redeem Enabled: ${checkResult.redeemEnabled ? "Yes" : "No"}`); } else { console.log("❌ Asset is not whitelisted"); } } checkAsset( "yusd", "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // USDC 1 ); ``` ### Protocol Statistics Dashboard ```typescript async function protocolDashboard() { const sdk = await YieldFiSDK.create({ gatewayUrl: "https://gw.yield.fi", }); // Get protocol stats const stats = await sdk.vault.getProtocolStats(); console.log("=== Protocol Statistics ==="); console.log(`Total TVL: $${stats.stats.totalTvl}`); console.log(`Max APY: ${stats.stats.maxApy}%`); console.log(`Total Users: ${stats.stats.totalUsers}`); console.log(`Total Fund Managers: ${stats.stats.totalFundManagers}`); console.log(`YPO: ${stats.stats.ypo}`); // Get strategies const strategies = await sdk.vault.getStrategies(); console.log(`\n=== Available Strategies ==="); strategies.strategies.forEach((strategy) => { console.log(` - ${strategy}`); }); // Get vaults by strategy const defiVaults = await sdk.vault.getVaults({ chainId: 1, strategy: "DeFi", }); console.log(`\n=== DeFi Vaults: ${defiVaults.pagination.total} ===`); } protocolDashboard(); ``` # Brand Kit The YieldFi brand kit includes guidelines for using our logo & icon across collaterals. It provides links to various logo formats (SVG and PNG) and a color palette. ## YieldFi Logo
Cover image
PNG/files/IQa7qHFHj0IOKw6lW3l6SVG/files/WimXAywcfZx0h2YqAilY/files/MtqmdGzgsv6Bf2yKS3KL
PNG/files/NqTV8kuQATaklw2HI7aQSVG/files/0vyPyuR3jJtDfYd3sbhD/files/hV8IhacJDaMS1JlpJlCK
PNG/files/TYE4ztuXL9Eewqvu6X1lSVG/files/ZtP3hdptYzpLQzu5LQPV/files/g11L6vooHOile0eQtrYd
## YieldFi Icon
Cover image
PNG/files/n5aPC1feS3j2EpUjUAqnSVG/files/JARR2Dd6EN25JXkHxtow/files/rdT4SgD15Mx6WrBuCqFg
PNG/files/F9pf7KM018IJbZoPKHNESVG/files/wILEIya2l0x2nEDlR6d0/files/iCT4bhGXZYrMHZMdKEKr
PNG/files/EEzfiFqhacG1xZvMpoNVSVG/files/8DVzIX5WUvmYznaWu1id/files/iYFlsaRybznNdUCDfrJO
## YieldFi Points
Cover image
PNG/files/OlmpVviVdYjn4alml9vGSVG/files/tTeY0wj2ZEFFLS6Ifg8g/files/D4PbdpyOQvFmJqi11Ewc
## YieldFi Vaults
Cover image
PNG/files/o57LuC602gt3hS1eN9MgSVG/files/53blPgy1vPNylntFXo1t/files/wKXefK2rYwz4zUpdy6SA
PNG/files/DQL7GXtAbqFyCvSfH1R3SVG/files/tusptrXg9HV5u7cDXM2O/files/3fYPviJLKfOWOWoCB0kp
# Curator App YieldFi provides curators—asset managers, strategy teams, and trading desks—with a purpose-built operating stack to launch and manage tokenized vaults with institutional-grade controls and transparency. Instead of stitching together custody, execution accounts, reporting, and investor analytics across multiple vendors, curators get a unified interface designed for day-to-day portfolio operations and scalable capital formation. At the center is the **Curator App**, where curators can view and manage **their vaults** in one place. For each vault, the app surfaces real-time performance and operational telemetry, including **NAV and APY history, TVL, exposure breakdowns, liquidity profile, leverage, and risk metrics such as VaR/CVaR**, along with operational indicators like redemption behavior and SLA tracking (where applicable). This makes curator performance auditable and comparable—reducing diligence friction and improving investor confidence. Curators also receive institutional execution rails out of the box. The Curator App provides direct access to **Institutional grade MPC custody wallets** for secure asset management within DeFi, enabling controlled signing and operational segregation. For centralized execution venues, curators can access dedicated **exchange SMA / sub-accounts** with **Custody &** **Off Exchange Settlement** solutions used to run strategies with controlled permissions and clean accounting. This mirrors how professional managers operate in traditional markets, while keeping issuance, reporting, and transparency native to the vault. Together, the Curator App, MPC wallets, and exchange sub-accounts form a complete curator infrastructure layer—built to help managers launch faster, operate safely, and scale AUM with verifiable performance and risk reporting from day one. # Points Program YieldFi Points are earned through on-chain activity and community participation within the YieldFi ecosystem. These points will form the foundation for current and future rewards, multipliers, and community benefits. YieldFi Points are distributed across multiple Seasons ### Season 1 (LIVE) Season 1 rewards early participants who actively contribute to the YieldFi ecosystem through minting, staking, lending, LPing, and engaging with partner protocols. * Duration: Ongoing * Key Focus: On-chain activities and marketing campaigns Season 1 sets the foundation for future reward programs. Your points earned in this season may carry forward benefits. ### How Points Are Earned Points can be earned through various activities: * Minting & Holding vault tokens * Supplying borrow assets to lending markets * Pendle LP & YT tokens * Referral program * Participating in quests, campaigns, and social engagement Each activity earns a base points payout, with additional multipliers applied where relevant. You can track all eligible activities and strategies on the [DeFi Dashboard](https://v2.yield.fi/defi). #### 1. DeFi Ecosystem Participation Users earn points by minting YieldFi vault tokens and deploying them across integrated DeFi platforms. #### 2. Campaigns YieldFi periodically runs short-term campaigns where users can complete specific actions to earn bonus points. Stay tuned to our Telegram and Twitter for live campaign announcements. #### 3. Community Support Users who actively support the YieldFi community through meaningful engagement (e.g., Discord activity, Twitter posts, quest completions) can earn points at the team’s discretion. #### 4. Referrals Earn additional points by referring new users. * You receive 10% of the points earned by the person you referred. * These are bonus points — your referral does not lose any of their points. * Referral codes must be applied before a wallet mints vault tokens. Codes are permanent once applied. Generate and manage your referral code in the [Referral page](https://v2.yield.fi/referral). ### Multipliers Each activity using a whitelisted asset has an associated multiplier. Multipliers define how many points you earn per day. | Whitelisted Asset | Multiplier | | ------------------------------- | ---------- | | vyTokens | 5x | | Borrow Asset in Lending Markets | 2.5x | | yTokens | 1x | The multiplier for each activity using the whitelisted assets are decided by which category it falls under in the table below. | Activity | Multiplier | Description | | --------------------------------------- | ---------- | ------------------------------------- | | Hold vyTokens | 5x | Earn 5 points per $1 per day | | Hold YT | 5x | On Yield Markets, Until market expiry | | Pendle LP Position | 5x | On Yield Markets, Until market expiry | | Supply borrow assets to lending markets | 2.5x | On Lending Markets | | Hold yTokens | 1x | Earn 1 point per $1 per day | *** # Ethereum All YieldFi v3 contract addresses on Ethereum Mainnet. ### Core Contracts | Contract | Address | Explorer | | ------------ | -------------------------------------------- | ------------------------------------------------------------------------------------ | | Manager V3 | `0x08fB9833A5a84d5bCEcDF5a4a635d33260C5F05C` | [Etherscan](https://etherscan.io/address/0x08fB9833A5a84d5bCEcDF5a4a635d33260C5F05C) | | Registry | `0x9A766451B18DF401e39109F8A9F06355Be0f7505` | [Etherscan](https://etherscan.io/address/0x9A766451B18DF401e39109F8A9F06355Be0f7505) | | VaultFactory | `0x5c46Ed83fC4446282a75d30375d993357aBa3878` | [Etherscan](https://etherscan.io/address/0x5c46Ed83fC4446282a75d30375d993357aBa3878) | ### Supporting Contracts | Contract | Address | Explorer | | --------------- | -------------------------------------------- | ------------------------------------------------------------------------------------ | | Administrator | `0x803438689B101aEDe853c9604D32AA80f0b3fce1` | [Etherscan](https://etherscan.io/address/0x803438689B101aEDe853c9604D32AA80f0b3fce1) | | FeatureRegistry | `0xC9eC62D1E2aDa282C3544178664D98cf62849961` | [Etherscan](https://etherscan.io/address/0xC9eC62D1E2aDa282C3544178664D98cf62849961) | | PriceOracle | `0x67DBA3444a99B9788E78932015312b2550241dF5` | [Etherscan](https://etherscan.io/address/0x67DBA3444a99B9788E78932015312b2550241dF5) | | NAV | `0x95178e55fE7edD0792b9819B7654C9Ee076832fa` | [Etherscan](https://etherscan.io/address/0x95178e55fE7edD0792b9819B7654C9Ee076832fa) | ### Feature Contracts | Contract | Address | Explorer | | ---------------- | -------------------------------------------- | ------------------------------------------------------------------------------------ | | GreenlistFeature | `0x13a9f3f09588c4E5C6Cddb1164398630bf929Ff0` | [Etherscan](https://etherscan.io/address/0x13a9f3f09588c4E5C6Cddb1164398630bf929Ff0) | | LimitsFeature | `0xbbb6Edf1811fda36F591C617b51d2d43E4963aa6` | [Etherscan](https://etherscan.io/address/0xbbb6Edf1811fda36F591C617b51d2d43E4963aa6) | ### Adapters | Contract | Address | Explorer | | ----------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------ | | ChainlinkOracle Adapter | `0xf6cdCf759E39C29Eb843Cbfd549a7D9B82aBdbA4` | [Etherscan](https://etherscan.io/address/0xf6cdCf759E39C29Eb843Cbfd549a7D9B82aBdbA4) | ### Example Vaults | Vault | Address | Explorer | | ------ | -------------------------------------------- | ------------------------------------------------------------------------------------- | | yDemo | `0x3EdAe9C342bA1c0Ece710db1F0C7BCCEC24Ee668` | [Etherscan](https://etherscan.io/address/0x3EdAe9C342bA1c0Ece710db1F0C7BCCEC24Ee668) | | yPrism | `0xdd5eff0756db08bad0ff16b66f88f506e7318894` | [Etherscan](https://etherscan.io/address/00xdd5eff0756db08bad0ff16b66f88f506e7318894) | ### Network * **Chain ID**: `1` * **Network**: Ethereum Mainnet * **Explorer**: [Etherscan](https://etherscan.io) # BSC All YieldFi v3 contract addresses on Ethereum Mainnet. ### Core Contracts | Contract | Address | Explorer | | ------------ | -------------------------------------------- | ---------------------------------------------------------------------------------- | | Manager V3 | `0x08fB9833A5a84d5bCEcDF5a4a635d33260C5F05C` | [BSC Scan](https://bscscan.com/address/0x08fB9833A5a84d5bCEcDF5a4a635d33260C5F05C) | | Registry | `0x9A766451B18DF401e39109F8A9F06355Be0f7505` | [BSC Scan](https://bscscan.com/address/0x9A766451B18DF401e39109F8A9F06355Be0f7505) | | VaultFactory | `0x5c46Ed83fC4446282a75d30375d993357aBa3878` | [BSC Scan](https://bscscan.com/address/0x5c46Ed83fC4446282a75d30375d993357aBa3878) | ### Supporting Contracts | Contract | Address | Explorer | | --------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | | Administrator | `0x803438689B101aEDe853c9604D32AA80f0b3fce1` | [BSC Scan](https://bscscan.com/address/0x803438689B101aEDe853c9604D32AA80f0b3fce1) | | FeatureRegistry | `0xC9eC62D1E2aDa282C3544178664D98cf62849961` | [BSC Scan](https://bscscan.com/address/0xC9eC62D1E2aDa282C3544178664D98cf62849961) | | PriceOracle | `0x67DBA3444a99B9788E78932015312b2550241dF5` | [BSC Scan](https://bscscan.com/address/0x67DBA3444a99B9788E78932015312b2550241dF5) | | NAV | `0x95178e55fE7edD0792b9819B7654C9Ee076832fa` | [BSC Scan](https://bscscan.com/address/0x95178e55fE7edD0792b9819B7654C9Ee076832fa) | ### Feature Contracts | Contract | Address | Explorer | | ---------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | | GreenlistFeature | `0x13a9f3f09588c4E5C6Cddb1164398630bf929Ff0` | [BSC Scan](https://bscscan.com/address/0x13a9f3f09588c4E5C6Cddb1164398630bf929Ff0) | | LimitsFeature | `0xbbb6Edf1811fda36F591C617b51d2d43E4963aa6` | [BSC Scan](https://bscscan.com/address/0xbbb6Edf1811fda36F591C617b51d2d43E4963aa6) | ### Adapters | Contract | Address | Explorer | | ----------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | | ChainlinkOracle Adapter | `0xf6cdCf759E39C29Eb843Cbfd549a7D9B82aBdbA4` | [BSC Scan](https://bscscan.com/address/0xf6cdCf759E39C29Eb843Cbfd549a7D9B82aBdbA4) | ### Example Vaults | Vault | Address | Explorer | | ------ | -------------------------------------------- | ---------------------------------------------------------------------------------- | | yPrism | `0xdd5eff0756db08bad0ff16b66f88f506e7318894` | [BSC Scan](https://bscscan.com/address/0x585EcA2C4a45AcB171e01e5e65F4f87D7845abd5) | ### Network * **Chain ID**: 56 * **Network**: Binance Smart Chain * **Explorer**: [BSC Scan](https://bscscan.com/) # Audits YieldFi smart contracts are audited on an ongoing basis, and we commission audits **for each major upgrade** to ensure new functionality and changes receive independent security review. Below is the audit history in reverse chronological order: ## V3 Contracts (14th Jan, 2026) [**Sherlock Audit Report**](https://github.com/sherlock-protocol/sherlock-reports/blob/main/audits/2026.02.03%20-%20Final%20-%20YieldFi%20Collaborative%20Audit%20Report%201770139561.pdf) The Sherlock audit report on Vault smart contracts confirmed the absence of critical and high level issues. Medium-level, Low-level and informational recommendations were implemented promptly. {% file src="/files/koWKngX3HUUynBqig0Jo" %} ## vyToken Contracts (17th June, 2025) [**Cyfrin Audit Report**](https://github.com/Cyfrin/cyfrin-audit-reports/blob/main/reports/2025-06-17-cyfrin-yieldfi-pr19-vytoken-v2.2.pdf) The Cyfrin audit report on YieldFi’s DeFi Vault smart contracts confirmed the absence of critical, high and medium level issues. Low-level and informational recommendations were implemented promptly. {% file src="/files/IqQx8uMcB83jNKoPbVXa" %} ## yToken Contracts (25th April, 2025) #### [**Cyfrin Audit Report**](https://github.com/Cyfrin/cyfrin-audit-reports/blob/main/reports/2025-04-24-cyfrin-yieldfi-v2.0.pdf) The Cyfrin audit report on YieldFi’s smart contracts highlighted 2 critical and 1 high-level issues along with a few medium and low-level issues, which were implemented promptly and verified by the auditors. {% file src="/files/vJxQLU4htRB3BwAByW4A" %} ## yToken Contracts (12th Nov, 2024) #### [**Halborn Audit Report**](https://www.halborn.com/audits/yieldfi) The Halborn audit report on YieldFi’s smart contracts confirmed the absence of critical and high-level issues. Medium and low-level recommendations were implemented promptly. {% file src="/files/UitSFs9XendoQKy6RC6q" %} #### [**Cantina Solo Audit Report**](https://cantina.xyz/portfolio/d13d31e4-72c7-404c-b281-f6ccdd3c534f) The Cantina solo audit report on YieldFi’s smart contracts confirmed the absence of critical and high-level issues. Medium and low-level recommendations were implemented promptly. {% file src="/files/2v8UlH0RywXyi9gg9Uft" %} # Hypernative Monitoring #### Why we use it Smart contract audits significantly reduce risk, but they are a **point-in-time review**. After deployment, risk can come from new integrations, changing market conditions, operational mistakes, or novel attack patterns. To add a **runtime security layer** on top of audits, YieldFi is implementing **Hypernative** as a real-time monitoring and threat-detection system for our onchain infrastructure. #### What we monitor We configure monitoring around the behaviors that matter for vault safety and user funds, including: * **Contract activity and privileged actions** (e.g., role changes, parameter updates, timelock executions). * **Abnormal transaction patterns** that may indicate exploitation attempts (unexpected call paths, unusual volumes, rapid repeated interactions, suspicious counterparties). * **Integration risk signals** from dependencies that vaults may rely on (e.g., oracle anomalies, protocol incidents, liquidity events), where relevant to a vault’s operation. * **Operational health indicators** related to issuance/redemption flows and other critical paths. #### Alerting and response workflow Hypernative alerts are routed to our operators in real time and mapped to internal **incident runbooks**. Depending on severity, the workflow includes escalation, triage, and predefined actions—such as restricting specific flows, tightening operational limits, or invoking safeguards that exist within the vault’s control framework (wherever supported). The goal is to **detect earlier, respond faster, and reduce blast radius**. #### Scope and limitations Monitoring does not prevent every loss event, and it does not replace secure engineering, audits, or conservative operations. Alerts can be noisy or incomplete, and automated actions only work when the underlying contracts and procedures support them. We treat Hypernative as an additional **defense tool in our armour**—an additional layer that improves visibility and response during live operations. # Legacy Smart Contract Addresses ### V2 Address
ChainContract Addresses
EthereumManager, yUSD, vyUSD, yBTC, yETH, vyETH, vyBTC
ArbitrumManager, yUSD, vyUSD, yETH, vyETH
BaseManager, yUSD, vyUSD, yETH, vyETH
OptimismManager, yUSD, vyUSD
SonicManager, yUSD, vyUSD
PlumeManager, yUSD, vyUSD
KatanaManager, yUSD, vyUSD
BNBManager, yUSD, vyUSD
AvalancheManager, yUSD, vyUSD
TACManager, yUSD, vyUSD
PlasmaManager, yUSD, vyUSD
LineaManager, yUSD, vyUSD
SagaManager, yUSD, vyUSD, yETH
Chain
EthereumLockbox, Bridge
ArbitrumBridge
BaseBridge
OptimismBridge
SonicBridge
PlumeBridge
KatanaBridge
BNBBridge
AvalancheBridge
PlasmaBridge
LineaBridge
### V1 Addresses | Chain | Contract Addresses | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Ethereum | [Manager](https://etherscan.io/address/0x88538b8199238efe82f53862b1eaf5e705993935), [yUSD](https://etherscan.io/token/0x1ce7d9942ff78c328a4181b9f3826fee6d845a97), [sUSD](https://etherscan.io/address/0x4f8e1426a9d10bddc11d26042ad270f16ccb95f2), [Receipt](https://etherscan.io/address/0x154E5dD6D7A0efBB343A3f2146a31590eEb8deED), [Bridge](https://etherscan.io/address/0x8484E4440E22683573e94b4eb040802307942BDC) | | Arbitrum | [Manger](https://arbiscan.io/address/0x9305a0cc13293b69dee0b9d281d21144b029bdff), [yUSD](https://arbiscan.io/address/0x895e15020C3f52ddD4D8e9514eB83C39F53B1579), [sUSD](https://arbiscan.io/address/0x4cA1Da924629b53615E2C3c2389FC8760F92c87b), [Receipt](https://arbiscan.io/address/0x87e8298ff74d5542d72b7ff07475ddf11f6f3dec), [Bridge](https://arbiscan.io/address/0x9f4a9ef56b164da0bf06218030c7c16d592cedcc) | | Base | [Manger](https://basescan.org/address/0x9305a0cc13293b69dee0b9d281d21144b029bdff), [yUSD](https://basescan.org/address/0x895e15020C3f52ddD4D8e9514eB83C39F53B1579), [sUSD](https://basescan.org/address/0x4cA1Da924629b53615E2C3c2389FC8760F92c87b), [Receipt](https://basescan.org/address/0x87e8298ff74d5542d72b7ff07475ddf11f6f3dec), [Bridge](https://etherscan.io/address/0x9f4a9ef56b164da0bf06218030c7c16d592cedcc) | | Optimism | [Manger](https://optimistic.etherscan.io/address/0xabd5e0c639d09272688854c43d47b309769413ef), [yUSD](https://optimistic.etherscan.io/address/0x895e15020c3f52ddd4d8e9514eb83c39f53b1579), [sUSD](https://optimistic.etherscan.io/address/0x4cA1Da924629b53615E2C3c2389FC8760F92c87b), [Receipt](https://optimistic.etherscan.io/address/0xd623117f3f6190e3144038b5f0f0c2db5f319939), [Bridge](https://optimistic.etherscan.io/address/0x1ce7d9942ff78c328a4181b9f3826fee6d845a97) | | Tron | [Manger](https://tronscan.org/#/contract/TEpz1XQQh7dmXRwp6t8fGEL5WqtGe4xKvD/code), [yUSD](https://tronscan.org/#/contract/TMjC852Swr3tMz3AvXXkzAQqQWY6cJD2uv), [sUSD](https://tronscan.org/#/contract/TRDoiuk5ovrP6rugqx9ybUY6Pft9uVea82), [Receipt](https://tronscan.org/#/contract/TNkAR1NtAFTjeF8dV9JqQHKHSZoMSRqh7H/code) | | Arbitrum Sapolia (Testnet) | [Manger](https://sepolia.arbiscan.io/address/0xb4a7914f7f99dcb62ee13554e4ea75e9a4f2578d), [yUSD](https://sepolia.arbiscan.io/address/0x2920BBbE7998c7a3ad0Ee87408149a0C6DEAabc2), [sUSD](https://sepolia.arbiscan.io/address/0x683e1b87bdab4f150016993934a43aa689a346cA), [Receipt](https://sepolia.arbiscan.io/address/0x8e085466D0e68eEcE8306A29DD6Ce13e37b3c76a), [Bridge](https://sepolia.arbiscan.io/address/0xa5e9ebEc1aE66777A6270f54534f8387a305E8B4) | # Terms & Conditions Issuer: YieldFi\ Governing law: British Virgin Islands (“BVI”) law\ Website: yield.fi (or successor domain) ### IMPORTANT NOTICE PLEASE READ THESE TERMS CAREFULLY. THEY AFFECT YOUR LEGAL RIGHTS AND OBLIGATIONS. INFORMATION ON OUR WEBSITE OR IN MARKETING MATERIALS IS FOR GENERAL DESCRIPTION ONLY, MAY CHANGE OVER TIME, AND DOES NOT FORM PART OF THESE TERMS OR ANY TOKEN TERMS UNLESS EXPRESSLY INCORPORATED BY REFERENCE. NO REGULATOR HAS AUTHORISED OR APPROVED THESE TERMS OR ANY TOKEN TERMS. DEALING IN TOKENS IS HIGH RISK AND MAY RESULT IN A TOTAL LOSS OF CAPITAL. TOKENS MAY BE RESTRICTED IN TRANSFERABILITY AND MAY BE ILLIQUID. YOU DO NOT BENEFIT FROM ANY STATUTORY COMPENSATION SCHEME OR DEPOSIT PROTECTION IN RELATION TO TOKENS. IF YOU HAVE NOT DEALT IN CRYPTOASSETS OR TOKENISED PRODUCTS BEFORE, YOU SHOULD SEEK INDEPENDENT PROFESSIONAL ADVICE (LEGAL, TAX, AND FINANCIAL) BEFORE DEALING IN TOKENS. BY DEALING IN TOKENS, YOU CONFIRM YOU HAVE READ, UNDERSTOOD, AND ACCEPTED THESE TERMS AND THE APPLICABLE TOKEN TERMS. *** ### 1. INTRODUCTION AND DOCUMENT HIERARCHY 1.1 These general terms and conditions, together with all schedules, policies, and documents incorporated by reference (together, the “General Terms” and each a “Condition”), apply to all Tokens issued by the Issuer and must be read together with the token-specific terms for the relevant Token or Series (the “Token Terms”). 1.2 The Token Terms set out the commercial and operational parameters for the relevant Series (including, where applicable, denomination, settlement currency, fees, valuation methodology, minting/redemption rules, eligibility restrictions, and risk disclosures). If there is any conflict between the General Terms and the Token Terms, the Token Terms prevail to the extent of the inconsistency. 1.3 Unless stated otherwise, capitalised terms not defined in these General Terms have the meanings given in the relevant Token Terms. 1.4 Nature of Tokens (Blockchain-Based Certificates; Series-Limited Contractual Rights).\ (a) Series issuance. Each Token is issued in respect of a specific Series corresponding to a specific Vault / Product, governed by its Token Terms. Each Series is intended to be operationally and economically independent from other Series.\ (b) What a Token is. Each Token is a blockchain-based contractual certificate recorded via smart contracts on a supported blockchain network. A Token evidences only the Tokenholder’s contractual rights under the Product Documentation for the relevant Series (including, as applicable, minting/redemption mechanics, valuation methodology, fees, eligibility restrictions, and risk disclosures).\ (c) Not equity; no governance. Tokens are not equity and do not confer ownership, governance, voting, or profit-participation rights in the Issuer.\ (d) No ownership in assets. Tokens do not represent any legal or beneficial interest in any underlying assets. Tokenholders do not own Series Assets; they hold only the contractual rights expressly set out in the Product Documentation.\ (e) Bankruptcy-remote segregation (structural ring-fencing). The Issuer operates a segregation framework intended to ring-fence assets and liabilities by Series. The Issuer maintains Series Wallets / Series Accounts and implements operational and contractual controls intended to ensure that Series Assets are held and tracked separately from (i) assets attributable to any other Series and (ii) the Issuer’s Operational Assets.\ (f) Limited recourse by design. Any payment, redemption, or settlement amount payable (if any) in respect of a Token is Series-limited and limited-recourse, restricted to the Series Assets of the relevant Series and subject to the Series Waterfall in Condition 10. *** ### 2. REPRESENTATIONS, ELIGIBILITY, AND COMPLIANCE 2.1 Authority and capacity. You represent and warrant that you are of legal age in your jurisdiction and have full legal capacity to enter into the Product Documentation. If you act on behalf of an entity, you have authority to bind that entity, and references to “you” include that entity. 2.2 Sanctions and restricted persons. You represent and warrant that neither you nor (where applicable) your beneficial owners, directors, officers, authorised persons, or wallets are (i) subject to sanctions, (ii) listed on prohibited or restricted parties lists, or (iii) located, resident, organised, or ordinarily resident in a jurisdiction subject to comprehensive sanctions or otherwise restricted by Applicable Law, in each case as determined by the Issuer acting reasonably. 2.3 Compliance with law. You will comply with all Applicable Laws, including AML/CFT, sanctions, tax, securities/financial promotions, and consumer protection. You will not use Tokens for unlawful purposes or to facilitate unlawful activity. 2.4 No advice; independent assessment. We do not provide legal, tax, investment, accounting, or other professional advice. You have made your own independent assessment of the Tokens, risks, and suitability. *** ### 3. INTERPRETATION AND DEFINITIONS 3.1 Interpretation rules. Headings are for convenience only; singular includes plural; “include” is illustrative; references to statutes include amendments/replacements; “person” includes individuals and entities. 3.2 Dealing in Tokens. “Dealing in” Tokens includes buying, subscribing, receiving, holding, transferring (if enabled), selling, redeeming, staking (if applicable), or otherwise using Tokens. 3.3 Defined terms. In these General Terms: * “Adverse Regulatory Event” means a material change in regulation or interpretation that materially impairs the Issuer’s ability to issue, operate, support, distribute, or comply with Applicable Law in relation to a Series. * “Adverse Tax Event” means a material change in tax law or interpretation that results in a substantial adverse tax consequence to the Issuer related to issuing, operating, or supporting a Series. * “Applicable Law(s)” means all laws, statutes, rules, regulations, orders, sanctions, and regulatory requirements applicable to the Parties in connection with Tokens and the Product Documentation (including AML/CFT and sanctions). * “Business Day” means a day on which banks are open in the BVI and relevant settlement systems identified in the Token Terms (as applicable) are operating. * “Greenlisted / Greenlisting” means completion of onboarding and satisfaction of KYC/AML Requirements, as confirmed by the Issuer. * “Insolvency Event” has the meaning in Condition 17.3. * “Issuer Call Option” means, if specified in the Token Terms, the Issuer’s right to initiate a Series wind-down or redemption/unwind procedures due to events beyond reasonable control, including Adverse Regulatory Events, Adverse Tax Events, war/terrorism, natural disasters, or cessation of operations. * “KYC/AML Requirements” means the Issuer’s onboarding, identification, verification, AML/CFT, sanctions screening, and related processes. * “Market Disruption Event” has the meaning in Condition 6.1. * “Operational Assets” means the Issuer’s own assets used to run its business (treasury, revenues, equity capital, and general corporate assets), excluding Series Assets. * “Product Documentation” means these General Terms and the applicable Token Terms, together with schedules/policies incorporated by reference, as amended in accordance with these General Terms. * “Redemption Amount” means the amount payable on redemption in the Settlement Currency calculated under the Token Terms (net of fees and properly attributable costs). * “Series” means a product-specific issuance of Tokens governed by Series-specific Token Terms and operated with segregated asset flows. * “Series Assets” means the assets attributable to a Series, including deposits received for minting that Series, assets acquired/deployed for that Series, proceeds, recoveries, and rights/receivables attributable to that Series. * “Series Liabilities” means liabilities properly attributable to a Series, including Token payment/redemption obligations for that Series and third-party costs/fees allocated to that Series under the Token Terms or Product Documentation. * “Series Wallets / Series Accounts” means the designated wallet addresses and/or accounts used for that Series (deposit/collateral/redemption), as described in the Token Terms and/or operational disclosures. * “Series Waterfall” means the priority order for applying Series Assets described in Condition 10.4 (or as specified in Token Terms). * “Settlement Currency” means the currency or stablecoin(s) in which redemption is settled, as specified in the Token Terms. * “Token(s)” means the digital tokens issued by the Issuer via smart contracts on a supported blockchain network, evidencing contractual rights under the Product Documentation for a Series. * “Tokenholder(s)” means the person controlling the private key(s) for a wallet address holding Tokens (subject to Greenlisting where required). * “Underlying” has the meaning in the Token Terms (if applicable). * “Website” means yield.fi (or successor domain as notified). *** ### 4. KYC/AML REQUIREMENTS AND ONBOARDING (GREENLISTING) 4.1 Greenlisting requirement. To mint, redeem, or access restricted functionality, you may be required to complete KYC/AML Requirements. The Issuer may treat non-Greenlisted persons as ineligible to access restricted features. 4.2–4.7 Information, accuracy, verification, third parties, acceptance/rejection. (Keep your current text, with one change:)\ Replace “accept or reject onboarding at its discretion” with: “accept or reject onboarding acting reasonably and in accordance with Applicable Law.” *** ### 5. ORDERING, SUBSCRIPTION, MINTING, AND DELIVERY 5.1 Wallet requirement. You must use a compatible wallet and are responsible for access and private keys. 5.2 Subscription process. Tokens may be subscribed for through the Website or approved channels described in the Token Terms. 5.3 Payment methods. You must pay using methods specified in Token Terms (fiat transfer and/or stablecoin / crypto transfer). 5.4 When payment is due. Payment is due as specified in Token Terms. 5.5 Minting and delivery. Upon confirmed receipt of funds (and subject to Greenlisting where required), the Issuer will mint and deliver Tokens to your specified wallet address in accordance with Token Terms. 5.6 Errors. You are responsible for wallet and payment details; incorrect transfers may be irreversible. 5.7 Series deposit routing and segregation. All subscription payments for a Series must be made only to the Series Wallets / Series Accounts designated for that Series. Payments made to non-designated addresses/accounts may not be credited and may be irrecoverable. *** ### 6. VALUATION AND MARKET DISRUPTION 6.1 Market Disruption Event. A Market Disruption Event occurs if, in respect of the Underlying (where relevant), the price, reference rate, or value necessary for determining valuation, minting, redemption, or settlement cannot be determined or made available. 6.2 Postponement. If a Market Disruption Event occurs on a relevant valuation/fixing day, that day may be postponed until the next Business Day on which disruption no longer exists, as specified in Token Terms. 6.3 Fallback determination. If disruption continues, the Issuer may determine the relevant value using a reasonable methodology consistent with Token Terms and established market practice, including using best available data sources and execution-based realisation values where appropriate. *** ### 7. UNDERLYING ILLIQUIDITY 7.1 Underlying Illiquidity. Underlying Illiquidity means low/no trading volume, limited market depth, or practical difficulty in executing or hedging without materially affecting price. 7.2 Effect on calculations. In Underlying Illiquidity conditions, the Issuer may calculate redemption or settlement amounts using a best-efforts realised execution price (net of costs) rather than a standard reference fixing, consistent with Token Terms. 7.3 Delays. Determination and/or payment may be delayed to account for market conditions and operational constraints. *** ### 8. EXERCISE OF RIGHTS; PRIVATE KEYS; COMPLIANCE ENFORCEMENT 8.1 Recognised Tokenholders. Where Greenlisting is required, the Issuer recognises only persons who both hold Tokens and have completed KYC/AML Requirements. 8.2 Private key responsibility. Loss, theft, or compromise of private keys can result in loss of Tokens. You are responsible for wallet security. 8.3 Compliance actions. To comply with Applicable Law, court orders, sanctions, or law enforcement requests, the Issuer may restrict transfers, freeze functionality, refuse transactions, or take other actions permitted under Product Documentation or Applicable Law. *** ### 9. REDEMPTION 9.1 How redemption is initiated. Redemption is initiated per Token Terms, which may include a request process and/or on-chain actions. 9.2 Settlement instructions. If paid in stablecoins / crypto, you must provide a compatible wallet you control. If paid in fiat, you must provide correct bank details. You bear banking or gas fees; where the Issuer incurs properly attributable costs, they may be deducted as specified in Token Terms. 9.3 Timing. Timing, processing windows, and SLAs are described in Token Terms, are subject to change without prior notice and may be impacted by Market Disruption Events, Underlying Illiquidity, compliance checks, and operational constraints. 9.4 Fees and deductions. Fees are as specified in Token Terms. 9.5 Eligibility. Where Greenlisting applies, redemption may be restricted to Greenlisted Tokenholders. 9.6 Redemption payment source; limited recourse. Redemption payments for a Series are funded solely from Series Assets and processed using the Series Wallets / Series Accounts and methods described in Token Terms, subject to Condition 10. *** ### 10. STRUCTURAL SEGREGATION, LIMITED RECOURSE, AND SERIES WATERFALL 10.1 Structural intent. Each Series is operated on a segregated basis. Each Token evidences Series-limited contractual rights and is a limited-recourse instrument tied to the relevant Series. 10.2 Segregation of Series Assets.\ (a) The Issuer maintains Series Wallets / Series Accounts for each Series and uses them to receive deposits, hold collateral, deploy capital, and process redemptions for that Series.\ (b) The Issuer will not intentionally commingle Series Assets with (i) Operational Assets or (ii) assets of another Series, except where technically required for execution (e.g., routing/batching), with traceable books-and-records and prompt re-allocation.\ (c) The Issuer maintains internal records attributing assets, liabilities, income, fees, and costs to each Series on a consistent basis. 10.3 Limited recourse; no cross-collateralisation.\ (a) Any amount payable (if any) in respect of a Series is payable solely out of the Series Assets of that Series after application of the Series Waterfall.\ (b) Tokenholders of one Series have no recourse to Series Assets of any other Series.\ (c) To the maximum extent permitted by Applicable Law, Tokenholders have no recourse to Operational Assets for satisfaction of obligations attributable to a Series. 10.4 Series Waterfall. Unless Token Terms specify otherwise, Series Assets are applied in order: 1. Series costs and expenses properly attributable to the Series (custody/MPC, execution, banking, gas/transaction fees, oracle/data costs, and disclosed third-party expenses); 2. fees specified in Token Terms (management/performance/processing/withdrawal fees, if applicable); 3. Tokenholder redemption/payments for that Series. 10.5 Shortfall and loss allocation. If Series Assets are insufficient, Tokenholders bear the shortfall pro rata within that Series (unless Token Terms specify otherwise). Tokenholders may receive less than principal or nothing. 10.6 No recharacterisation. Tokenholders may not take steps intended to recharacterise Series-limited obligations as general corporate obligations or defeat this segregation/limited recourse framework. 10.7 Non-petition; bankruptcy-remoteness covenant. To the maximum extent permitted by Applicable Law, each Tokenholder agrees it will not seek to initiate insolvency proceedings against the Issuer solely on the basis of Series-limited claims, except where mandatory law prevents such covenant from being effective. *** ### 11. EXCLUSION OF PERSONAL LIABILITY; NO ADDITIONAL RECOURSE 11.1 Limited recourse confirmation. Tokenholder rights are limited to Series Assets as set out in Condition 10, except to the extent required by non-excludable law. 11.2 No personal liability. No recourse lies against any shareholder, director, officer, employee, affiliate, curator, custodian, wallet provider, exchange, prime broker, bank, protocol, or service provider, except in cases of actual fraud, wilful misconduct, or gross negligence where liability cannot be excluded by law. 11.3 Survival. This Condition survives redemption, burning, and Series termination. *** ### 12. SMART CONTRACT ADMINISTRATION; MODIFICATIONS; UPGRADES 12.1 Permitted upgrades. Smart contracts may include upgrade mechanisms. The Issuer may use them only to:\ (a) address security vulnerabilities or operational threats;\ (b) correct bugs or unintended deviations from Product Documentation;\ (c) maintain compatibility with network upgrades or external dependencies;\ (d) refactor without materially changing the economic intent; or\ (e) amend components rendered ineffective due to external changes. 12.2 Material changes. A change that materially and adversely changes Tokenholder rights, valuation methodology, fee mechanics, redemption mechanics, or risk profile for a Series is a “Material Adverse Change.” The Issuer will not implement a Material Adverse Change without:\ (a) updating the Token Terms / Product Documentation; and\ (b) providing notice under Condition 15,\ except where an immediate change is required for security/compliance, in which case notice will be provided as soon as reasonably practicable. 12.3 Deemed acceptance (if applicable). Where Token Terms provide for deemed acceptance, it applies as described there. *** ### 13. MIGRATION; SUBSTITUTION OF ISSUER; SERIES CONTINUITY 13.1 Series continuity objective. Any migration, substitution, or technical transition must preserve Series segregation and limited recourse in Condition 10. 13.2 Substitution. The Issuer may substitute itself with an affiliate or successor (a “New Issuer”) if:\ (a) the New Issuer can perform operational obligations for the Series;\ (b) the segregation and limited recourse framework is preserved on substantially equivalent terms; and\ (c) the Issuer provides reasonable notice under Condition 15.\ Tokenholder consent is not required unless the Token Terms expressly state otherwise. 13.3 No expansion of recourse. Substitution does not expand Tokenholder recourse beyond the relevant Series Assets. *** ### 14. AMENDMENTS 14.1 We may amend these General Terms to reflect changes in law, regulation, security, product design, or operational requirements. 14.2 If a change is material, we will make reasonable efforts to provide at least 2 days’ notice before it takes effect, unless a shorter period is required for security, compliance, or risk management reasons. *** ### 15. NOTICES 15.1 Notices relating to Tokens and these General Terms will be published on the Website or other official channels designated by the Issuer. *** ### 16. TAX 16.1 Tokenholders are solely responsible for taxes arising from holding, transferring, minting, redeeming, or otherwise dealing in Tokens. 16.2 Payments are made without deduction or withholding unless required by Applicable Law. Where withholding is required, the Issuer may deduct the amount and is not obliged to gross up unless Token Terms expressly provide otherwise. *** ### 17. SERIES EVENTS, ISSUER INSOLVENCY, AND WIND-DOWN 17.1 Series shortfall is not an Issuer default. A delay, suspension, reduction, or non-payment in respect of a Series resulting solely from (i) insufficient Series Assets, (ii) Series Waterfall application, (iii) Market Disruption / Illiquidity, (iv) compliance checks, or (v) operational constraints in Token Terms, does not constitute an Issuer-wide default and does not create recourse beyond the relevant Series. 17.2 Series Wind-Down Event. A Series Wind-Down Event occurs if any of the following happens for a Series (Issuer acting reasonably and in good faith): illegality/adverse regulatory; adverse tax; persistent disruption/illiquidity; material counterparty/infrastructure failure; security incident; expected Series Asset shortfall; or termination triggers stated in Token Terms. 17.3 Issuer Insolvency Event. An Issuer Insolvency Event occurs if the Issuer commences or becomes subject to liquidation/winding-up/reorganisation/moratorium proceedings, becomes generally unable to pay its debts as they fall due, suspends payments of all or a material part of its debts, or is subject to involuntary insolvency proceedings. 17.4 Consequences of a Series Wind-Down Event. The Issuer may: suspend mint/redemption/transfers (if enabled); unwind positions; realise Series Assets; determine a final realisation value using a reasonable methodology consistent with Token Terms and market practice; apply the Series Waterfall; and distribute realised Series Assets (if any). 17.5 Payment mechanics during wind-down. Best-efforts realisation applies; properly attributable costs are deducted as Series costs; distributions are pro rata within the Series (unless Token Terms specify otherwise); and there is no obligation to contribute Operational Assets or assets from other Series absent an express Token Terms commitment. 17.6 Issuer Insolvency Event consequences. The segregation and limited recourse framework in Condition 10 applies subject to applicable insolvency law, court orders, and mandatory rules that cannot be excluded. 17.7 Notices. We will publish notice of a Wind-Down Event or Insolvency Event under Condition 15 subject to legal, security, and confidentiality constraints. 17.8 Survival. This Condition survives redemption/burning and Series termination. *** ### 18. LIMITATION OF LIABILITY 18.1 To the maximum extent permitted by Applicable Law, the Issuer disclaims liability for indirect, incidental, consequential, special, punitive, or exemplary damages (including loss of profits/opportunity/goodwill). 18.2 The Issuer is not liable for independent third parties not under its direct control (exchanges, custodians, wallet providers, banks, liquidity providers, analytics providers, protocol operators, infrastructure vendors), except where the Issuer engaged in actual fraud, wilful misconduct, or gross negligence that cannot be excluded by law. 18.3 Nothing limits liability that cannot be excluded under Applicable Law. *** ### 19. NON-CUSTODIAL; NO FIDUCIARY DUTIES 19.1 Non-custodial. Unless Token Terms expressly state otherwise, the Issuer does not hold custody of Tokenholders’ private keys. You are responsible for wallet security. 19.2 No fiduciary relationship. The Product Documentation does not create fiduciary duties. To the maximum extent permitted by law, any fiduciary duties that might otherwise be implied are waived, and our obligations are only those expressly set out. *** ### 20. GOVERNING LAW AND JURISDICTION 20.1 These General Terms, the Product Documentation, and any non-contractual obligations are governed by BVI law. 20.2 Subject to any arbitration clause in Token Terms, the courts of the BVI have jurisdiction to settle disputes arising out of or in connection with the Product Documentation. *** ### 21. SEVERABILITY If any provision is held invalid or unenforceable, the remaining provisions remain in effect. The parties will, where possible, replace the invalid provision with a lawful provision closest to the original economic intent. *** ### 22. MISCELLANEOUS 22.1 Independent advice. You should obtain independent professional advice if unsure about any aspect of Tokens. 22.2 No waiver. Any waiver must be in writing by the Issuer. Failure to enforce a provision is not a waiver. 22.3 Entire agreement. Product Documentation constitutes the entire agreement relating to Tokens and supersedes prior statements, subject to documents incorporated by reference. 22.4 Assignment. The Issuer may assign/transfer rights and obligations to an affiliate/successor consistent with Condition 13 and Token Terms. Token transfers (if any) are governed by Token Terms and smart contract rules. *** # Risk Disclosures Dealing in Tokens involves a high degree of risk and may be suitable only if you can evaluate the risks and bear a complete loss of capital. This list is not exhaustive. #### 1) Structural segregation and limited recourse risk Tokens are Series-limited, limited-recourse blockchain-based contractual certificates. Tokenholders have recourse only to the Series Assets of the relevant Series (after Series costs/fees). If Series Assets are insufficient (market losses, counterparty failure, hacks, settlement issues, or other risks), Tokenholders may recover less than principal or nothing. Tokenholders have no recourse to Series Assets of other Series and, to the maximum extent permitted by law, no recourse to Operational Assets. #### 2) No ownership of underlying Tokenholders do not directly own or control any Underlying or Series Assets. Tokenholders hold only contractual rights under the Product Documentation. #### 3) Market, strategy, and performance risk Token value may be linked to strategy/Underlying performance. Losses may occur. Past performance is not indicative of future results. #### 4) Valuation, tracking, and timing differences Valuation may differ from reference prices due to fees, operational timing, market disruptions, illiquidity, execution costs, and settlement constraints. #### 5) Liquidity and transferability risk There may be no secondary market. Tokens may be illiquid and/or subject to transfer restrictions. #### 6) Redemption and settlement risk Redemptions may be delayed by SLAs, compliance checks, Market Disruption Events, illiquidity, and operational constraints. Settlement may involve banking, stablecoin, or blockchain risks. #### 7) Third-party and counterparty risk The Issuer relies on third parties (custodians/MPC providers, exchanges, prime brokers, banks, blockchains, oracle providers, protocol operators, infrastructure vendors). Failures, insolvencies, hacks, or outages may impact a Series. #### 8) Smart contract and cybersecurity risk Bugs, exploits, governance attacks, key compromise, bridge failures, oracle failures, and other incidents can cause partial or total loss. #### 9) Blockchain and network risks Congestion, high fees, forks, re-org, consensus failures, validator/miner attacks, and emerging technology risks may disrupt operations. #### 10) Regulatory and enforcement risk Laws and interpretations may change rapidly. The Issuer may restrict jurisdictions, suspend features, or cease operations in some markets. #### 11) Tax risk Tax treatment may be uncertain and may change. Withholding may apply. You are responsible for your tax compliance. #### 12) Operational and key-person risk The Issuer may face execution, staffing, vendor, and business continuity risks. #### 13) Unanticipated risks New risks may emerge that are not presently foreseeable. # Series Segregation & Bankruptcy Remote Structure Disclosure This Schedule forms part of the Product Documentation. It describes the Issuer’s intended structural segregation framework for each Series. Capitalised terms have the meanings given in the General Terms and the Token Terms. #### 1. Purpose and scope 1.1 **Purpose.** This Schedule explains how the Issuer intends to operate each Series on a segregated, bankruptcy-remote basis, including the designation of Series Wallets / Series Accounts, attribution of Series Assets and Series Liabilities, the Series Waterfall, and the limits of Tokenholder recourse. 1.2 **Scope.** This Schedule is structural and operational in nature. Series-specific mechanics (including valuation, fees, redemption windows, and Underlying definitions) are set out in the applicable Token Terms. *** #### 2. Series ring-fencing model 2.1 **Separate Series.** Each Token issuance corresponds to a Series. Each Series is intended to operate as an independent, ring-fenced product sleeve, with its own:\ (a) Series Wallets / Series Accounts;\ (b) Series Assets and Series Liabilities attribution;\ (c) operational processes for minting, deployment, and redemption; and\ (d) Series Waterfall (unless varied by Token Terms). 2.2 **No cross-collateralisation.** The Issuer does not intentionally cross-collateralise Series. Series Assets of one Series are not intended to support obligations of another Series, except if expressly stated in Token Terms. 2.3 **Segregation from Operational Assets.** The Issuer segregates Series Assets from Operational Assets. Operational Assets are intended to fund only the Issuer’s corporate operations (e.g., payroll, overheads, vendor expenses not allocated to Series). *** #### 3. Series Wallets / Series Accounts architecture 3.1 **Designated addresses/accounts per Series.** For each Series, the Issuer designates one or more Series Wallets / Series Accounts. These typically include:\ (a) **Deposit Address(es):** addresses/accounts for receiving subscription funds for minting;\ (b) **Collateral / Holding Wallet(s):** addresses/accounts used to hold Series Assets and collateral;\ (c) **Execution / Deployment Wallet(s) (if applicable):** addresses/accounts used to interact with whitelisted DeFi protocols or to transfer to exchange / prime broker sub-accounts for execution, consistent with Token Terms;\ (d) **Redemption / Payout Wallet(s):** addresses/accounts used to process redemptions and distributions. 3.2 **Address/account designation.** The Token Terms and/or operational disclosures identify the Series Wallets / Series Accounts (or the method by which they are identified). Tokenholders must route funds only to the designated Series Wallets / Series Accounts. 3.3 **Controls on movement.** Movements from Series Wallets / Series Accounts are initiated and executed pursuant to the Issuer’s internal controls, vendor controls, and Series operating procedures, and may rely on third-party service providers (e.g., MPC wallet providers, exchanges, prime brokers, banks). 3.4 **Technical execution exception.** In limited circumstances, technical routing, batching, or settlement processes may require transient movements that do not reflect economic commingling. Where this occurs, the Issuer maintains traceable books-and-records intended to preserve correct Series attribution and promptly restores allocations. *** #### 4. Attribution of Series Assets and Series Liabilities 4.1 **Series Assets.** Series Assets include, as applicable:\ (a) subscriptions received for the Series;\ (b) assets acquired or deployed for the Series (including collateral, LP positions, yield-bearing instruments, hedges, and receivables);\ (c) proceeds from realisations, unwind activity, liquidations, or recoveries attributable to the Series;\ (d) any airdrops, rewards, rebates, or incentives attributable to the Series (if and to the extent specified in Token Terms); and\ (e) any rights, claims, or receivables arising from Series activity. 4.2 **Series Liabilities.** Series Liabilities include, as applicable:\ (a) redemption and settlement obligations payable to Tokenholders of that Series (if any), calculated under Token Terms;\ (b) Series costs and expenses properly attributable to the Series;\ (c) fees payable in respect of the Series as specified in Token Terms; and\ (d) any other liabilities expressly allocated to the Series under Product Documentation. 4.3 **Allocation policy.** The Issuer maintains an internal allocation approach intended to attribute assets, liabilities, income, fees, and costs to the relevant Series on a consistent basis. Where a cost or fee relates to multiple Series, the Issuer applies a reasonable allocation methodology (e.g., pro rata by AUM, usage, transactions, or other objective metric). *** #### 5. Use of third-party infrastructure and accounts 5.1 **Service providers.** The Issuer may use third parties to operate a Series, including MPC wallet providers, custodians, exchanges, prime brokers, banks, protocol operators, oracle providers, and infrastructure vendors. 5.2 **Series sub-accounts (where applicable).** Where the Series uses exchange or prime broker infrastructure, the Issuer intends to use segregated sub-accounts or equivalent arrangements to attribute positions and balances to the Series. 5.3 **Whitelisting.** Where a Series deploys Series Assets into DeFi protocols, the Issuer intends to maintain a whitelisting approach for contracts/endpoints used, consistent with the Series operating model. 5.4 **Counterparty risk remains.** Segregation reduces commingling but does not eliminate third-party, operational, or counterparty risk. Failures or insolvencies of third parties may affect Series Assets and Tokenholder outcomes. *** #### 6. Series Waterfall and funding of redemptions 6.1 **Waterfall application.** Unless the Token Terms specify otherwise, realised Series Assets (including during ordinary operations or wind-down) are applied in the Series Waterfall order:\ (a) Series costs and expenses;\ (b) fees specified in Token Terms;\ (c) Tokenholder redemptions/payments for that Series. 6.2 **Redemption source.** Redemptions (if any) are funded solely from Series Assets after application of the Series Waterfall and subject to Token Terms, compliance checks, operational constraints, Market Disruption Events, and Underlying Illiquidity. 6.3 **No top-up.** The Issuer has no obligation to contribute Operational Assets or assets from other Series to cover a Series shortfall, unless expressly committed in the Token Terms. *** #### 7. Limits of recourse; effect of shortfall 7.1 **Limited recourse.** Tokenholders’ rights are limited to Series Assets of the relevant Series after application of the Series Waterfall (subject to non-excludable Applicable Law). 7.2 **No recourse to other Series.** Tokenholders of one Series have no recourse to Series Assets of any other Series. 7.3 **No recourse to Operational Assets.** To the maximum extent permitted by Applicable Law, Tokenholders have no recourse to Operational Assets for satisfaction of Series obligations. 7.4 **Shortfall mechanics.** If Series Assets are insufficient, Tokenholders bear the shortfall pro rata within that Series (unless Token Terms provide otherwise), and may receive less than principal or nothing. *** #### 8. Series Wind-Down mechanics (high level) 8.1 **Triggers.** A Series Wind-Down Event may occur as described in Condition 17 (e.g., regulatory illegality, adverse tax, persistent disruption, counterparty failure, security incident, or expected Series shortfall). 8.2 **Actions.** In a wind-down, the Issuer may suspend minting/redemption/transfers (if enabled), unwind positions, realise Series Assets, determine a final realisation value using reasonable methods consistent with Token Terms, apply the Series Waterfall, and distribute realised Series Assets (if any). 8.3 **Best-efforts; no guarantee.** Wind-down involves execution risk, timing risk, and price impact. The Issuer does not guarantee any minimum outcome or timeline. *** #### 9. Records, transparency, and verification 9.1 **Records.** The Issuer maintains records intended to support Series attribution, including transaction logs, wallet/account mapping, and internal accounting schedules. 9.2 **Transparency scope.** The Issuer may provide transparency or reporting at the Series level (e.g., addresses, holdings, NAV methodology, exposures, and performance) as described in Token Terms or separate disclosures. 9.3 **No assurance.** On-chain visibility and internal records facilitate attribution but do not constitute an audit, guarantee, or assurance of solvency or outcomes. *** #### 10. Legal effectiveness and limitations 10.1 **Structural intent; mandatory law.** This segregation framework reflects the Issuer’s structural intent and operating model. Actual outcomes in insolvency or court-supervised proceedings may be affected by mandatory BVI law, court orders, insolvency practitioner actions, and factual determinations regarding asset attribution. 10.2 **No creation of trust.** Unless expressly stated in Token Terms, nothing in the Product Documentation creates a trust, fiduciary relationship, or custodial relationship in favour of Tokenholders. 10.3 **Conflicts.** If there is any conflict between this Schedule 2 and the Token Terms for a Series, the Token Terms prevail for that Series. *** #### 11. Acknowledgement By dealing in Tokens, you acknowledge and agree that:\ (a) Tokens are blockchain-based contractual certificates evidencing Series-limited rights;\ (b) your recourse is limited to Series Assets after the Series Waterfall;\ (c) you have no recourse to other Series or Operational Assets (subject to non-excludable law); and\ (d) you bear risks described in Schedule 1, including third-party, market, execution, operational, smart contract, and regulatory risks. # Token Terms # yPrism **Issuer / Operator:** YieldFi\ **Governing law:** British Virgin Islands law\ **Document hierarchy:** These Token Terms supplement and form part of the Product Documentation. Capitalised terms not defined here have the meanings in the General Terms. ### 0) Series Snapshot * **Series ID / Ticker:** yPrism * **Product type:** Market Neutral * **Series objective:** Deploy Series Assets into market-neutral, delta-neutral positions (e.g., private LP deals, hedged carry, basis, and funding-rate spreads across whitelisted DeFi protocols and/or hedged venues) to target yield primarily from net financing and fee spreads while seeking to minimise directional exposure to the underlying asset price. * **Settlement currency:** USDC * **Deposit asset(s):** USDC / USDT / USD0 * **Target redemption SLA:** T+2 * **Fees:** * **Management fee:** 0.00% p.a. * **Performance fee:** 20.00% * **Mint fee:** none * **Redemption fee:** none (other than **network gas** fees * **Transferability:** Fully transferable * **Leverage permitted:** Yes * **Jurisdiction / eligibility:** See Eligibility Criteria Section. *** ### 1) Token Character and Series-Limited Structure 1.1 **Token character.** Tokens are blockchain-based contractual certificates evidencing Series-limited rights under the Product Documentation. Tokens are not equity and confer no governance rights in the Issuer. 1.2 **Series-limited, limited recourse.** Any payment/redemption amount in respect of this Series is payable solely from **Series Assets** after application of the **Series Waterfall**, subject to Applicable Law (including any non-excludable law). 1.3 **No ownership of assets.** Tokenholders do not own Series Assets or any Underlying; they hold only contractual rights as described in the Product Documentation. *** ### 2) Eligibility, Access and Transfer Controls 2.1 **Investor eligibility.** Tokens may be minted, held, redeemed, or transferred only by persons meeting:\ (a) **KYC/AML / Greenlisting** requirements (if applicable); and\ (b) **jurisdictional/eligibility restrictions**: see eligibility criteria section. 2.2 **Transfer restrictions.** * **Transfer status:** Fully transferrable 2.3 **Sanctions & screening.** Wallet screening may be applied at mint, transfer (if enabled), and redemption. *** ### 3) Supported Network, Token Contract, and Admin Controls 3.1 **Network(s).** Ethereum, BSC Network etc. 3.2 **Token contract address(es).** See Smart Contract Addresses 3.3 **Admin / upgrade controls.** Upgradeability, pausing, and emergency controls (if any) are described in product docs, and are subject to the General Terms (smart contract administration / material adverse change notice). *** ### 4) Series Wallets / Accounts (Segregation Disclosure) 4.1 **Designated Series Wallets / Accounts.** Refer [Product Factsheet](https://yield.fi/vaults/yprism) 4.2 **Deposit routing requirement.** Deposits sent to non-designated addresses/accounts may be irrecoverable and may not be credited. 4.3 **Series segregation.** Series Assets are intended to be held and tracked separately from other Series and from Operational Assets, as further described in Schedule 2. *** ### 5) Roles and Permitted Activities 5.1 **Operator (Issuer).** The Issuer operates the Series, maintains the token contract(s), sets and administers Token Terms, and manages service provider relationships. 5.2 **Curator / strategy manager (if applicable).** * **Name:** Clearstar * **Role:** Strategy execution, Rebalancing, DeFi deployment, Exchange execution, Hedging * **Authority model:** Curator executes via MPC quorum. 5.3 **Service providers (if applicable).** * **MPC / custody:** ForDeFi * **Exchanges / prime broker:** N/A * **Oracles / pricing:** Chainlink etc * **Audit / security:** See Audits section 5.4 **Permitted activity set.** See [transparency](https://yield.fi/transparency?token=yprism\&chain=1) page. *** ### 6) Deposits and Minting 6.1 **Deposit window.** Deposits accepted: 24/7 6.2 **Minimum / maximum.** * **Min deposit:** n/a * **Max deposit per address:** n/a * **Max Series capacity (soft/hard):** n/a 6.3 **Mint price / issuance.** Tokens are minted at: * **Issue price basis:** NAV-based * **Mint formula:**\ **Tokens minted = (Net deposit amount in Settlement Currency) / (Token NAV per Token)**\ where “Net deposit amount” is after applicable mint fees (if any) and properly attributable costs. 6.4 **Mint fees.** None. 6.5 **Failed or reversed deposits.** Handling for banking rejects, chain reorgs, stablecoin blacklisting, or compliance blocks: See product docs. *** ### 7) NAV, Valuation Methodology, and Pricing 7.1 **NAV definition.** “Token NAV per Token” means:\ **(Series Assets – Series Liabilities) / Tokens outstanding**, determined as of the valuation time. 7.2 **Valuation frequency.** Minimum twice per week. 7.3 **Valuation sources.** * On-chain assets: Chainlink or equivalent asset oracle * CEX positions: n/a * Off-chain assets: n/a * FX (if relevant): n/a 7.4 **Market disruption fallback.** If standard sources are unavailable, Issuer uses a reasonable fallback consistent with market practice and the General Terms, including execution-based realisation values. 7.5 **Publication.** NAV is published via update to the vault NAV value. *** ### 8) Redemptions and Settlement 8.1 **Redemption method.** Redemption is initiated via: * Onchain redemption request 8.2 **Redemption windows & SLAs.** * **Cutoff:** n/a * **Processing target:** T+2 * **Maximum timeframe (best efforts):** T+2\ Delays may occur due to Market Disruption, illiquidity, compliance, or operational constraints. 8.3 **Redemption pricing.** * **Redemption price basis:** min of NAV at {redemption request, redemption processing} * **Redemption Amount = Tokens redeemed × Redemption NAV per Token − fees − properly attributable costs** 8.4 **Redemption fees.** 0% \[except gas fees]. 8.5 **Settlement mechanics.** Paid in: * **Stablecoin:** USDC to wallet provided by Tokenholder; or * **Fiat:** bank transfer to verified account;\ Subject to compliance verification and sanctions screening. 8.6 **In-kind redemption (optional).** Disabled 8.7 **Redemption source and limited recourse.** Redemptions are funded solely from Series Assets after applying the Series Waterfall. *** ### 9) Fees, Expenses, and Series Waterfall 9.1 **Fee schedule.** * **Management fee:** 0% per annum * **Performance fee:** 20% of net profits with high-water mark model, crystallised at NAV distribution. * **Other fees:** gas fees at processing redemptions. 9.2 **Pass-through expenses.** Series pays properly attributable third-party costs: custody/MPC, exchange fees, prime broker fees, gas, oracle/data, audit/security allocated to the Series (if any), banking fees, legal/admin costs allocated to the Series. 9.3 **Series Waterfall.** Unless otherwise specified: 1. Series costs/expenses; 2. fees; 3. Tokenholder redemptions/payments. *** ### 10) Risk Limits and Portfolio Constraints 10.1 **Exposure constraints.** * Directional exposure: <1% delta * Leverage cap: n/a * Single counterparty concentration: n/a * Single protocol concentration: n/a * Stablecoin concentration: n/a * Duration cap (if fixed income): n/a * Borrowing permitted: Yes. 10.2 **Collateral and margin.** * Margin buffers: n/a * Liquidation policies: n/a * Rebalancing frequency: n/a 10.3 **Prohibited activities.** unwhitelisted protocols, unsecured lending, long-only risk, etc. *** ### 11) Points, Airdrops, Rebates, and Incentives (If Applicable) 11.1 **Treatment policy.** Any points/airdrops/rebates attributable to Series activity are treated as: * retained by Series and reflected in NAV / or * distributed to Tokenholders under a disclosed program 11.2 **Disclosure.** Method and timing of recognition in NAV: As and when realised. *** ### 12) Reporting and Transparency 12.1 **Standard reporting.** Issuer provides: * NAV history and current NAV * Holdings/exposure summary * Performance metrics: APY * Material events: security incidents, counterparty failures, wind-down events 12.2 **Frequency.** At least twice per week on best effort basis 12.3 **Audit/attestation (optional).** proof-of-reserves attestation *** ### 13) Series Wind-Down and Termination 13.1 **Triggers.** As per General Terms (Series Wind-Down Events) plus any Series-specific triggers. 13.2 **Process.** Issuer may suspend mint/redemption/transfers (if enabled), unwind positions, realise Series Assets, determine final realisation value, and distribute Series Assets (if any) pro rata after Series Waterfall. 13.3 **No top-up.** No obligation to contribute Operational Assets or other Series assets unless expressly stated. *** ### 14) Conflicts, Discretion, and Material Changes 14.1 **Conflicts.** n/a 14.2 **Issuer discretion.** Issuer discretion is limited to reasonable actions consistent with Product Documentation, especially during market disruption or wind-down. 14.3 **Material adverse changes.** Material adverse changes follow the General Terms notice framework (with emergency exception for security/compliance). *** ### 15) Risk Disclosures As detailed in General Risk Disclosures *** ### 16) Notices and Contact * **Official notices channel:** Discord / Telegram * **Support contact:** Discord / Telegram * **Effective date of these Token Terms:** From the date of smart contract deployment * **Version:** n/a *** ### 17) Execution Blocks * **Minimum ticket:** n/a * **Operational onboarding:** n/a * **Settlement instructions:** n/a * **Cutoff times:** n/a * **Redemption cadence:** n/a # yUSD **Issuer / Operator:** YieldFi\ **Governing law:** British Virgin Islands law\ **Document hierarchy:** These Token Terms supplement and form part of the Product Documentation. Capitalised terms not defined here have the meanings in the General Terms. ### 0) Series Snapshot * **Series ID / Ticker:** yUSD * **Product type:** Market Neutral * **Series objective:** Deploy Series Assets into market-neutral, delta-neutral positions (e.g., private LP deals, hedged carry, basis, and funding-rate spreads across whitelisted DeFi protocols and/or hedged venues) to target yield primarily from LP, leverage looping and fees while seeking to minimise directional exposure to the underlying asset price. * **Settlement currency:** USDC * **Deposit asset(s):** USDC / USDT * **Target redemption SLA:** T+2 * **Fees:** * **Management fee:** 2.00% p.a. * **Performance fee:** 0.00% * **Mint fee:** none * **Redemption fee:** none (other than **network gas** fees * **Transferability:** Fully transferable * **Leverage permitted:** Yes * **Jurisdiction / eligibility:** See Eligibility Criteria Section. *** ### 1) Token Character and Series-Limited Structure 1.1 **Token character.** Tokens are blockchain-based contractual certificates evidencing Series-limited rights under the Product Documentation. Tokens are not equity and confer no governance rights in the Issuer. 1.2 **Series-limited, limited recourse.** Any payment/redemption amount in respect of this Series is payable solely from **Series Assets** after application of the **Series Waterfall**, subject to Applicable Law (including any non-excludable law). 1.3 **No ownership of assets.** Tokenholders do not own Series Assets or any Underlying; they hold only contractual rights as described in the Product Documentation. *** ### 2) Eligibility, Access and Transfer Controls 2.1 **Investor eligibility.** Tokens may be minted, held, redeemed, or transferred only by persons meeting:\ (a) **KYC/AML / Greenlisting** requirements (if applicable); and\ (b) **jurisdictional/eligibility restrictions**: see eligibility criteria section. 2.2 **Transfer restrictions.** * **Transfer status:** Fully transferrable 2.3 **Sanctions & screening.** Wallet screening may be applied at mint, transfer (if enabled), and redemption. *** ### 3) Supported Network, Token Contract, and Admin Controls 3.1 **Network(s).** EVM chains. 3.2 **Token contract address(es).** See Smart Contract Addresses 3.3 **Admin / upgrade controls.** Upgradeability, pausing, and emergency controls (if any) are described in product docs, and are subject to the General Terms (smart contract administration / material adverse change notice). *** ### 4) Series Wallets / Accounts (Segregation Disclosure) 4.1 **Deposit routing requirement.** Deposits sent to non-designated addresses/accounts may be irrecoverable and may not be credited. 4.2 **Series segregation.** Series Assets are intended to be held and tracked separately from other Series and from Operational Assets, as further described in Schedule 2. *** ### 5) Activities 5.1 **Operator (Issuer).** The Issuer operates the Series, maintains the token contract(s), sets and administers Token Terms, and manages service provider relationships. 5.2 **Service providers (if applicable).** * **MPC / custody:** ForDeFi * **Exchanges / prime broker:** N/A * **Oracles / pricing:** Chainlink etc * **Audit / security:** See Audits section *** ### 6) Deposits and Minting 6.1 **Deposit window.** Deposits accepted: 24/7 6.2 **Minimum / maximum.** * **Min deposit:** n/a * **Max deposit per address:** n/a * **Max Series capacity (soft/hard):** n/a 6.3 **Mint price / issuance.** Tokens are minted at: * **Issue price basis:** NAV-based * **Mint formula:**\ **Tokens minted = (Net deposit amount in Settlement Currency) / (Token NAV per Token)**\ where “Net deposit amount” is after applicable mint fees (if any) and properly attributable costs. 6.4 **Mint fees.** None. 6.5 **Failed or reversed deposits.** Handling for banking rejects, chain reorgs, stablecoin blacklisting, or compliance blocks: See product docs. *** ### 7) NAV, Valuation Methodology, and Pricing 7.1 **NAV definition.** “Token NAV per Token” means:\ **(Series Assets – Series Liabilities) / Tokens outstanding**, determined as of the valuation time. 7.2 **Valuation frequency.** Minimum twice per week. 7.3 **Valuation sources.** * On-chain assets: Chainlink or equivalent asset oracle * CEX positions: n/a * Off-chain assets: n/a * FX (if relevant): n/a 7.4 **Market disruption fallback.** If standard sources are unavailable, Issuer uses a reasonable fallback consistent with market practice and the General Terms, including execution-based realisation values. 7.5 **Publication.** NAV is published via update to the vault NAV value. *** ### 8) Redemptions and Settlement 8.1 **Redemption method.** Redemption is initiated via: * Onchain redemption request 8.2 **Redemption windows & SLAs.** * **Cutoff:** n/a * **Processing target:** T+2 Delays may occur due to Market Disruption, illiquidity, compliance, or operational constraints. 8.3 **Redemption pricing.** * **Redemption price basis:** min of NAV at {redemption request, redemption processing} * **Redemption Amount = Tokens redeemed × Redemption NAV per Token − fees − properly attributable costs** 8.4 **Redemption fees.** 0% \[except gas fees]. 8.5 **Settlement mechanics.** Paid in: * **Stablecoin:** USDC to wallet provided by Tokenholder; or * **Fiat:** bank transfer to verified account;\ Subject to compliance verification and sanctions screening. 8.6 **In-kind redemption (optional).** Optional 8.7 **Redemption source and limited recourse.** Redemptions are funded solely from Series Assets after applying the Series Waterfall. *** ### 9) Fees, Expenses, and Series Waterfall 9.1 **Fee schedule.** * **Management fee:** 2% per annum * **Performance fee:** 0% of net profits with high-water mark model, crystallised at NAV distribution. * **Other fees:** gas fees at processing redemptions. 9.2 **Pass-through expenses.** Series pays properly attributable third-party costs: custody/MPC, exchange fees, prime broker fees, gas, oracle/data, audit/security allocated to the Series (if any), banking fees, legal/admin costs allocated to the Series. 9.3 **Series Waterfall.** Unless otherwise specified: 1. Series costs/expenses; 2. fees; 3. Tokenholder redemptions/payments. *** ### 10) Risk Limits and Portfolio Constraints 10.1 **Exposure constraints.** * Directional exposure: <1% delta * Leverage cap: n/a * Single counterparty concentration: n/a * Single protocol concentration: n/a * Stablecoin concentration: n/a * Duration cap (if fixed income): n/a * Borrowing permitted: Yes. 10.2 **Collateral and margin.** * Margin buffers: n/a * Liquidation policies: n/a * Rebalancing frequency: n/a 10.3 **Prohibited activities.** unwhitelisted protocols, long-only risk, etc. *** ### 11) Points, Airdrops, Rebates, and Incentives (If Applicable) 11.1 **Treatment policy.** Any points/airdrops/rebates attributable to Series activity are treated as: * retained by Series and reflected in NAV / or * distributed to Tokenholders under a disclosed program 11.2 **Disclosure.** Method and timing of recognition in NAV: As and when realised. *** ### 12) Reporting and Transparency 12.1 **Standard reporting.** Issuer provides: * NAV history and current NAV * Holdings/exposure summary * Performance metrics: APY * Material events: security incidents, counterparty failures, wind-down events 12.2 **Frequency.** At least twice per week on best effort basis 12.3 **Audit/attestation (optional).** proof-of-reserves attestation *** ### 13) Series Wind-Down and Termination 13.1 **Triggers.** As per General Terms (Series Wind-Down Events) plus any Series-specific triggers. 13.2 **Process.** Issuer may suspend mint/redemption/transfers (if enabled), unwind positions, realise Series Assets, determine final realisation value, and distribute Series Assets (if any) pro rata after Series Waterfall. 13.3 **No top-up.** No obligation to contribute Operational Assets or other Series assets unless expressly stated. *** ### 14) Conflicts, Discretion, and Material Changes 14.1 **Conflicts.** n/a 14.2 **Issuer discretion.** Issuer discretion is limited to reasonable actions consistent with Product Documentation, especially during market disruption or wind-down. 14.3 **Material adverse changes.** Material adverse changes follow the General Terms notice framework (with emergency exception for security/compliance). *** ### 15) Risk Disclosures As detailed in General Risk Disclosures *** ### 16) Notices and Contact * **Official notices channel:** Discord / Telegram * **Support contact:** Discord / Telegram * **Effective date of these Token Terms:** From the date of smart contract deployment * **Version:** n/a *** ### 17) Execution Blocks * **Minimum ticket:** n/a * **Operational onboarding:** n/a * **Settlement instructions:** n/a * **Cutoff times:** n/a * **Redemption cadence:** n/a # vyUSD **Issuer / Operator:** YieldFi\ **Governing law:** British Virgin Islands law\ **Document hierarchy:** These Token Terms supplement and form part of the Product Documentation. Capitalised terms not defined here have the meanings in the General Terms. ### 0) Series Snapshot * **Series ID / Ticker:** vyUSD * **Product type:** Market Neutral * **Series objective:** Deploy Series Assets into market-neutral, delta-neutral positions (e.g., private LP deals, hedged carry, basis, and funding-rate spreads across whitelisted DeFi protocols and/or hedged venues) to target yield primarily from LP, leverage looping and fees while seeking to minimise directional exposure to the underlying asset price. * **Settlement currency:** USDC * **Deposit asset(s):** USDC / USDT * **Target redemption SLA:** T+2 * **Fees:** * **Management fee:** 2.00% p.a. * **Performance fee:** 0.00% * **Mint fee:** none * **Redemption fee:** none (other than **network gas** fees * **Transferability:** Fully transferable * **Leverage permitted:** Yes * **Jurisdiction / eligibility:** See Eligibility Criteria Section. *** ### 1) Token Character and Series-Limited Structure 1.1 **Token character.** Tokens are blockchain-based contractual certificates evidencing Series-limited rights under the Product Documentation. Tokens are not equity and confer no governance rights in the Issuer. 1.2 **Series-limited, limited recourse.** Any payment/redemption amount in respect of this Series is payable solely from **Series Assets** after application of the **Series Waterfall**, subject to Applicable Law (including any non-excludable law). 1.3 **No ownership of assets.** Tokenholders do not own Series Assets or any Underlying; they hold only contractual rights as described in the Product Documentation. *** ### 2) Eligibility, Access and Transfer Controls 2.1 **Investor eligibility.** Tokens may be minted, held, redeemed, or transferred only by persons meeting:\ (a) **KYC/AML / Greenlisting** requirements (if applicable); and\ (b) **jurisdictional/eligibility restrictions**: see eligibility criteria section. 2.2 **Transfer restrictions.** * **Transfer status:** Fully transferrable 2.3 **Sanctions & screening.** Wallet screening may be applied at mint, transfer (if enabled), and redemption. *** ### 3) Supported Network, Token Contract, and Admin Controls 3.1 **Network(s).** EVM chains. 3.2 **Token contract address(es).** See Smart Contract Addresses 3.3 **Admin / upgrade controls.** Upgradeability, pausing, and emergency controls (if any) are described in product docs, and are subject to the General Terms (smart contract administration / material adverse change notice). *** ### 4) Series Wallets / Accounts (Segregation Disclosure) 4.1 **Deposit routing requirement.** Deposits sent to non-designated addresses/accounts may be irrecoverable and may not be credited. 4.2 **Series segregation.** Series Assets are intended to be held and tracked separately from other Series and from Operational Assets, as further described in Schedule 2. *** ### 5) Activities 5.1 **Operator (Issuer).** The Issuer operates the Series, maintains the token contract(s), sets and administers Token Terms, and manages service provider relationships. 5.2 **Service providers (if applicable).** * **MPC / custody:** ForDeFi * **Exchanges / prime broker:** N/A * **Oracles / pricing:** Chainlink etc * **Audit / security:** See Audits section *** ### 6) Deposits and Minting 6.1 **Deposit window.** Deposits accepted: 24/7 6.2 **Minimum / maximum.** * **Min deposit:** n/a * **Max deposit per address:** n/a * **Max Series capacity (soft/hard):** n/a 6.3 **Mint price / issuance.** Tokens are minted at: * **Issue price basis:** NAV-based * **Mint formula:**\ **Tokens minted = (Net deposit amount in Settlement Currency) / (Token NAV per Token)**\ where “Net deposit amount” is after applicable mint fees (if any) and properly attributable costs. 6.4 **Mint fees.** None. 6.5 **Failed or reversed deposits.** Handling for banking rejects, chain reorgs, stablecoin blacklisting, or compliance blocks: See product docs. *** ### 7) NAV, Valuation Methodology, and Pricing 7.1 **NAV definition.** “Token NAV per Token” means:\ **(Series Assets – Series Liabilities) / Tokens outstanding**, determined as of the valuation time. 7.2 **Valuation frequency.** Minimum twice per week. 7.3 **Valuation sources.** * On-chain assets: Chainlink or equivalent asset oracle * CEX positions: n/a * Off-chain assets: n/a * FX (if relevant): n/a 7.4 **Market disruption fallback.** If standard sources are unavailable, Issuer uses a reasonable fallback consistent with market practice and the General Terms, including execution-based realisation values. 7.5 **Publication.** NAV is published via update to the vault NAV value. *** ### 8) Redemptions and Settlement 8.1 **Redemption method.** Redemption is initiated via: * Onchain redemption request 8.2 **Redemption windows & SLAs.** * **Cutoff:** n/a * **Processing target:** T+2 Delays may occur due to Market Disruption, illiquidity, compliance, or operational constraints. 8.3 **Redemption pricing.** * **Redemption price basis:** min of NAV at {redemption request, redemption processing} * **Redemption Amount = Tokens redeemed × Redemption NAV per Token − fees − properly attributable costs** 8.4 **Redemption fees.** 0% \[except gas fees]. 8.5 **Settlement mechanics.** Paid in: * **Stablecoin:** USDC to wallet provided by Tokenholder; or * **Fiat:** bank transfer to verified account;\ Subject to compliance verification and sanctions screening. 8.6 **In-kind redemption (optional).** Optional 8.7 **Redemption source and limited recourse.** Redemptions are funded solely from Series Assets after applying the Series Waterfall. *** ### 9) Fees, Expenses, and Series Waterfall 9.1 **Fee schedule.** * **Management fee:** 2% per annum * **Performance fee:** 0% of net profits with high-water mark model, crystallised at NAV distribution. * **Other fees:** gas fees at processing redemptions. 9.2 **Pass-through expenses.** Series pays properly attributable third-party costs: custody/MPC, exchange fees, prime broker fees, gas, oracle/data, audit/security allocated to the Series (if any), banking fees, legal/admin costs allocated to the Series. 9.3 **Series Waterfall.** Unless otherwise specified: 1. Series costs/expenses; 2. fees; 3. Tokenholder redemptions/payments. *** ### 10) Risk Limits and Portfolio Constraints 10.1 **Exposure constraints.** * Directional exposure: <1% delta * Leverage cap: n/a * Single counterparty concentration: n/a * Single protocol concentration: n/a * Stablecoin concentration: n/a * Duration cap (if fixed income): n/a * Borrowing permitted: Yes. 10.2 **Collateral and margin.** * Margin buffers: n/a * Liquidation policies: n/a * Rebalancing frequency: n/a 10.3 **Prohibited activities.** unwhitelisted protocols, long-only risk, etc. *** ### 11) Points, Airdrops, Rebates, and Incentives (If Applicable) 11.1 **Treatment policy.** Any points/airdrops/rebates attributable to Series activity are treated as: * retained by Series and reflected in NAV / or * distributed to Tokenholders under a disclosed program 11.2 **Disclosure.** Method and timing of recognition in NAV: As and when realised. *** ### 12) Reporting and Transparency 12.1 **Standard reporting.** Issuer provides: * NAV history and current NAV * Holdings/exposure summary * Performance metrics: APY * Material events: security incidents, counterparty failures, wind-down events 12.2 **Frequency.** At least twice per week on best effort basis 12.3 **Audit/attestation (optional).** proof-of-reserves attestation *** ### 13) Series Wind-Down and Termination 13.1 **Triggers.** As per General Terms (Series Wind-Down Events) plus any Series-specific triggers. 13.2 **Process.** Issuer may suspend mint/redemption/transfers (if enabled), unwind positions, realise Series Assets, determine final realisation value, and distribute Series Assets (if any) pro rata after Series Waterfall. 13.3 **No top-up.** No obligation to contribute Operational Assets or other Series assets unless expressly stated. *** ### 14) Conflicts, Discretion, and Material Changes 14.1 **Conflicts.** n/a 14.2 **Issuer discretion.** Issuer discretion is limited to reasonable actions consistent with Product Documentation, especially during market disruption or wind-down. 14.3 **Material adverse changes.** Material adverse changes follow the General Terms notice framework (with emergency exception for security/compliance). *** ### 15) Risk Disclosures As detailed in General Risk Disclosures *** ### 16) Notices and Contact * **Official notices channel:** Discord / Telegram * **Support contact:** Discord / Telegram * **Effective date of these Token Terms:** From the date of smart contract deployment * **Version:** n/a *** ### 17) Execution Blocks * **Minimum ticket:** n/a * **Operational onboarding:** n/a * **Settlement instructions:** n/a * **Cutoff times:** n/a * **Redemption cadence:** n/a # Investment Disclaimer #### Jurisdictional Restrictions These materials are not directed to, and must not be accessed by, any U.S. Person or any person located in the United States. YieldFi (the “Issuer”) does not offer or sell Tokens to U.S. Persons, nor are Tokens marketed, solicited, or distributed in the United States or in any other jurisdiction where such activities would be unlawful.\ Details on restricted jurisdictions, eligibility requirements, and distribution limitations are set out in the Terms & Conditions and related legal documentation. #### No Offer or Solicitation These materials are provided for general informational purposes only and do not constitute an offer, solicitation, invitation, or recommendation to acquire Tokens or any other financial instruments. Any issuance of Tokens (or blockchain-based certificates, where applicable) is made solely on the basis of the relevant formal legal documentation (including, where applicable, Token Terms and other binding issuance documentation). Prospective investors must rely exclusively on such documentation when making any investment decision. #### No Regulatory Endorsement Any approval, registration, or review of documentation by a regulator (where applicable) should not be interpreted as an endorsement of the Issuer, the Tokens (or blockchain-based certificates), or the merits of any offering. #### Risk Disclosure Tokens (or blockchain-based certificates) issued by YieldFi are high-risk instruments. They are not deposits, not bank products, and are not protected by any investor compensation or deposit protection scheme. YieldFi’s vault structure is designed as a bankruptcy-remote arrangement with segregation of user funds at the vault level; however, investors remain exposed to risks including (without limitation) market risk, liquidity risk, counterparty risk, operational risk, technology risk, smart contract risk, custody and key-management risk, and legal/regulatory risk, and may suffer a partial or total loss of their investment. The value of Tokens (or blockchain-based certificates) may fluctuate and may not perfectly track any reference value or underlying exposure due to fees, market conditions, liquidity constraints, timing effects, or operational mechanics. Past performance is not indicative of future results. #### No Advice; Independent Assessment Required Nothing in these materials constitutes legal, tax, investment, or other professional advice, nor should any content be interpreted as a personal recommendation. You are solely responsible for assessing suitability for your circumstances and should seek independent professional advice where appropriate. #### Third-Party Information Any information attributed to third parties reflects the Issuer’s interpretation of publicly available or licensed sources and has not been independently verified or endorsed by such third parties. # Privacy Policy Effective Date: 13 January, 2026\ Controller: YieldFi\ Website: [https://yield.fi](https://yield.fi/) *** ### I. General YieldFi takes data protection, privacy, and information security seriously. The careful, transparent, and responsible handling of personal data is a core part of our operations and reflects our commitment to user trust, regulatory compliance, and institutional standards. This Privacy Policy explains how we collect, use, process, store, disclose, and protect personal data when you: * Visit or use our website (yield.fi and related domains), * Interact with our applications, interfaces, APIs, SDKs, or documentation, * Onboard or complete identity verification, * Communicate with us via email, forms, or community channels, or * Otherwise interact with YieldFi and its services. This policy is designed to align with the principles of the EU General Data Protection Regulation (“GDPR”), including transparency, purpose limitation, data minimisation, and security, and may also be relevant under other privacy frameworks depending on your jurisdiction. You can use certain parts of our website without providing personal data. However, some services (e.g., onboarding, compliance checks, or communication features) necessarily require the processing of personal data. *** ### II. Data Controller and Contact Details The data controller responsible for processing your personal data is: Email: \ Website: [https://yield.fi](https://yield.fi/) For any questions relating to privacy, data protection, or to exercise your rights, you can contact us at the email address above. We will make reasonable efforts to respond within applicable legal timeframes. *** ### III. Definition of Personal Data “Personal data” means any information that relates to an identified or identifiable natural person. This may include, depending on context: * Name and contact details (e.g., email address), * Online identifiers (e.g., IP address), * Identity verification data, * Wallet addresses where linked to an identifiable individual, * Communication content, * Technical identifiers and usage data. Anonymous data or data that has been irreversibly anonymised is not considered personal data. *** ### IV. Cookies and Technical Data Collection #### 1. Cookies We use cookies and similar technologies to ensure website functionality, enhance security, and improve user experience. Cookies are small text files stored on your device by your browser. They may include: * Strictly necessary cookies (required for basic functionality and security), * Session cookies (temporary cookies deleted when you close your browser), * Preference cookies (to remember settings, where applicable), * Analytics or performance cookies (where enabled). You can control or disable cookies through your browser settings. Please note that disabling certain cookies may affect functionality or access to some features. #### 2. Server Log Data When you access our website, our servers may automatically collect certain technical information, including: * Browser type and version * Operating system * Referrer URL * Pages accessed * Date and time of access * IP address This data is processed primarily for: * Ensuring the security and stability of the website, * Detecting abuse or malicious activity, * Diagnosing technical issues, * Improving performance and user experience. We do not use this information to directly identify you. The legal basis for this processing is our legitimate interest in operating a secure and reliable service. *** ### V. User Onboarding and Account-Related Data Certain services offered by YieldFi (such as access to minting, redemption, or compliance-gated functionality) may require onboarding. During onboarding, we may collect and process the following categories of data (“Customer Data”): * Full name * Email address * Country of residence * Wallet address(es) * Account-related metadata (e.g., timestamps of activity) We process this data to: * Provide access to our services, * Maintain system integrity and prevent misuse, * Communicate with you regarding your use of the service, * Meet contractual and operational obligations. The legal basis for processing is typically the performance of a contract and our legitimate business interests. We retain onboarding data for as long as your account or relationship with YieldFi remains active, unless a longer retention period is required by law. *** ### VI. Identity Verification (KYC / Compliance Processing) In certain cases, we are required (by law, regulation, risk policy, or commercial partner requirements) to perform identity verification and compliance checks. Where applicable, identity verification may be conducted through third-party KYC / compliance service providers. Depending on jurisdiction and risk context, this may involve processing of: * Full legal name * Date and place of birth * Nationality * Residential address * Verification result (e.g., approved / rejected) * Government-issued ID details (passport or national ID) * Proof of address * Tax identification numbers * Source of funds or source of wealth information (where required) We process this data for the purposes of: * Complying with applicable AML/CFT and sanctions laws, * Protecting the platform against fraud and abuse, * Meeting obligations to partners or service providers, * Enabling contractual access to services. Where possible, we seek to minimise the amount of personal data processed and rely on verification outcomes rather than raw documents. *** ### VII. Communications and Newsletter If you contact us (e.g., via email, forms, or support channels), we process the information you provide, such as: * Your name * Email address * Message content * Any additional information you voluntarily provide We use this data solely to respond to your request, provide support, or communicate regarding services. If you choose to subscribe to updates or newsletters, we may send you product updates, educational materials, or company news. You can unsubscribe at any time using the link in the communication or by contacting us. Legal basis for processing in this context is consent and/or legitimate interest in maintaining communications. *** ### VIII. Social Media and Community Platforms YieldFi maintains a presence on external platforms such as X (Twitter), Telegram, Discord, and similar services. When you interact with us via these platforms: * Your data is primarily processed by the platform provider under their own privacy policy, * We may see public interactions (e.g., messages, replies, reactions), * We may receive anonymised or aggregated analytics about engagement. We do not control how third-party platforms process your personal data. We encourage you to review their respective privacy policies. *** ### IX. Disclosure of Data to Third Parties We may share personal data with carefully selected third-party service providers who assist us in operating our services, including: * Cloud infrastructure and hosting providers * IT and cybersecurity providers * Compliance and KYC service providers * Communication and support tools * Analytics providers These providers act as processors on our behalf and are contractually required to: * Process data only according to our instructions, * Apply appropriate confidentiality and security safeguards, * Not use the data for their own independent purposes. We may also disclose personal data where required to do so by law, regulation, court order, or where necessary to protect our rights, enforce agreements, or prevent harm. Where data is transferred internationally, we take reasonable measures to ensure appropriate safeguards are in place. *** ### X. Data Retention We retain personal data only for as long as necessary for the purposes described in this Privacy Policy, including: * Providing and maintaining services * Complying with legal or regulatory obligations * Resolving disputes * Enforcing agreements * Maintaining security and audit trails When data is no longer required, it is deleted, anonymised, or securely archived in accordance with applicable law. *** ### XI. Your Rights Depending on your jurisdiction, you may have the following rights in relation to your personal data: * Right to access your personal data * Right to correct inaccurate or incomplete data * Right to request deletion (subject to legal retention obligations) * Right to restrict certain processing * Right to data portability * Right to object to processing based on legitimate interests You can exercise these rights by contacting us at . We may request verification of identity before fulfilling requests. *** ### XII. Security Measures We implement technical and organisational security measures designed to protect personal data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access. These measures may include: * Access controls * Encryption where appropriate * Segmentation of systems * Monitoring and logging * Vendor risk assessments Vault structure note (informational): YieldFi’s products are implemented as a bankruptcy-remote structure with complete segregation of funds at the vault level, and positions may be represented through blockchain-based certificates. However, no system is entirely secure. You acknowledge that transmission of data over the internet involves inherent risks. *** ### XIII. Changes to This Privacy Policy We may update this Privacy Policy from time to time to reflect changes in law, technology, or our operations. Updated versions will be published on our website with a revised effective date. We encourage you to review this policy periodically. *** ### XIV. Contact If you have any questions about this Privacy Policy or how we handle your data, please contact us at:\ Email: # Eligibility Criteria YieldFi products are designed for users with a high degree of technical competence and risk awareness. By interacting with Tokens and/or blockchain-based certificates (together, “YieldFi Instruments”) or associated interfaces, you confirm that you meet the criteria below and understand the risks involved. These criteria are intended to help ensure that participants can responsibly interact with non-custodial infrastructure and assess the risks of sophisticated on-chain financial products. *** #### Technical and Operational Proficiency You should reasonably be able to demonstrate the following capabilities: * Proficiency using non-custodial wallets (e.g., MetaMask, Rabby, Safe, hardware wallets). * Ability to securely manage private keys, seed phrases, and wallet permissions. * Experience interacting with Layer 2 networks and alternative blockchain ecosystems (e.g., Arbitrum, Optimism, Base, Berachain). * Competence in signing, approving, and revoking on-chain transactions. * Familiarity with decentralised exchanges (DEXs), aggregators, and DeFi interfaces. * Understanding of core DeFi concepts such as LP tokens, slippage, gas fees, transaction finality, and MEV. * Awareness of differences between APR and APY, impermanent loss, and yield mechanics. * Understanding of smart contract risks, oracle risks, governance risks, and protocol-level exploits. * Familiarity with collateralisation models, liquidation thresholds, and minting/redemption mechanics (where applicable). * Habit of reviewing documentation before interacting with contracts. * Practice of verifying contract addresses and interfaces prior to transactions. * Ability to monitor positions using on-chain tools (e.g., DeBank, Zapper, Arkham). * Awareness of potential tax obligations arising from crypto activity. * Capacity to review third-party audits and security reports at a high level. * Use of appropriate security practices (e.g., hardware wallets, multisig, wallet segmentation). * Emotional and financial discipline when navigating volatile market conditions. YieldFi does not assess individual competence and bears no responsibility for losses resulting from user error, misuse, or failure to follow security best practices. *** #### Product Structure and Key Risks * YieldFi Instruments are high-risk and may result in partial or total loss. * YieldFi’s vault structure is designed as a bankruptcy-remote arrangement with complete segregation of user funds at the vault level; however, this design does not eliminate risks, including (without limitation) market risk, liquidity risk, counterparty risk, operational risk, technology risk, smart contract risk, custody/key-management risk, oracle risk, governance risk, and legal/regulatory risk. * The value of YieldFi Instruments may fluctuate and may not perfectly track any reference value or underlying exposure due to fees, market conditions, liquidity constraints, timing effects, slippage, and operational mechanics. * Past performance is not indicative of future results. *** #### Legal and Compliance Criteria By interacting with YieldFi products, you confirm that: * You are legally permitted to enter into binding agreements (typically 18+). * You comply with all applicable local laws relating to digital assets and financial products. * You are solely responsible for determining whether YieldFi Instruments are lawful to acquire, hold, use, or dispose of in your jurisdiction. * Your funds are derived from legitimate sources and are not linked to unlawful activity. * You are not subject to sanctions or restrictions under Applicable Law. *** #### Restricted Jurisdictions YieldFi Instruments are not offered to U.S. Persons, nor to any person or entity located in or ordinarily resident in the United States. YieldFi Instruments are also restricted in certain other jurisdictions due to regulatory, legal, or compliance considerations, including (but not limited to): * The United Kingdom * China * Jurisdictions subject to international sanctions You are solely responsible for verifying whether you are permitted to access YieldFi products under your local law. For the latest restrictions and binding documentation, please refer to the Legal Documents section. *** #### Acknowledgement By dealing in YieldFi Instruments, you confirm that: * You understand the technical, legal, and financial risks involved, * You meet the eligibility criteria above, and * You accept full responsibility for your participation. If you do not meet these criteria, you must not interact with YieldFi Instruments or associated systems. # Verifications and Screenings #### Verification Processes YieldFi implements a layered set of technical, compliance, and operational controls to help enforce eligibility restrictions and mitigate misuse of the platform. These controls are designed to support regulatory compliance, sanctions obligations, and risk management. However, they do not guarantee that prohibited users will never attempt to access the platform, and they do not eliminate all risks associated with interacting with **Tokens and/or blockchain-based certificates** (together, “YieldFi Instruments”). *** ### In-App Screening Processes #### IP and Geolocation Screening When a user visits the YieldFi website or application, their IP address may be automatically analysed to estimate geographic location.\ If an IP address is identified as originating from a restricted jurisdiction, access to the website or certain functionalities may be blocked.\ This process may also include measures designed to detect and restrict access via VPNs, proxy services, or anonymisation tools where such access is inconsistent with compliance requirements. #### Wallet Screening YieldFi may perform screening checks when a user connects a wallet to the platform. These checks are designed to identify wallets associated with: * Sanctioned entities * Known illicit activity * High-risk blockchain exposure * Compliance red flags If a connected wallet is flagged by screening tools, the platform may automatically disconnect the wallet and restrict access to wallet-based functionality. #### Acceptance of Legal Documentation Before interacting with YieldFi Instruments or compliance-gated features, users may be required to review and explicitly accept the General Terms and Conditions, applicable product terms (including **Token Terms and/or certificate terms**, where applicable), and related legal disclosures. These documents state that participation from prohibited jurisdictions is not permitted. *** ### Onchain Screening Processes At the smart contract level, certain minting and redemption contracts may integrate third-party compliance or sanctions screening infrastructure (where technically feasible).\ This may include blockchain compliance oracles (such as Chainalysis or equivalent providers) that maintain lists of sanctioned or restricted wallet addresses. Where implemented, addresses identified by such systems may be prevented from minting, redeeming, or interacting with certain smart contract functions. Onchain compliance controls depend on the capabilities of the underlying network and tooling and may not be available across all deployments. *** ### Offchain Transfers (Fiat-Based Processing) Investors wishing to subscribe or redeem YieldFi Instruments using fiat (e.g., USD bank transfers) must follow a manual compliance process. Such investors may be required to: * Contact the YieldFi team via the official support channel * Complete onboarding and KYC/AML verification * Receive explicit written approval from YieldFi’s compliance function Once approved, the investor may be added to a compliance allowlist (commonly referred to as a “greenlist”) for fiat-based processing. Confirmation is typically provided via email. Approval timelines may vary depending on complexity of review and may take several business days. Greenlisting for fiat transactions applies only to offchain processing and does not guarantee ongoing eligibility across all products, vaults, or jurisdictions. *** ### Important Note These verification mechanisms are designed to support compliance efforts but: * Do not guarantee that all prohibited activity will be detected or prevented * Do not replace the user’s responsibility to comply with applicable laws * Do not create any obligation for YieldFi to permit access * Do not change the fact that YieldFi’s products are implemented with a **bankruptcy-remote structure and complete segregation of user funds at the vault level**, which is an architecture and risk-management design and not a guarantee against loss YieldFi reserves the right to restrict, suspend, or terminate access to any user at any time where required for legal, regulatory, security, or risk management reasons.