# FAQs
#### What is Evolve?
**Evolve** is the issuer of **eUSD** — a yield-bearing stablecoin on the **SEI** chain. eUSD is designed to deliver **stable, transparent yield** through a diversified portfolio of:
* **RWA yield**
* **AI infrastructure yield**
* **Onchain lending yield tokens on SEI**
***
#### What is eUSD?
**eUSD is a yield-bearing token on SEI that targets USD stability while earning yield.**\
You hold a single token (eUSD) that represents a claim on a yield-generating portfolio managed under Evolve’s disclosed mandate and controls.
***
#### Who is Evolve for?
Evolve is built for four types of users:
* **Capital Allocators** → simple yield exposure with clear redemption terms
* **Builders / Distribution Partners** → wallets, exchanges, fintechs, banks, wealth tech, LP networks offering “Earn”
* **Treasury & Finance Teams** → DAOs and corporates that need stable yield + reporting
* **DeFi Power Users** → users who want a yield-bearing stablecoin they can hold, redeem, and use across SEI DeFi
***
#### What problem does Evolve solve?
Stable yield is fragmented and operationally complex (multiple venues, wrappers, liquidity constraints, and inconsistent reporting). Evolve makes yield:
* **Accessible** via a single yield-bearing stablecoin (eUSD)
* **Composable** across the SEI DeFi ecosystem
* **Measurable** with standardized NAV/APY and disclosure-driven transparency
***
#### Where does the yield come from?
eUSD’s yield can come from three primary sources (allocation varies over time):
1. **RWA Yield**\
Rate- and credit-driven yield from real-world asset exposure, structured and disclosed via eUSD documentation.
2. **AI Infrastructure Yield**\
Yield generated from exposure to AI-infra cashflow opportunities (e.g., capacity / compute-linked yield structures), implemented through the product’s disclosed strategy sleeves and counterparties.
3. **SEI Lending Yield Tokens**\
Onchain lending yields driven by borrow demand in SEI markets and protocols (via lending vaults / yield tokens).
Each sleeve’s **venues, drivers, and constraints** is shown on the eUSD transparency page / factsheet.
***
#### Is the APY “real,” or does it include points and incentives?
Displayed APY reflects **realized, mark-to-market yield**.\
**Unrealized incentives** (points, airdrops, emissions) are **not included** in APY and are **additive** only if they materialize.
***
#### What fees do I pay?
Displayed APY is **net of fees**. Fees are disclosed on the **eUSD factsheet** and may include:
* **Management fee** and/or **performance fee**
***
#### How do I get started?
Typical onboarding flow:
1. Visit the **Evolve app** (eUSD page)
2. Connect your EVM wallet
3. Deposit supported collateral (as listed)
4. Mint **eUSD** (instantly)
***
#### How long does redemption take?
Redemption can take **few hours to \~T+2** days.
***
#### Do I need KYC/KYB? Who is eligible?
No
***
#### Are there minimums, maximums, or caps?
No
***
#### What does “yield-bearing stablecoin” mean?
It means you receive an **ERC-20 token (eUSD)** that aims to track USD value while earning yield through portfolio performance.
You can typically:
* **Hold** eUSD
* **Redeem** eUSD (per terms)
* **Use eUSD in DeFi** on SEI (LP, collateral, leverage looping, tranching, etc.), where supported
***
#### Who manages the capital?
eUSD is managed under Evolve’s disclosed allocation framework. Evolve may rebalance across sleeves based on:
* Liquidity needs (redemption capacity)
* Risk limits (concentration, counterparty, protocol exposure)
* Market conditions (rates, spreads, onchain lending demand)
If third-party operators or counterparties are involved, their role and oversight are disclosed in the factsheet.
***
#### How does Evolve handle custody and security?
Evolve uses institutional-grade controls where applicable, such as:
* **Segregated custody wallets** and policy-controlled signers
* **Segregated venue/protocol positions** for sleeve-level accounting
* **Least-privilege access**, approvals, monitoring, and incident playbooks
Custody/control models are disclosed per sleeve where relevant (especially for RWA and AI infra exposures).
***
#### What risks should I understand?
Key risk categories include:
* **Market risk** (rates, spreads, credit)
* **Liquidity risk** (queues, redemption windows, market depth)
* **Counterparty risk** (issuers, custodians, borrowers, venues)
* **Smart contract / protocol risk** (SEI DeFi, integrations)
* **Operational risk** (controls, processes, execution)
* **Regulatory / eligibility risk** (jurisdiction restrictions, access constraints)
If the underlying portfolio loses value, **eUSD NAV can decline**.
***
#### What happens in stressed markets or a black swan?
Behavior is product-defined and may include:
* **Redemptions moving into a queue**
* **Reduced risk exposure** / rotation toward higher-liquidity sleeves
* **Orderly unwinds** rather than forced liquidations
Illustrative example:
* eUSD TVL: **$100M**
* You hold: **$1M** (1% of supply)
* Instant liquidity drops from **100% → 20%**
* Remaining redemptions settle over a disclosed window (e.g., **T+2**)
* If NAV changes during unwinds, settlement occurs at the **updated NAV**
***
#### Is APY net of fees?
Yes. Displayed APY is always **net of fees**.
***
#### How is NAV (token price) calculated?
A standard definition:
**NAV = (Assets − Liabilities) ÷ eUSD Supply**
The eUSD factsheet should disclose:
* Pricing sources / valuation policy
* Any buffers/haircuts (if used)
* Treatment of accrued yield and costs
***
#### How often is NAV updated?
NAV cadence is disclosed (commonly **daily**, sometimes **event-driven**).\
If an epoch-based update or anti-front-running mechanism exists, it will be disclosed. In general:
* NAV may update on a schedule for predictability
* Material downside updates may be applied immediately if specified
***
#### Is eUSD a bank deposit or insured product?
No. eUSD is **not a bank deposit** and does not carry deposit insurance. It is a **tokenized yield product** governed by its disclosed terms and risk factors.
***
#### What does transparency look like?
Where feasible, eUSD provides standardized disclosure of:
* **NAV, APY, TVL history**
* **Sleeve breakdown** (RWA vs AI infra vs SEI lending yield tokens)
* Counterparty / venue exposure (where applicable)
* Redemption liquidity and queue status
* Attestations / audit reports
***
#### Can I borrow against eUSD?
Potentially, yes—if eUSD is listed or supported by SEI lending markets or partner venues such as Takara Lend, Yei and/or Morpho markets on SEI. Availability depends on ecosystem support and risk parameters set by those protocols.
***
#### Is Evolve DeFi-native or institutional-grade?
Both: **institutional-style controls and disclosure**, with **DeFi-native distribution and composability** on SEI.
***
#### Want to integrate eUSD into your product?
Evolve can support integration rails (as applicable):
* List eUSD in your app
* Display NAV/APY + key terms
* Enable mint + redemption flows (including request → processing if queued)
* Support DeFi utility paths on SEI where supported (collateral, LP, looping)
# About Evolve
Yield-bearing money for the SEI economy
**Evolve** issues **eUSD** — a **yield-bearing stablecoin** on the **SEI** chain. eUSD is designed to be a programmable, composable unit of account that earns yield from a diversified set of onchain and offchain sources, including:
* **RWA yield**
* **AI infrastructure yield**
* **SEI-native lending yield tokens**
Today, most “yield” products still live offchain: opaque vehicles, delayed reporting, and fragmented distribution. Evolve brings **stable yield onchain** in a format that is **simple to hold**, **easy to integrate**, and **usable across DeFi**.
***
### Why eUSD exists
Stablecoins upgraded money for the internet. **eUSD upgrades stablecoins** by embedding yield and transparency into the token itself.
Instead of requiring users to chase yields across multiple venues, wrappers, and products, eUSD provides a **single token** that can:
* **Settle 24/7 on SEI**
* **Be used across DeFi** (collateral, LP, looping, markets), where supported
* **Expose live product signals** (NAV, APY history, TVL, sleeve exposure, liquidity status)
* **Integrate into partner “Earn” experiences** without rebuilding a full product stack
This is the stablecoin evolution: **not just holding dollars onchain, but holding dollars that work.**
***
### How eUSD works
eUSD represents a position in a yield-generating portfolio managed under Evolve’s disclosed mandate. The portfolio may allocate across:
#### 1) RWA yield
Rate- and credit-driven yield sourced from real-world asset exposure (structure and counterparties disclosed where applicable).
#### 2) AI infrastructure yield
Yield sourced from AI-infrastructure cashflow opportunities (capacity/compute-linked structures or equivalent sleeves), implemented via disclosed strategies and counterparties.
#### 3) SEI lending yield tokens
Onchain lending yields driven by borrow demand across SEI markets and lending vaults.
eUSD yield is reflected via **NAV appreciation** (token price increases over time) and/or other disclosed mechanisms defined in the eUSD terms.
***
### What makes eUSD different
Traditional yield products rely on trust-me reporting and slow reconciliation cycles. eUSD is built to be **programmable** and **observable**.
Where feasible, eUSD is designed to expose:
* **NAV and APY history**
* **TVL and supply changes**
* **Sleeve allocations** (RWA / AI infra / SEI lending)
* **Liquidity and redemption status** (queues, windows, capacity)
* **Exposure and concentration signals** (where applicable)
* **Attestations / audits** (when applicable)
This makes eUSD easier to monitor for allocators and safer to distribute for partners — because product behavior is **explicit**, not implied.
***
### Who Evolve is for
Evolve is built for:
* **Capital allocators** → one-click stable yield with clear terms
* **Treasury teams (DAOs + corporates)** → onchain yield-bearing cash management
* **DeFi power users** → composable yield-bearing stablecoin utility on SEI
* **Distribution partners** → wallets, exchanges, fintechs, wealth tech, LP networks offering “Earn”
***
### Important links
* **Website:**
* **Docs:**
* **Twitter / X:**
* **Telegram:**
* **Discord:**
***
{% hint style="info" %}
### Legal & risk disclosure (high level)
eUSD is a **tokenized yield product** issued by Evolve. Tokenholder rights are defined by the applicable **terms, disclosures, and offering documentation**.
* Holding eUSD **does not necessarily** give you legal or beneficial ownership of underlying assets.
* eUSD may represent a **contractual claim against the issuer** and may be **contractually subordinated** depending on the structure.
* In an insolvency scenario, payments may be restricted and claims may rank below senior creditors in accordance with the applicable subordination terms.
For a complete description of rights, terms, and risk factors, refer to the **applicable eUSD documentation**.
{% endhint %}
# Value Proposition
#### 1) Capital efficiency
**eUSD is a programmable, yield-bearing stablecoin on SEI.** Where supported by the ecosystem, allocators can **borrow against eUSD**, use it as **collateral**, or **loop strategically** for capital efficiency and short-term liquidity—without exiting the underlying yield position.
#### 2) Real-time transparency vs “trust-me” reporting
Instead of waiting for monthly/quarterly statements, allocators can track **eUSD NAV**, **APY history**, **TVL/supply**, **sleeve exposures** (RWA / AI infra / SEI lending), **liquidity/redemption status**, and **proof-of-reserves / attestation artifacts** (where applicable)—making allocation decisions and monitoring meaningfully sharper.
#### 3) Institutional analytics built in (no vendor sprawl)
Evolve is designed to provide institutional-grade reporting for eUSD out of the box, such as **Sharpe/Sortino**, **VaR/CVaR**, **drawdowns + recovery**, **liquidity ladders**, **concentration by sleeve/counterparty/protocol**, and **redemption SLA history**—without requiring allocators to stitch together multiple third-party tools.
#### 4) Operational simplicity
Allocation is standardized: **one asset (eUSD)**, **consistent mint/redemption flows**, and **unified reporting** across underlying yield sleeves—so allocators can access diversified yield without bespoke fund docs, incompatible data formats, or manual reconciliation.
#### 5) Composability + portfolio construction
eUSD can plug into SEI DeFi portfolio construction—**lending markets**, **LP positions**, **structured products**, **tranching**, and **hedging overlays**—enabling onchain risk management workflows that are difficult to replicate offchain.
# How It Works
**eUSD** is a yield-bearing token on **SEI**. It represents a pro-rata claim on a **bankruptcy-remote segregated vault structure** that holds the underlying yield sleeves (e.g., **RWA yield**, **AI infrastructure yield**, and **SEI lending yield tokens**) and reflects strategy performance through a periodically updated **Net Asset Value (NAV)**, net of applicable fees.
Users interact with eUSD through two core flows:
* **Mint (instantaneous)**
* **Redeem (request → queue → payout)**
***
#### Mint (Instantaneous)
When you deposit a supported asset into Evolve to mint **eUSD**, the system mints **eUSD** at current NAV to your wallet, representing your pro-rata claim on the eUSD vault.
***
#### Redemption (Redeem Queue → Payout)
To redeem **eUSD**, you submit a redemption request which enters the **RedeemQueue**. You may cancel the request any time before it is processed.
Once processed:
* the redeemed **eUSD** is **burned**, and
* the underlying assets are transferred to the specified receiver wallet address (per the supported payout rails).
***
#### Yield Distribution
Yield is distributed by **updating eUSD NAV** to reflect portfolio performance, net of any applicable fees.
* **Positive performance (NAV ↑):**\
If the new NAV is above the **High Water Mark**, the increase is not applied as a single step. Instead, the NAV update is **vested over a defined epoch period**, reducing the ability to front-run a known NAV jump by minting right before it or redeeming right after it.
* **Negative performance (NAV ↓):**\
If the new NAV is below the current NAV, the NAV update is applied **instantly**, ensuring losses are reflected immediately.\
Even in this scenario, front-running is mitigated because redemptions can be configured to settle at the **lower of Current NAV or End-of-Epoch NAV**, preventing users from exiting at a temporarily higher NAV before accounting is finalized.
***
#### Redemption SLAs & Fees
Expected redemption processing times and all applicable fees are disclosed on the **eUSD factsheet / product page**, so users can evaluate liquidity and costs before minting.
# Fees
Displayed APY is net of fees. Evolve charges 1% management fees per year on the eUSD circulating supply.
# Flow of Funds
This page describes the standard flow of funds where **Evolve** issues multiple yield products (including **eUSD** and future vault products). Each Vault is a distinct product/strategy with **bankruptcy-remote segregated vault structure**, **segregated asset control**, and **vault-specific accounting** implemented using **segregated MPC wallets** and (where relevant) **segregated exchange sub-accounts** per Vault.
***
### Structure at a glance
Evolve creates multiple Vaults (e.g., **Vault A / Vault B / Vault C**). Users deposit into a specific Vault, and Evolve issues the Vault’s receipt token/position to the user under that Vault’s terms.
**Core principle:** assets, liabilities, cashflows, and reporting are **Vault-specific**. Segregation is implemented via:
* **Segregated MPC wallets per Vault** (deposit, strategy/collateral, redemption/processing)
* **Segregated exchange sub-accounts per Vault** (where execution requires exchanges)
***
### Parties and roles
* **Users**\
Deposit into a specific Vault and hold the Vault receipt token/position.
* **Issuer — Evolve**\
Creates Vaults, defines Vault terms (with Curator input where applicable), issues tokens/positions, and oversees service providers and controls.
* **Vault**\
Product-level pool with its own **bankruptcy-remote segregated vault structure**, accounting, and terms.
* **Curator / Strategy Operator**\
Executes the strategy for a Vault and manages risk with respect to deployments, rebalances, and liquidations (within defined policies).
* **Segregated MPC Wallets (per Vault)**\
Onchain wallets dedicated to each Vault (e.g., **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 books and records, 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: Evolve
|
| creates Vaults + publishes Vault terms + appoints Curator (if applicable)
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
#### 1) 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. Evolve issues the Vault token/position to the user under **Vault A** and updates Vault-level accounting.
***
#### 2) Deployment / execution (Vault → DeFi / Exchanges)
1. Assets are held in Vault A’s MPC wallets under vault-specific policies.
2. If the strategy uses exchanges, assets may be transferred to **Vault A’s segregated exchange sub-accounts** (and later swept back, where applicable).
3. Curator/strategy operator executes actions for Vault A within defined permissions:
* DeFi deployments (whitelisted protocols/endpoints)
* Exchange execution / hedging
* Rebalances and risk actions
***
#### 3) Income and P\&L collection (DeFi / Exchanges → Vault)
Strategy income, realized P\&L, and principal flows return to Vault A attribution via:
* Vault A **collateral/strategy MPC wallets**, and/or
* Vault A **exchange sub-accounts**, with periodic sweeps back to MPC wallets where applicable.
***
#### 4) Fees and expenses (paid from the Vault)
Vault-level fees (management and/or performance, if applicable) are:
* accrued and settled from **Vault A assets only**, and
* recorded in **Vault A books and records**.
No other Vault is impacted.
***
#### 5) Distributions (if the Vault pays out)
If Vault A supports periodic payout:
* Evolve processes distributions from **Vault A’s redemption/processing MPC wallet** to user wallets, per Vault terms.
***
#### 6) Redemption (Vault → User)
1. User submits a redemption request for Vault A (per redemption rules, cooldowns, and limits).
2. Evolve calculates redemption amount based on **Vault A 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. Evolve pays the user from **Vault A’s redemption/processing MPC wallet** and burns/reduces the user’s Vault token/position.
***
### Segregation rules (what this prevents)
Segregation is enforced at the Vault level through:
* a dedicated MPC wallet set per Vault (**deposit**, **collateral/strategy**, **redemption/processing**), plus
* segregated exchange sub-accounts with clear Vault attribution, plus
* Vault-specific books and records (positions, P\&L, NAV, token supply, user balances)
**Cross-Vault transfers are prohibited** unless explicitly defined by product terms and controls (e.g., formal migration processes with disclosures).
***
### In summary
Evolve’s architecture is designed to ensure each Vault operates as its own **bankruptcy-remote segregated vault structure** with:
* vault-specific custody and execution rails
* vault-specific accounting and reporting
* clear attribution of assets, liabilities, cashflows, and performance
This enables multiple products (including eUSD and future vaults) to run in parallel without commingling risk or operational ambiguity.
# Operational Control
This page describes the operational control model where **Evolve** operates multiple Vaults (including **eUSD** and future products). The model replaces traditional administrator and agency functions with a **software-driven control layer**, uses **segregated MPC wallets** and **exchange sub-accounts** for custody and execution, and makes the **Curator / Strategy Operator** the primary risk owner for each Vault within a defined mandate.
***
### Operating model
Evolve creates multiple Vaults (e.g., **Vault A / Vault B / Vault C**). Each Vault is a distinct product with its own terms, **bankruptcy-remote segregated vault structure**, asset segregation, accounting, and reporting.
Operational control is enforced through:
1. **Vault-level mandates** (terms, limits, escalation rules)
2. **Software modules** that implement lifecycle + accounting rules
3. **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
#### Evolve
* 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 where applicable)
* Approves Curator appointment and maintains a Vault-specific mandate for the Curator
* Oversees whitelisting of DeFi protocols and execution endpoints based on Curator requirements and internal controls
#### Curator / Strategy Operator
* 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 mints and redemptions per Vault terms (windows, limits, queues)
* Mints/burns Vault tokens and maintains the 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/exposures, 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)
Each Vault uses segregated onchain wallets, typically including:
* **Deposit wallet(s)**
* **Collateral/strategy wallet(s)**
* **Redemption/processing wallet(s)**
Controls and properties:
* Transfers execute only based on **authorized instructions** and **policy checks**
* Onchain movements preserve an **immutable transaction history**
***
### Exchange sub-accounts (per Vault)
Where a Vault uses exchanges for execution, hedging, or yield strategies:
* Each Vault has **segregated exchange sub-accounts**
* Positions, margin, financing, and P\&L are attributed at the **Vault level**
* Venue statements are used to reconcile back into Vault accounting
***
### Vault segregation in operations
* Each Vault uses a dedicated MPC wallet set and dedicated exchange sub-accounts
* Software modules maintain Vault-specific ledgers and reporting outputs
* Asset movements occur only within the Vault’s approved pathways (e.g., **MPC ↔ DeFi**, **MPC ↔ exchange sub-account**)
* **Cross-Vault transfers are prohibited** (unless explicitly defined via a controlled, versioned process with disclosures)
***
### Asset movement controls
#### Instruction controls
* Curator initiates strategy actions and transfers within the Vault mandate
* Software enforces policy checks before execution (whitelisted endpoints, limits, timing rules, role permissions)
* 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 the internal Vault ledger
* Reconcile exchange sub-account balances, positions, and P\&L against the 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, exposures, 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 offchain 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 **Evolve** structures user assets and Vault operations to achieve **bankruptcy-remoteness by design**—i.e., to isolate Vault 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 Evolve’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 enforceability
***
### Core building blocks
#### 1) 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 (where relevant)
* Vault assets are tracked and reported **Vault-by-Vault** (positions, NAV, token supply, liabilities)
***
#### 2) Vault-level ring-fencing of liabilities
* Vault liabilities (fees, execution costs, hedging costs, 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)
***
#### 3) Contractual recourse perimeter (who can claim what)
* Strategy counterparties and service providers contract on **Vault-scoped terms**, intended to limit recourse to the relevant Vault assets where applicable
* User terms define:
* payment waterfall
* mint/redeem mechanics
* fee mechanics
* Transfers, execution, and protocol interactions are constrained to:
* **whitelisted endpoints**
* **whitelisted assets**
* **controlled roles and permissions**
***
#### 4) Operational separation from corporate treasury
* Evolve maintains a separate **operating treasury** distinct from Vault assets
* Corporate expenses are funded from operating treasury—not from Vault assets—except for Vault-attributable expenses explicitly disclosed in Vault terms
***
### Diagram — bankruptcy-remote intent
```id="evolve-bankruptcy-remote"
Evolve (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 per Vault
* Vault-level ledgers and reporting outputs
* Prohibition on cross-Vault transfers (unless explicitly defined via a controlled, versioned process)
#### Permissioned asset movement
* Role-based controls across software modules and signing policies
* Maker-checker approvals for sensitive actions
* Immutable onchain audit trails for all wallet movements
#### Reconciliation and attestations
* Reconcile MPC + exchange balances to Vault ledgers and token supply
* Investigate and document exceptions with clear ownership and resolution notes
* Attestations / audits where applicable (and disclosed per product)
#### Versioned Vault terms
* Controlled changes to fees, valuation policy, risk limits, and whitelists
* Clear governance workflow (proposal → review → approval → versioned release)
# Liquidity
Evolve supports DeFi integrations through **two liquidity mechanisms**:
1. a **primary liquidity path** implemented through **native mint and redemption**, and
2. a **secondary liquidity path** implemented through **venue-based trading** (being added in partnership with a trading venue).
This mirrors how liquidity works in traditional markets—**mutual fund primary liquidity** and **ETF secondary liquidity**—while remaining compatible with **product-specific redemption mechanics** and the **bankruptcy-remote segregated vault structure**.
***
### Primary liquidity: Native mint and redemption
**eUSD** is issued and redeemed through Evolve’s native facility.
#### Mint (issuance)
* eUSD is minted when a user deposits the accepted mint asset(s) into the eUSD vault.
* The amount of eUSD minted is determined by the product’s issuance logic and the applicable **NAV reference** at the time of processing (as defined in the product terms).
#### Redeem
* eUSD is redeemed when a user submits a redemption request and eUSD is burned to receive the designated redeem asset (as defined in the product terms).
* Redemption proceeds are determined by the product’s redemption logic and the applicable **NAV reference** at the time of processing.
**Primary mint/redemption is the canonical liquidity path** for eUSD. It anchors eUSD valuation to the product’s NAV methodology and provides a standardized entry/exit route that DeFi integrators can rely on.
***
### Secondary liquidity: Trading venue liquidity (coming soon)
Evolve is adding secondary liquidity for eUSD through **partnerships with a trading venue**.
Secondary liquidity is implemented as **secondary market trading** of eUSD, enabling holders to buy or sell eUSD on a venue **without using mint/redemption** for that transaction.
This is especially relevant when:
* redemptions operate with **cooldowns**, **processing windows**, or **queues**, or
* users prefer **immediate execution** over waiting for the redemption cycle.
Secondary trading can provide an additional liquidity route for users who want faster exits, while the primary route remains the valuation anchor.
***
### How DeFi builders evaluate liquidity
For DeFi integrations (especially **lending markets**), liquidity is typically evaluated based on two properties:
1. **Canonical exit route**\
Primary mint/redemption provides a standardized “base case” path to convert eUSD back into the redeem asset per disclosed rules.
2. **Secondary trading availability**\
Venue-based liquidity provides an optional faster exit route when immediate liquidity is required or preferred.
Evolve’s model supports both properties **without requiring continuous AMM liquidity** to be maintained onchain at all times.
***
### Summary
* **Primary liquidity (mint/redeem)** is the valuation anchor and canonical exit route.
* **Secondary liquidity (venue trading)** provides optional faster execution and alternative exits (coming soon).
* Both are compatible with product-specific redemption mechanics and the underlying **bankruptcy-remote segregated vault structure**.
# Liquidation Services
Evolve runs **Liquidation Services** to make **eUSD** safely usable across DeFi markets—especially for lending and borrowing use cases. When yield-bearing tokens like eUSD are accepted as collateral on protocols such as **Takara Lend** (fork of Compound V2)**, Yei, Morpho**, 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 eUSD can be inefficient. Deep pools often require continuous, expensive liquidity incentives and can still fail under stress—exactly when liquidations matter most.
***
#### Why Evolve provides liquidation execution
Evolve’s approach is to provide **specialized liquidation execution** as an alternative (or complement) to subsidized DEX depth.
Liquidation bots monitor supported lending markets for accounts approaching liquidation thresholds. When a position becomes liquidatable, the liquidation service:
1. **Purchases the collateral (eUSD)** and repays the borrower’s debt
2. Restores solvency in the lending market by closing risky positions
3. **Redeems acquired eUSD via native redemption rails**, converting it back into the designated redeem asset (per eUSD redemption rules)
This makes liquidation more predictable because it ties liquidity to **eUSD redeemability** and **operational SLAs**, rather than relying on volatile DEX pool depth.
***
#### How the liquidation loop stays capital-efficient
Liquidation capacity is actively managed and continuously recycled.
Example (illustrative):
* The liquidation bot executes a **$1M liquidation** on a Morpho market
* It acquires **$1M of eUSD collateral**
* It promptly **redeems eUSD via the primary redemption path**
* Proceeds are recycled to replenish liquidation capital, ensuring the next liquidation can be executed on time
This loop reduces dependence on mercenary liquidity mining and helps keep lending markets healthy.
***
#### Liquidation SLAs and capacity targets
Liquidation services target SLAs designed to support liquidating **up to \~10% of an eUSD vault’s TVL** at any time, **subject to**:
* lending venue constraints (market parameters, liquidation incentives, caps)
* eUSD redemption constraints (queue behavior, windows, liquidity policy)
* operational risk controls (limits, exposure, counterparties)
Capacity is monitored and rebalanced continuously.
***
#### Why this matters
By making liquidations reliable, Evolve enables eUSD to function as a **robust collateral primitive** across SEI DeFi:
* healthier lending markets
* more predictable risk management under stress
* reduced need for expensive, continuous DEX liquidity incentives
* tighter coupling between collateral liquidity and the underlying **bankruptcy-remote segregated vault structure** via native redemption rails
# 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. **eUSD** is designed to be a first-class collateral asset on SEI DeFi, so it exposes an **onchain price feed** that tracks eUSD’s underlying reference value and can be consumed directly by lending protocols or via adapter contracts.
***
#### Pricing methodology
eUSD tracks a **reference value** that reflects the economic value of its underlying sleeves and performance (**net of applicable fees**). As this reference value changes, the oracle updates the price so eUSD’s onchain price follows the same source of truth used for product accounting and reporting.
To strengthen transparency, Evolve uses a **proof-of-reserve / proof-of-backing oriented design** for the oracle infrastructure where feasible:
* When assets or collateral sit **offchain**, independent third parties may verify balances and provide **attestations**.
* This provides additional assurance that underlying collateral supports the token’s reference value (subject to the scope and limitations of the attestation).
For canonical settlement, eUSD can process mint/redemption using a **designated reference price** consistent with the product’s NAV methodology and processing rules, so issuance/redemption aligns with the same accounting reference that integrations rely on.
***
#### Oracle interface (Chainlink-compatible)
eUSD implements a Chainlink-style interface via:
* `latestRoundData()` → returns `(roundId, answer, startedAt, updatedAt, answeredInRound)`
This enables:
* standard oracle plumbing for integrations
* staleness checks using `updatedAt`
* compatibility with common DeFi oracle adapter patterns
***
#### 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" %}
**Important notes & disclaimers**
* The oracle price and related verification procedures are provided **for reference and risk management purposes**.
* eUSD is structured via a **bankruptcy-remote segregated vault structure**; oracle outputs do not, by themselves, create any additional legal entitlement beyond what is defined in the product terms.
* **Redemption amounts are determined by the product’s disclosed reference methodology and processing rules** (including any queue/epoch mechanics) and may differ from the oracle reference in certain scenarios.
* Always review the applicable **legal documents, product terms, and risk disclosures**.
{% endhint %}
# Points Program
**Evolve Points** are earned through onchain activity and community participation across the **eUSD** ecosystem on **SEI**. Points form the foundation for current and future rewards, multipliers, and community benefits.
Evolve Points are distributed across multiple **Seasons**.
***
### Season 1 (LIVE)
Season 1 rewards early participants who actively contribute to the **eUSD ecosystem** through **minting, holding, lending, borrowing, providing liquidity**, and participating in partner protocol activity and campaigns.
* **Duration:** Ongoing
* **Key focus:** Onchain activity + growth campaigns
Season 1 sets the foundation for future reward programs. Points earned in this season may carry forward benefits into later seasons (as defined by future announcements).
***
### How points are earned
Points can be earned through a set of eligible activities:
* **Minting & holding eUSD**
* **Supplying assets to lending markets** (where supported)
* **Using eUSD as collateral** (borrowing against it, where supported)
* **Providing liquidity in eUSD markets** (DEX/venue pools on SEI, where supported)
* **Participating in quests, campaigns, and social/community engagement**
Each activity earns a **base points payout**, with **multipliers** applied where relevant.
You can track eligible activities and your points on the **DeFi Dashboard** (once linked in-app).
***
### 1) DeFi ecosystem participation
Users earn points by minting **eUSD** and deploying it across supported SEI DeFi platforms, including:
* lending markets (supply/borrow/collateral use)
* liquidity pools (eUSD pair markets)
* other whitelisted integrations as they go live
Eligibility is based on onchain activity and supported market addresses.
***
### 2) Campaigns
Evolve periodically runs short-term campaigns where users can complete specific actions to earn **bonus points**.
Follow Telegram and Twitter/X for live campaign announcements.
***
### 3) Community support
Users who actively support the Evolve community through meaningful engagement (e.g., Discord activity, Twitter posts, quest completions) may earn discretionary points, subject to the program rules.
***
### Multipliers
Each eligible activity has an associated multiplier that determines how many points you earn per day.
#### Activity multipliers (Season 1)
| Activity | Multiplier | Description |
| -------------------------------------------- | ---------: | ------------------------------ |
| Hold eUSD | 1.0× | Earn 1 point per $1 per day |
| Supply assets to lending markets | 2.5× | On supported lending markets |
| Use eUSD as collateral (borrow against eUSD) | 2.5× | On supported lending markets |
| Provide liquidity in eUSD markets | 2.0× | On supported eUSD pools/venues |
# Smart Contract Addresses
# Audits
eUSD smart contracts and core infrastructure are **powered by YieldFi**. As a result, users and integrators should refer to **YieldFi’s audit reports** for the underlying contracts and system components that Evolve relies on.
**YieldFi audit reports:**
# Hypernative
Real-Time Web3 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, **Evolve (via YieldFi infrastructure)** uses **Hypernative** as a real-time monitoring and threat-detection system for onchain operations supporting **eUSD**.
***
#### What we monitor
Monitoring is configured 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**\
(unexpected call paths, unusual volumes, rapid repeated interactions, suspicious counterparties)
* **Integration risk signals from dependencies**\
(e.g., oracle anomalies, protocol incidents, liquidity events), where relevant to eUSD operations
* **Operational health indicators**\
related to mint/redeem flows and other critical paths
***
#### Alerting and response workflow
Hypernative alerts are routed to 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 (where supported)
* tightening operational limits
* invoking safeguards defined in the 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 layer** that improves visibility and response during live operations.
# Terms & Conditions
### Issuer, scope, and hierarchy
**Issuer:** Evolve (“Evolve”, the “Issuer”, “we”, “us”, “our”)\
**Contact:** \
**Website:** goevolve.xyz
These general terms and conditions (the **“General Terms”**) apply to all tokens issued by Evolve, including **eUSD**, and must be read together with the token-specific terms for the relevant token/series (the **“Token Terms”**).
If there is any conflict between these General Terms and the Token Terms, the **Token Terms prevail** to the extent of the inconsistency.
### Important notice
Dealing in tokens involves a high degree of risk and may result in a **total loss**. No regulator has authorised or approved these terms or any token terms. You should obtain independent professional advice (legal, tax, financial) before dealing in tokens.
### Nature of eUSD and “Series”
#### Series issuance
Each issuance corresponds to a **Series** (a product sleeve) governed by its Token Terms. Each Series is intended to be **operationally and economically independent** from other Series.
#### What eUSD is
eUSD is a blockchain-based token recorded via smart contracts on supported blockchain networks. It evidences only the tokenholder’s **contractual rights** under the Product Documentation (these General Terms + Token Terms + incorporated policies).
#### Not equity; no governance
Tokens are not equity and do not confer ownership, governance, voting, or profit-participation rights in Evolve.
### Bankruptcy-remote segregated vault structure and Series-limited recourse
Evolve operates a **bankruptcy-remote segregated vault structure** intended to ring-fence assets and liabilities **by Series** using dedicated Series wallets/accounts and operational controls.
Any amounts payable (if any) in respect of eUSD are **Series-limited**, restricted to the **Series Assets** of the relevant Series and applied in accordance with the **Series Waterfall** set out in the Token Terms (or, if not specified, the default waterfall described below).
#### Default Series Waterfall (unless Token Terms specify otherwise)
Series Assets are applied in order:
1. Series costs/expenses properly attributable to the Series (custody/MPC, execution, banking, onchain fees, oracle/data costs, disclosed third-party expenses)
2. Fees specified in Token Terms (management/performance/processing fees, if any)
3. Tokenholder redemptions/payments for that Series
If Series Assets are insufficient, tokenholders bear the shortfall **pro rata within that Series** (unless Token Terms specify otherwise).
### Eligibility, compliance, and sanctions
You represent and warrant that:
* you have legal capacity and authority (and authority to bind an entity, if applicable)
* you are not a sanctioned or restricted person, and you will not use tokens for unlawful purposes
* you will comply with applicable law, including AML/CFT and sanctions requirements
Evolve does not provide investment, legal, tax, or accounting advice.
### Minting and redemption
* Minting occurs upon confirmed receipt of funds (and subject to eligibility checks), in accordance with Token Terms.
* Redemption is processed according to Token Terms (including windows/queues, pricing reference, and fees).
* You are responsible for wallet security; incorrect transfers may be irreversible.
### Valuation, market disruption, and illiquidity
If valuation inputs become unavailable or markets are disrupted, Evolve may postpone valuation or apply documented fallback methodologies consistent with Token Terms and reasonable market practice.
### Smart contract administration, modifications, and upgrades
Smart contracts may include upgrade mechanisms and may be upgraded to address security vulnerabilities, bugs, compatibility issues, and similar operational needs. Any change that materially and adversely impacts tokenholder rights, valuation, fees, redemption mechanics, or risk profile is treated as a **material adverse change** and will be handled via documentation updates and notice, except where immediate action is required for security/compliance reasons.
### Wind-down events and issuer continuity
Token Terms may specify wind-down triggers. Evolve may suspend features, unwind positions, realise Series assets, and apply the Series Waterfall during a wind-down, consistent with Token Terms and applicable law.
### Notices and contact
Notices may be published on the Evolve website/app and/or communicated via email where appropriate.\
For legal/compliance contact: ****
# Risk Disclosures
Dealing in eUSD 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.
### Key risk categories
1. **Bankruptcy-remote segregation and Series-limited recourse risk**\
Recovery is limited to the Series Assets after Series costs/fees; you may receive less than principal or nothing.
2. **No direct ownership of underlying assets**\
Your rights are defined by the Product Documentation for eUSD.
3. **Market, strategy, and performance risk**\
Portfolio performance may be negative; past performance is not indicative of future results.
4. **Valuation and timing differences**\
NAV/valuation may differ from reference prices due to fees, operational timing, disruption, illiquidity, execution costs, and settlement constraints.
5. **Liquidity and transferability risk**\
Secondary markets may not exist; eUSD may be illiquid and/or subject to restrictions.
6. **Redemption and settlement risk**\
Redemptions may be delayed by queues/SLAs, compliance checks, disruptions, illiquidity, and operational constraints.
7. **Third-party and counterparty risk**\
Dependence on custodians/MPC providers, exchanges, banks, protocols, oracle providers, and other vendors.
8. **Smart contract and cybersecurity risk**\
Bugs/exploits, governance attacks, key compromise, oracle failures, etc.
9. **Blockchain/network risk**\
Congestion, forks, re-orgs, validator issues, and other network risks.
10. **Regulatory and enforcement risk**\
Laws and interpretations may change; Evolve may restrict jurisdictions or suspend features.
11. **Tax risk**\
Tax treatment may be uncertain; you are responsible for compliance.
12. **Operational and key-person risk**\
Execution, staffing, vendor, and business continuity risks.
# Segregation & Bankruptcy-Remote Structure Disclosure
This schedule forms part of the Product Documentation. It describes Evolve’s intended segregation framework for the **eUSD Series** and how Series assets and liabilities are attributed and ring-fenced.
### Purpose and scope
* describes designated Series wallets/accounts and how Series assets/liabilities are attributed
* describes the Series Waterfall and limits of recourse
* token-specific mechanics (valuation, fees, redemption windows, eligible assets) are set out in the eUSD Token Terms
### Ring-fencing model
* eUSD is intended to operate as an independent, ring-fenced product sleeve
* no intentional cross-collateralisation with other Series
* segregation from Evolve operating assets
### Series wallets/accounts architecture
Evolve designates one or more Series wallets/accounts for eUSD, typically:
* deposit address(es)
* collateral/holding wallet(s)
* execution/deployment wallet(s) (if applicable)
* redemption/payout wallet(s)
Tokenholders must route funds only to designated Series wallets/accounts.
### Attribution of Series assets and liabilities
* Series Assets include subscriptions, deployed positions, proceeds, recoveries, and Series-attributable rights/receivables (and incentives if specified)
* Series Liabilities include redemption obligations, Series costs/expenses, Series fees, and other liabilities expressly allocated under Product Documentation
### Technical execution exceptions
In limited cases, technical routing/batching may require transient movements that do not reflect economic commingling; Evolve maintains traceable books and restores allocations promptly.
# Token Terms
### Key commercial parameters
* **Token name / symbol:** eUSD
* **Chain:** SEI
* **Mint asset(s):** USDC
* **Redeem asset:** USDC
* **NAV methodology & frequency:** Daily
* **Fees:** 1% management fee (no performance fees)
* **Redemption SLA & queue rules:** T+2 days
* **Eligibility / Greenlisting:** permissionless
* **Liquidity policy:** T+2 days
# Investment Disclaimer
Materials are provided for informational purposes only and do not constitute an offer, solicitation, invitation, or recommendation to acquire eUSD where unlawful. Any issuance is made solely on the basis of the formal legal documentation (General Terms + eUSD Token Terms + related schedules).
No regulator endorsement: any regulatory interaction should not be interpreted as endorsement of Evolve, eUSD, or any offering.
Jurisdictional restrictions and eligibility limitations apply as described in the Eligibility Criteria and Verifications & Screenings policies.
Contact: ****
# Privacy Policy
**Last updated:** Feb 21, 2026\
**Controller:** **Evolve** (“Evolve”, “we”, “us”, “our”)\
**Contact:** ****
This Privacy Policy explains how Evolve collects, uses, discloses, and protects personal data when you access Evolve’s websites, applications, dashboards, APIs, and related services (the **“Services”**) in connection with **eUSD**.
Evolve’s smart contracts and vault infrastructure are **powered by YieldFi** (the infrastructure provider). YieldFi may process certain technical and operational data on Evolve’s behalf as a **service provider/subprocessor** to deliver the Services.
> This policy is provided for transparency and does not constitute legal advice.
***
### 1) Scope
This policy applies to:
* Visitors to Evolve websites and apps
* Users who connect wallets, mint, redeem, or otherwise interact with eUSD
* Users who undergo eligibility checks, KYC/KYB, or AML screenings (where applicable)
* Partners/integrators using Evolve’s integration surfaces (where applicable)
It does not apply to third-party websites, wallets, exchanges, DeFi protocols, or blockchains you use to interact with eUSD, each of which has its own policies.
***
### 2) What we collect
#### A) Data you provide
* **Contact details** (e.g., email if you contact support)
* **Account/profile data** (if we provide an optional account layer)
* **Support communications** (messages, attachments, and metadata)
#### B) Identity and verification data (if KYC/KYB is required)
Where access is gated (Greenlist), we may collect or receive:
* **Identity information** (name, date of birth, nationality)
* **Government ID and verification artifacts** (ID images, selfie/liveness checks)
* **Entity/KYB information** (company registration, beneficial ownership, proof of address, director/officer details)
* **Screening results** (sanctions/PEP/adverse media flags, risk scores)
#### C) Wallet and blockchain data
* **Wallet addresses** you connect
* **Transaction hashes** and onchain activity linked to your wallet (public blockchain data)
* **Balances and positions** as displayed in the app (derived from onchain data and product accounting)
#### D) Technical and usage data
* **IP address** (and approximate geolocation derived from IP)
* **Device and browser information** (user-agent, OS version, identifiers)
* **Log data** (access logs, error logs, timestamps, pages/actions)
* **Security telemetry** (signals used to detect fraud, abuse, or exploitation patterns)
#### E) Cookie and similar tracking data
We may use cookies or similar technologies for:
* essential site functionality
* security
* analytics and performance
(You can manage cookies via browser settings; some controls may limit functionality.)
***
### 3) How we use data
We use personal data to:
#### Provide and operate the Services
* enable wallet connections and user workflows (mint/redeem requests, dashboards)
* deliver product pages, disclosures, and reporting views
* administer eligibility gating where applicable
#### Compliance, safety, and risk management
* enforce eligibility restrictions and restricted jurisdiction access blocks
* perform KYC/KYB/AML checks where required
* run wallet screening and detect illicit or sanctioned activity
* investigate incidents, fraud, abuse, and security events
#### Improve and maintain the Services
* debugging, monitoring, performance analytics
* feature development and reliability
#### Communications
* respond to support inquiries
* send critical operational notices (e.g., policy changes, security incidents)
***
### 4) Legal bases (high-level)
Depending on jurisdiction, our processing may rely on one or more of:
* **performance of a contract** (to provide Services you request)
* **legal obligations** (AML/CFT, sanctions compliance)
* **legitimate interests** (security, fraud prevention, product improvement)
* **consent** (where required, e.g., certain cookies/marketing)
***
### 5) How we share data
We may share data with:
#### A) Infrastructure provider (YieldFi)
Evolve uses YieldFi as the smart contract and vault infrastructure provider. YieldFi may process limited technical and operational data (e.g., logs, workflow events, security telemetry) **as a service provider/subprocessor** to help operate the Services.
#### B) Verification and screening providers
Where KYC/KYB or wallet screening is required, we share necessary data with vendors to:
* verify identity/entity information
* conduct sanctions/PEP screening and risk checks
#### C) Analytics, hosting, and security providers
We may use service providers for:
* hosting and content delivery
* application monitoring and security alerting
* analytics and performance monitoring
#### D) Legal and regulatory disclosures
We may disclose data if required to comply with law, respond to lawful requests, enforce our terms, or protect rights, safety, and integrity of the Services.
#### E) Business transfers
If Evolve undergoes a merger, acquisition, restructuring, or asset sale, data may be transferred as part of that transaction, subject to applicable law and confidentiality protections.
We do **not** sell your personal data to advertisers.
***
### 6) International transfers
Your data may be processed in multiple jurisdictions depending on where Evolve and its service providers operate. Where required, we use appropriate safeguards (e.g., contractual protections) for cross-border transfers.
***
### 7) Retention
We retain data only as long as necessary for:
* providing the Services
* compliance obligations (including AML/sanctions screening records where applicable)
* security, auditability, and dispute resolution
Retention periods vary by data category and legal requirements. You may request deletion where applicable, subject to legal and operational constraints.
***
### 8) Security
We implement administrative, technical, and organizational measures designed to protect personal data. However, no system can be guaranteed 100% secure. You are responsible for maintaining the security of your wallet(s), keys, and devices.
***
### 9) Your rights
Depending on your jurisdiction, you may have rights to:
* access, correct, or delete personal data
* object to or restrict processing
* request portability (where applicable)
* withdraw consent (where processing relies on consent)
To exercise rights, contact ****. We may request verification of identity to protect users from unauthorized requests.
***
### 10) Children
The Services are not intended for children. Do not use the Services if you are not of legal age in your jurisdiction.
***
### 11) Changes to this policy
We may update this policy from time to time. We will post the updated version and update the “Last updated” date. Material changes may be communicated via the app or other reasonable channels.
***
### 12) Contact
For privacy questions, requests, or complaints: ****
# Eligibility Criteria
**eUSD and related Services are intended only for eligible users.** You are solely responsible for confirming that you are permitted to access and use the Services under applicable law.
### 1) Restricted jurisdictions (non-exhaustive)
Evolve does not offer eUSD to:
* **U.S. Persons** and persons located in or ordinarily resident in the **United States**
* persons located in or ordinarily resident in certain other restricted jurisdictions, including (but not limited to):
* **United Kingdom**
* **China**
* jurisdictions subject to international sanctions
Evolve may update restricted jurisdictions at any time to reflect compliance requirements.
### 2) Sanctions / restricted persons
You must not use the Services if you (or, where applicable, your beneficial owners, directors, officers, authorised persons, or wallet addresses) are subject to sanctions or other restrictions under applicable law.
### 3) Source of funds and lawful use
By using the Services, you confirm your funds are derived from legitimate sources and are not linked to unlawful activity, and you will not use eUSD for unlawful purposes.
### 4) Competence and risk awareness
You should only participate if you:
* understand blockchain and non-custodial wallet risks
* can evaluate technical, legal, and financial risks
* can bear a complete loss of capital
### 5) Acknowledgement
By dealing in eUSD, you confirm that you:
* meet the eligibility criteria above
* understand the risks involved
* accept responsibility for your participation
If you do not meet these criteria, you must not interact with eUSD or associated systems.
# Verifications and Screenings
Evolve implements a layered set of technical, compliance, and operational controls to help enforce eligibility restrictions and mitigate misuse. These controls support compliance and risk management, but they do not guarantee prohibited users will never attempt access and they do not eliminate all risks.
### 1) In-app screening processes
#### A) IP and geolocation screening
When you visit the Evolve website or application, your IP address may be analysed to estimate geographic location. If an IP is identified as originating from a restricted jurisdiction, access to the website or certain functionality may be blocked. This may include measures designed to detect or restrict access via VPNs, proxy services, or anonymisation tools where inconsistent with compliance requirements.
#### B) Wallet screening
When you connect a wallet, Evolve may screen the wallet using third-party tools to identify wallets associated with:
* sanctioned entities
* known illicit activity
* high-risk blockchain exposure
* other compliance red flags
If a connected wallet is flagged, Evolve may disconnect the wallet, block access, restrict mint/redeem, or require enhanced verification.
### 2) KYC/KYB and AML checks (where applicable)
Certain features (especially mint/redeem) may require identity verification or business verification (KYC/KYB), including AML screening, to satisfy compliance requirements. If required, you must complete verification before accessing restricted flows.
### 3) Ongoing monitoring and rescreening
Evolve may:
* rescreen wallets or users periodically
* request updated information
* apply enhanced due diligence for elevated risk signals
* restrict or suspend access based on compliance outcomes
### 4) Limitations
Screening tools and data sources can be incomplete, delayed, or inaccurate. A “pass” result is not a guarantee that a user is low-risk or compliant, and a “flag” may require manual review. These controls reduce risk but do not eliminate it.
### 5) Actions we may take
Based on screening/verification outcomes, Evolve may:
* block access from restricted jurisdictions
* restrict mint/redeem functionality
* place accounts/wallets into a review state
* request additional information
* report activity where required by law
* terminate access consistent with the Terms & Conditions