# Introduction **Welcome to the Enzyme Documentation — your starting point for building the future of finance.**\ Enzyme delivers the global infrastructure for tokenized finance, enabling enterprises and institutions to create, scale, and manage next-generation decentralized finance ventures. In Enzyme Documentation, you will find everything you need — from user guides to developer tools — across our entire product suite. ### Quick Start
Cover image
Enzyme.OnyxThe tech stack to issue and administer tokenized funds and instruments

:bolt:

/files/doLN55ydLJv3cEnAtOTa/spaces/Ea9gKZgFC4ELwy5PKFQp
Enzyme.BlueThe end-to-end platform for decentralized strategy management

:leaf:

/files/I3o4mIfzDrRVk84HOSjt/spaces/vWVuPN2BVJDLluN0NzQs
Enzyme.MysoThe premier protocol for creating and trading on-chain options

:globe-pointer:

/files/XX6JfmgV96iEY3HIL8N4https://enzyme.finance/products/myso
*** ## Launch App
Cover image
Enzyme Onyxhttps://manager.onyx.enzyme.finance/login
Enzyme Bluehttps://app.enzyme.finance/discover
Enzyme Myso/pages/LThc2RqOxBKU56Qt3TMy
# Our Products As the pioneer of the Vault industry, Enzyme draws on years of experience forged alongside industry leaders. Our infrastructure empowers businesses and institutions with a comprehensive suite of products to create and manage next-generation financial products and strategies.
Enzyme OnyxIssue, structure and administer tokenized products
Enzyme BlueCurate and manage decentralized strategies
Enzyme MysoCreate and trade on-chain options
# Enzyme Vault Enzyme Vaults, underpinned by Enzyme's proprietary protocol, provide superior versatility and resilience, all within a tokenized architecture designed to help businesses embrace the decentralized future.
Enzyme Vaults are smart contracts that can be tailored to the owner's objectives and specific requirements. The structure enables any number of participants, from one to an unlimited amount, to deposit funds in exchange for shares. These shares are issued as ERC-20 tokens, with transferability and lock conditions configurable by the Vault owner.\ \ Learn more about Enzyme Vaults [HERE](https://enzyme.finance/enzyme-vault). # Myso Options Options are derivatives that provide the right, but not the obligation, to buy or sell an asset at a predetermined strike price on or before a set expiry date. **Myso Options** can be structured in two fully collateralized formats: * **Covered Calls** — the seller holds the underlying asset and earns a premium by giving up upside beyond the strike price. * **Cash-Secured Puts** — the seller posts cash collateral and earns a premium while committing to buy the asset at the strike price if exercised.
Myso Options enable: * **Wide Token Support**\ From blue-chips to alt-coins, options can be written on a broad ERC-20 asset universe with customizable strike prices and expiries. * **On-Chain Settlement**\ Settlement occurs directly on-chain, ensuring transparency, security, and removal of counterparty risk. * **Deep Liquidity**\ A neutral venue structure enables cross-firm liquidity, giving market participants competitive pricing without the need to onboard multiple trading desks. Learn more about ***Covered Calls*** and ***Cash-Secured Puts*** [HERE](https://enzyme.finance/myso-options). # Use Cases Enzyme empowers industry leaders across sectors to achieve immediate goals and long-term growth
Tokenized Funds Create natively tokenized funds for efficient and innovative digital asset management. The tokenized nature of Enzyme Vaults enables you to create investment funds that are tokenized by design, or to add as a tokenization layer to existing centralized investment vehicles.
Financial Instruments Enzyme enables financial institutions and businesses to issue and distribute fully on-chain financial instruments ranging from exchange-traded product to advanced debt and structured products.
Tokenized Pools Seamlessly attract and consolidate liquidity through incentivized and fully decentralized vehicles.
Real World Assets Real-World Assets (RWAs) represent one of the most promising frontiers for value creation in digital finance—but tokenization alone is not enough. Enzyme provides the execution layer that unlocks utility, composability, and on-chain programmability, enabling RWAs to operate seamlessly within decentralized financial ecosystems.
# Who are we Founded in 2017 by Mona El Isa, Enzyme was built with a mission to level the investment playing field and drive the democratization of decentralized finance through cutting-edge infrastructure, originally designed exclusively for asset managers. After eight years of pioneering the space with the leading asset management protocol, Enzyme evolved into a Global Infrastructure for Tokenized Finance — empowering any businesses and institutions to scale through tokenization, introducing new products and services to provide them with all the tools they need to achieve their objectives. At Enzyme, we are deeply committed to the ethos of decentralization, embedding it not only in the design of our products but also in the way we approach development. We believe the future of finance is unfolding before us—a great movement of convergence that will ultimately lead to the emergence of ONE finance: a system that grants users greater fairness, transparency, and control. We embrace this era of transformation, empowering visionaries and builders to bring their boldest ideas to life, shaping a more decentralized and equitable future for all. # Governance Enzyme is one of the oldest protocols on mainnet, with a track record of over six years. Originally developed for replicating fund management practices on chain whilst removing intermediaries, the protocol has evolved considerably and can now be described as a protocol providing digital asset management infrastructure for builders and managers. We have a variety of users, ranging from liquid staking protocols accelerating their projects through our vault structures to capture deposits, fund managers building regulated services on our infrastructure and blockchain banks building products for their customers with enzyme at their core. Enzyme’s use cases are continually evolving and our governance structure reflects this evolution where we have a framework of two committees tasked with building and maintaining enzyme. Our strategy & operations committee focuses on direction as the market evolves and our technical committee ensures that the protocol remains robust and secure through specific technical expertise and audits. # Tokenomics **MLN as a utility token for Enzyme Blue** MLN is a utility token which gives you access to the protocol. Users pay fees in MLN to access the platform. The number of MLN you need to access the network is equivalent to 25 basis points of the AUM linked to your usage of the protocol. Once collected, these tokens are automatically burned. If users fail to pay fees in MLN, they will get penalised for this because the protocol will dilute their vault shares by 50bps. The MLN collected by the protocol is highly unlikely to offer any value to the MLN token in the short term given that inflation is likely to exceed the amount burnt for many years to come (see next section). **MLN to fund protocol development & growth** Each year, up to 300,600 new MLN tokens can be minted by the minter contract. This MLN is to be used for current and future protocol development and growth. The Enzyme Council DAO can review grant applications and allocate those funds to projects, developers, maintainers and auditors who they believe can add value to the Enzyme ecosystem. Any MLN tokens not spent at the end of each year, are typically burnt. **Future planned MLN Utility** It has been planned for a while to evolve and add more utility to the MLN token. The details of this will be confirmed in the future and may involve things like locking up and staking an amount of MLN to make a governance proposal. # What is Enzyme Onyx? ## Overview Enzyme.Onyx is **a modular** and **self-custodial** Vault Layer for boundless digital asset management. Built for the innovators of modern markets, Enzyme.Onyx gives enterprises the freedom to create and manage fully tokenized strategies — **across any asset class**, **network**, **and financial systems.**
Enzyme Vault/pages/A9KTyXpqKG1LZVUS2u3I
Administration App/pages/aOjs4gC5WzIpifbjuGsn
Investor Interface/pages/4rzBe5k6uNHjO6v0ClJt
# Architecture
To enable flexible strategy deployment, Enzyme.Onyx uses an Enzyme Vault as the tokenization layer, with strategies deployable through any wallet type, including EOAs (MetaMask, Phantom...), MPCs (Fireblocks...), Smart Accounts (Safe...), and Cold Wallets (Ledger...). ### Enzyme Vaults - Subscription and Accounting The Enzyme Vault acts as the tokenization layer, providing a natively tokenized structure that supports deposits and redemptions, issues Vault Shares (ERC20), and consolidates fees. At the Vault level, the value of the underlying strategy is consolidated, ensuring accurate NAV computation and per-share valuation. {% hint style="info" %} Learn more about Enzyme Vaults [HERE](https://enzyme-finance.gitbook.io/onyx/enzyme-vault/overview). {% endhint %} ### Wallets - Custody and Management While the Enzyme Vault collects funds and provides the tokenized structure, custody and execution of the underlying strategy are handled by Wallets (***Management Wallet***). Vault owners can leverage their preferred custody stack to deploy any strategy of their choice, without any kind of boundaries. {% hint style="info" %} Lean more about Wallets [HERE](https://enzyme-finance.gitbook.io/onyx/getting-started/publish-your-docs). {% endhint %} *** ## What Onyx isn't? Onyx is not a micro-management tool. It provides the tokenization layer that can be deployed on top of any wallet, enabling the tokenization of any type of strategy. Onyx does not monitor, track, or restrict how the tokenized value or assets are managed. # Use Cases ## Boundless by design Enzyme.Onyx architecture provides businesses and institutions with a seamless solutions to deploy any type of tokenized strategies. The nature of the tokenized products depends on the underlying strategy, this notably includes but is not limited to: * **Tokenized Funds**, whether native or ad hoc * **Tokenized Financial Instruments** such as structured products, collateralized debt products, term deposits and more * **Tokenized Pools** such as TVL Pools, Staking Pools, VC Pools and more ## Unlimited Systems, Protocols and Assets **Systems :** Cross-chain and cross-system (decentralized and centralized) **Protocols** * Any DeFi protocols (Aave, Uniswap, Fluid, GMX...) * CeFi platforms (Coinbase, Kraken...) * Any centralized platforms (brokers, marketplaces...) .... **Assets :** Supports crypto, RWAs, and even non-financial assets {% hint style="info" %} Onyx can tokenize any asset, provided its value can be calculated and reported. Learn more about Accounting [HERE](https://enzyme-finance.gitbook.io/onyx/enzyme-vault/accounting). {% endhint %} ## Underlying strategies Enzyme.Onyx, as a vault layer, makes it possible to tokenize on- and off-chain value, broadening strategies and use cases infinitely.
Fully DecentralizedHarness everything decentralized finance has to offer
CentralizedTokenize ANY real-world-asset
HybridSeamlessly combine decentralized and traditional assets.
# Deployment Access to Onyx will be gated during its first months of rollout, then opened to broader users. {% stepper %} {% step %} ### Provide your requirements Ownership, control parameters, fee model, default management wallet address... {% endstep %} {% step %} ### Enzyme deploys the Vault We handle the deployment and deliver a secure, tokenized structure tailored to your needs. **100% self-custodial.** {% endstep %} {% step %} ### Access the Administration App Use our app to manage collections, process deposits and redemptions, report NAV... {% endstep %} {% step %} ### Execute your strategy Run your strategy through your preferred wallet and custody stack. {% endstep %} {% step %} ### Get a custom front-end Enzyme delivers a dedicated interface for your Vault, tailored to your investors and users. (White-label to be integrated soon) {% endstep %} {% endstepper %} # Wallets {% hint style="info" %} The ***Owner Wallet*** and ***Management Wallet*** are to be distinguished.
* ***Owner Wallet***: The custody stack used to access the Administration App. It serves as the gateway and identity check for Vault ownership. * ***Management Wallet***: The custody stack responsible for collecting funds and executing the strategy. \ *The Owner Wallet and Management Wallet may be the same, but they can also be separated, discretion of the Vault Owner.* {% endhint %} ## Compatibility Vault Owners are free to choose any wallet type for the ***Owner Wallet*** and the ***Management Wallet***. This includes, but is not limited to: * Externally Owned Accounts (EOAs) * Multi-Party Computation (MPC) wallets * Smart Accounts * Cold Wallets ## Sub-wallets ***Managers*** are free to use multiple ***Management Wallets*** to structure and execute their strategies.
## Delegation and role-based access The tokenized structure can be organized with role-based access: * At the macro level, using the Enzyme Vault parameters * At the micro level, leveraging the custody stack capabilities {% hint style="info" %} For instance, users leveraging Safe as their Management Wallet can leverage Zodiac for role-based management and access. {% endhint %} ## Management Wallet independance {% hint style="danger" %} ***Management Wallets*** **are not directly connected or integrated with the Vault**. Vault Owners and Admins can withdraw funds from the Vault smart contract and transfer them to one or several wallets of their choice. {% endhint %} # Primitives ## Vault * **Enzyme Vault** *:* Enzyme Vaults are smart contracts that provide a natively tokenized framework for building next-generation financial instruments and strategies. They form the core building block of Enzyme.Onyx. * **Subscription** : A request submitted by an investor to either deposit assets into the Vault or redeem Vault Shares. * **Deposit** : The transfer of assets into the Enzyme Vault resulting in issuance of Vault Shares. * **Redemption** : The process of returning Vault Shares in exchange for underlying assets from the Enzyme Vault. * **Holdings Valuation** – The assessment of all assets and positions backing the Vault strategy that must be reported into the Administration App to calculate the Enzyme Vault's Net Asset Value (hereafter "NAV"). ## Roles * **Vault Owner** – The primary controller of the Vault with ultimate authority over its configuration and governance. * **Vault Admin** – A delegated role that can manage specific operational tasks such as accounting or subscription processing. * **Manager** – The role responsible for executing the investment strategy through the Management Wallet. The Manager can be the Vault Owner, Admin or a third-party. ## Wallets * **Owner Wallet**: The custody stack used to access the Administration App. It serves as the gateway and identity check for Vault ownership. * **Admin Wallet:** The custody stack of Admins that the Owner has whitelisted beforehand. * **Management Wallet**: The custody stack responsible for collecting funds and executing the strategy. ## Assets * **Deposit Asset** : The denomination asset accepted by the Vault for deposits. * **Redemption Asset** : The asset in which investors receive payouts when redeeming Vault Shares. * **Fee Asset** : The asset used to calculate and settle management, performance, or other fees within the Vault. ## Tools * **Administration App** : The application provided by Enzyme used by Vault Owners and Admins to oversee operations such as ***Holdings Valuation***, subscription management, fee handling, and fund transfers. * **Investor Interface** : The custom front-end through which investors interact with a Vault to subscribe (deposit/redeem), monitor performance, and access key information. # Overview Enzyme Vaults, underpinned by Enzyme's proprietary protocol, provide superior versatility and resilience, all within a tokenized architecture designed to help businesses embrace the decentralized future. ## Smart Contract Enzyme Vaults are smart contracts that can be tailored to the owner's objectives and specific requirements. The structure enables any number of participants, from one to an unlimited amount, to deposit funds in exchange for Vault Shares. ## Self-Custodial Enzyme Vaults are fully self-custodial smart contracts. Enzyme provides the infrastructure to deploy the Vault but has no control over the funds and the strategy beeing executed. {% hint style="warning" %} Enzyme may require Vault upgrades to align with improvements to the underlying protocol. These upgrades are designed to enhance security and functionality, while ensuring continuity for Vault Owners and investors. {% endhint %} ## Vault Shares The Vault Shares are issued **as ERC-20 tokens**, with transferability and parameters configurable by the Vault owner, enabling businesses and institutions to deliver embedded yield tokens.\ \ Vault shares are issued under **a custom ticker** set by the Vault Owner. # Ownership Vault ownership is secured through the ***Owner Wallet***, which can take any form—including multi-signature custody solutions. It may be the same as the ***Management Wallet*** or a separate one. {% hint style="info" %} Learn more about Wallets [HERE](https://enzyme-finance.gitbook.io/onyx/getting-started/publish-your-docs). {% endhint %} # Networks An ***Enzyme Vault*** can be deployed on any EVM-compatible chain, but each Vault exists on a single chain. {% hint style="info" %} **About Networks** \ While strategies can be executed across any chains and systems through the ***Management Wallets***, the Vault Network defines on which chain deposits and redemptions take place. Funds deposited into the Vault smart contract can be transferred to the ***Management Wallet*** on that chain. **From there, it is up to the manager to handle bridging or off-ramping should they need to move assets outside the network.**\ \ Learn more about Funds Transfer [HERE](https://enzyme-finance.gitbook.io/onyx/enzyme-vault/subscription/funds-transfer). {% endhint %} # Value Asset Vault Owners determine the Value asset used as reference to calculate NAV and Vault Share Price. # Accounting Because Enzyme.Onyx enables any type of strategy across unlimited systems, and to preserve the integrity of its tokenized structure, **Vaults deployed with Onyx operate under a non-continuous accounting model.** {% hint style="info" %} A **non-continuous accounting model** means the Vault’s NAV isn’t updated in real time through live price feeds, but only at specific checkpoints defined by the manager or strategy. {% endhint %} ## Holdings Valuation Vault Owners or Admins must regularly value the holdings and positions in their Management Wallet, with the frequency determined at their discretion. \ \ Once the valuation is reported, Enzyme.Onyx calculates the NAV by incorporating other items such as ***Capitalised Expenses***, ***Deferred Income***, and fees, and updates the Vault Share Price accordingly. # Valuation Reporting - NAV With Enzyme Onyx, the Net Asset Value calculation is not in real-time. By default it follows an asynchronous model. Vault Owners or Admins are required to consolidate the value of the underlying portfolio and to report it directly into the Onyx ***Administration App.***
### NAV Formula The ***Vault Owner*** or ***Admin*** is required to report the [Portfolio Value](/onyx-user-documentation/administration-app/vault/markdown/updating-the-nav)***,*** the protocol then computes it with [Expenses and Incomes](/onyx-user-documentation/administration-app/vault/markdown/reporting-expenses-and-income), the [Liquidity Buffer](/onyx-user-documentation/enzyme-vault/accounting/liquidity-buffer), as well as any accrued [Fees](/onyx-user-documentation/enzyme-vault/fees) that wouldn't have been distributed yet. {% hint style="success" %} **Net Asset Value = Portfolio Value + Liquidity Buffer + Capitalised Expenses - Deferred Income - Accrued Fees** \ ***Note:** Onyx automatically accrues fees when a NAV update is performed (for management and performance fees), and upon processing deposits or redemptions (for entry and exit fees). However, this does not imply that the corresponding liquidity is already held within the vault smart contract.* *Accrued fees may remain deployed within the management environment and continue to be invested. Onyx simply tracks the value of these fees through the App. It is the responsibility of the Manager to transfer the corresponding liquidity back to the vault when distribution is required. Learn more about Fees* [*HERE*](/onyx-user-documentation/enzyme-vault/fees)*.* *These accrued fees must nevertheless be accounted for and deducted to ensure accurate accounting and Net Asset Value (NAV) calculation.* ***NAV is calculated by taking into account accrued fees that have not yet been distributed.*** {% endhint %} ### NAV Reporting The **Portfolio Value** reporting is executed as an on-chain transaction, requiring both approval and gas fee payment from the ***Owner Wallet.*** With Enzyme.Onyx, the valuation method is left open—Vault Owners and Managers can handle it internally, work with their preferred provider, or ask Enzyme for partner recommendations.
### NAV Automation While the NAV requires a manual input by default, Enzyme can help develop a custom flow to automate the NAV reporting. More info [HERE](/onyx-user-documentation/enzyme-vault/accounting/nav-automation). {% hint style="success" %} To learn more about Valuation Reporting, visit Accounting Management. {% endhint %} # Portfolio Value ## What is the Portfolio Value? The Portfolio Value, represents the total value of all investments you made. It is a core input used by Onyx to calculate the Net Asset Value (NAV). {% hint style="warning" %} As you are looking at [updating your NAV](/onyx-user-documentation/administration-app/vault/markdown/updating-the-nav), you should only be looking at reporting the value of your investments. As such, the Portfolio Value is not supposed to include:\ \- Any accrued fees (Onyx accrues this for you and takes it into account for the NAV Calculation)\ \- Any liquidity held in the Vault smart contract that hasn't been allocated yet - the [Liquidity Buffer](/onyx-user-documentation/enzyme-vault/accounting/liquidity-buffer)\ \- Any accounting positions which are to be recorded separately - see [Expenses and Income](/onyx-user-documentation/enzyme-vault/accounting/expenses-and-income) {% endhint %} # Liquidity Buffer The Liquidity Buffer refers to any liquidity that has remained in the Vault smart contract and that hasn't been allocated yet. {% hint style="info" %} Some managers keep a Liquidity Buffer as a redemption reserve or to distribute the fees without unwinding positions.\ \ Sometimes the formation of this Liquidity Buffer simply results from processed deposits that haven't been invested. {% endhint %} # Expenses and Income Vault Owners and Admins can track capitalised expenses and deferred income. ## Capitalised Expenses Capitalised expenses let you record and amortize significant operating costs over a defined period, ensuring accurate accounting within the Vault’s valuation. {% hint style="success" %} *Example*
* *The Vault has operating expenses of **10k USD** for audit costs per year.* * *This expense can be added as a **capitalised expense item** with a write-down period (e.g., Jan 1 until Dec 31, 2025).* * *Whenever (partial) payments of an expense item are made, the **paid amount** needs to be tracked.* * *The Vault’s valuation module will automatically calculate the correct accounting value of all expense items whenever a valuation update is made, taking into account both the **pro rata write-down** of the capitalised expense and the **payments already made**.* {% endhint %} ## Deferred Income Deferred income lets you spread guaranteed revenue over a defined period, ensuring it is recognized gradually in the Vault’s valuation. {% hint style="success" %} *Example* * *The vault has guaranteed income of **USD 10k** for the year.* * *This income can be added as a **deferred income item** with a write-up period (e.g., Jan 1 to Dec 31, 2025).* * *Whenever (partial) payments of the income item are received, the **amount received** must be tracked.* * *The vault’s valuation module will automatically calculate the correct accounting value of all income items whenever a valuation update is made, taking into account both the **pro rata write-up** of the deferred income and the payments already received.* {% endhint %} # NAV Automation We’ve introduced Automated NAV (Net Asset Value) Updates to bring institutional-grade reporting and operational automation to onchain asset management. This feature is: * Designed and implemented by Enzyme * Automated via Chainlink CRE (Chainlink Runtime Environment) * Powered by independent third-party data providers The default update frequency is every 24 hours, covering most fund and treasury use cases. Higher frequencies can be configured where required. ### How It Works Chainlink CRE acts as the automation layer, executing these workflows on a scheduled basis. Enzyme leverages Chainlink’s SDK to build and maintain the deterministic NAV workflows — defining asset inclusion, valuation logic, reconciliation rules, and publication standards. For portfolio data and activity reporting, we rely on third-party providers such as: * Octav.fi * 1Token These providers may supply reporting across: * DeFi positions * CeFi balances * Custodial accounts * Derivatives exposure * Assets in transit on bridges (e.g. CCIP, LayerZero) * Offchain APIs and external systems (e.g. Interactive Brokers) This enables hybrid DeFi + CeFi funds and institution-ready structures. ### Data Responsibility & Scope Enzyme is responsible for: * Designing the NAV calculation logic * Implementing and maintaining the automation workflows * Ensuring deterministic execution via Chainlink CRE Enzyme is not responsible for the accuracy, completeness, or reliability of data supplied by third-party aggregators, custodians, exchanges, or API providers. Data integrity, availability, and correctness remain the responsibility of the selected external data provider. ### Optional Risk & Protection Modules Depending on the chosen provider and configuration, additional safeguards may include: * NAV anomaly and spike detection * Automated alerts * Risk monitoring modules * Insurance against NAV update failures Availability and scope depend on provider selection and workflow setup. ### The process \ The automation process follows 2 main steps: 1. Plug Onyx to an accounting provider to consolidate the Gross Asset Value 1. [With Octav](/onyx-user-documentation/enzyme-vault/accounting/nav-automation/automation-with-octav) 2. [Set up Chainlink Runtime Environment](/onyx-user-documentation/enzyme-vault/accounting/nav-automation/setting-up-cre) to automate the reporting # Automation with Octav This document explains how to prepare your vault and complete the required steps to enable automated NAV updates using Enzyme and Chainlink. *** ### 1. Before Setting up Please review the following carefully before proceeding. #### 1.1 Asset Requirements * The **deposit, redeem, and fee assets** of your vault must have a **reliable and stable asset rate**. * These assets should be pegged to a constant value (for example, USDC pegged to 1 USD). * If any of these assets do not meet this requirement, the automation may produce incorrect results. *** #### 1.2 Chainlink API Usage & Costs * Please ensure your Octav API plan has sufficient credits. *** #### 1.3 Vault Activity Restrictions During Execution * When the automation runs, **no manual actions should be performed on the vault**. * This includes: * Moving or transferring assets * Bridging assets * Executing deposits or redemptions * Claiming fees * Performing any of these actions during execution may result in an **incorrect NAV calculation**. * We strongly recommend scheduling **at least 30 minutes of inactivity** around the automation execution time. *** #### 1.4 Octav Subscription Requirement * All addresses tracked in your portfolio **must have an active Octav Lite subscription**. * Without this, the automation may fail or return incomplete data. *** ### 2. Information You Must Provide to Enzyme Before we begin setup, please send us the following details: * Network (e.g., Ethereum, Polygon, etc.) * Vault address (Shares contract) * Public bundle portfolio URL (check on FAQ section how to do it) * Desired automation schedule * Example: once per day at 01:00 UTC * Your Octav API key (share with Enzyme in a secure way, either via password manager that you are using, or with the usage of ) *** ### 3. Setup Process Overview The setup consists of: * Smart contracts deployed by the Enzyme team * A small number of on-chain transactions that **you must execute** We will guide you through each required action. *** ### 4. Actions Required From You #### Step 1: Assign Vault Admin Rights * We will provide you with a contract address of the `LimitedAccessLimitedCallForwarder`. * Using the Enzyme Admin UI, set this address as your **Vault Admin**. * This enables the automation to update the vault’s share value. *** #### Step 2: Authorize the Automation Consumer * We will provide you with contract address of the `CreWorkflowConsumer`. * You must send an on-chain transaction to the `LimitedAccessLimitedCallForwarder` (address was provided in the **Step 1)** calling `addUser`. * The input should be the address of `CreWorkflowConsumer` . * This transaction must be sent via a blockchain explorer (e.g., Etherscan). *** #### Step 3: Allow Share Value Updates * You must send an on-chain transaction to the `LimitedAccessLimitedCallForwarder` (address was provided in the **Step 1)** calling `addCall`. * This authorizes the automation to update the vault’s share value. * We will provide: * The target contract is address of the `ValuationHandler` . You can find this address in the Admin UI under Advanced > Valuation ![Screenshot 2026-02-25 at 10.49.30.png](attachment:9150a21b-1c1f-4a7c-a65f-4105843f6eef:Screenshot_2026-02-25_at_10.49.30.png) * The function selector is `0x189ee485` (this is `updateShareValue` selector) * This transaction must also be sent via a blockchain explorer (e.g., Etherscan). *** #### Step 4: Approve the Automation Workflow * After deploying the automation, we will share a **workflow ID** with you. * You must send an on-chain transaction to approve this workflow ID. * This step ensures that only the approved automation can execute actions on your vault. *** ### 5. After Setup * Once all steps are completed, the automation will execute according to the agreed schedule. * Please ensure: * No vault activity occurs during execution windows * Your Octav API key remains valid * Tracked addresses maintain active Octav subscriptions If any vault parameters change (assets, tracked addresses, or schedule), please contact the Enzyme team before making updates. *** ### 6. Automation Script Updates & Client Approval * Any update or change to the automation logic requires deploying a **new workflow**. * For every update, the Enzyme team will provide you with a **new workflow ID**. * **No updated or modified automation can run without your explicit approval.** * To approve an update, you must send an on-chain transaction calling `setAllowedWorkflowId` with the new workflow ID given by Enzyme Team. * Until this transaction is executed, the updated automation **cannot interact with your vault**. * Previously approved workflows remain inactive. * This design ensures that **no code changes are executed without your on-chain consent**. ### 7. Support If you have questions or need help executing any transaction: * Contact the Enzyme team before proceeding * Do not attempt to bypass or modify the setup independently We are happy to assist to ensure everything runs smoothly. ### FAQ To learn how to create a public bundle --> [HERE](/onyx-user-documentation/administration-app/vault/markdown/portfolio-value-providers/octav) # Setting-Up CRE ### Setup Steps 1. **Enzyme Team** deploys `LimitedAccessLimitedCallForwarder` for the Shares contract. 2. **Enzyme Team** deploys `CreWorkflowConsumer` for the Shares contract. 3. **Client** sends an on-chain transaction setting the `LimitedAccessLimitedCallForwarder` address as the **Vault Admin**. * This can be done via the Enzyme Admin UI. 4. **Client** sends an on-chain transaction to the `LimitedAccessLimitedCallForwarder` contract calling `addUser` with: * `user`: `CreWorkflowConsumer` address * This should be executed via Etherscan. 5. **Client** sends an on-chain transaction to the `LimitedAccessLimitedCallForwarder` contract calling `addCall` with: * `_target`: `ValuationHandler` contract address * `_selector`: `0x189ee485` (selector for `updateShareValue`) * This should be executed via Etherscan. 6. **Enzyme Team** deploys the automation workflow script to Chainlink and provides the resulting **workflow ID** to the client. 7. **Client** sends an on-chain transaction to the `CreWorkflowConsumer` contract calling `setAllowedWorkflowId` with: * `workflowId`: value provided in the previous step. * This should be executed via Etherscan. # Subscription An Enzyme Vault deployed with Onyx can host any number of participants, from a single investor to an unlimited pool, allowing deposits in exchange for Vault Shares and subsequent redemptions.\ \ Subscriptions follow a queue-based, non-continuous model.\ \ This section covers the following topics: * [Subscription Assets](https://docs.enzyme.finance/onyx-user-documentation/enzyme-vault/subscription/assets) * [Queued System](https://docs.enzyme.finance/onyx-user-documentation/enzyme-vault/subscription/queues) * [Control](https://docs.enzyme.finance/onyx-user-documentation/enzyme-vault/subscription/control) * [Funds Transfer](https://docs.enzyme.finance/onyx-user-documentation/enzyme-vault/subscription/funds-transfer) {% hint style="info" %} Subscription means Deposits and Redemptions {% endhint %} # Assets Both deposits and redemptions are unrestricted across crypto asset classes. ## Deposits Each Enzyme Vault is configured with one or several ***Deposit Assets***, chosen by the Vault Owner or Admin. This asset (any ERC-20 token) is the one required for deposits.\ \ There can be several ***Deposit Assets.*** {% hint style="info" %} About ***Deposit Assets*** While the Enzyme Vault only accepts funds in the ***Deposit Asset(s)***, Vault Owners can develop an extra layer of onboarding on top of the Vault to swap, bridge, or on-ramp other asset classes. \ \ *Examples:* \ *- Collect funds via bank transfers and on-ramp them into the chosen **Deposit Asset**.*\ *- Collect funds on Solana, bridge them to the the Vault network and swap into the **Deposit Asset**.* {% endhint %} ## Redemptions Vault Owners can configure one or several ***Redemption Assets*** that can vary from the ***Deposit Assets***. Redemptions are executed on the Enzyme Vault network. # Deposits Vaults support two deposit models: **asynchronous deposits** and **synchronous deposits**. These can be used independently or in combination, depending on the vault's investment strategy and risk profile. **Asynchronous deposits** go through a queue and require administrator approval before being processed. This gives vault administrators full control over when and at what share price deposits are accepted. **Synchronous deposits** are processed instantly, without a queue or approval step. Depositors receive shares immediately at the current share price. # Asynchronous Deposits The default deposit mechanism is asynchronous and relies on a queue. **Deposit Requests** can : * Be arbitrarily processed by Vault Owners or Managers * Be executed in batch * Be cancelled by the depositor after a waiting period defined by the Vault Owner or Admins **Deposit Requests cannot** be cancelled by Vault Owner and Admins (*Subscriptions are on-chain transactions and only the initiator can revoke them*). However, Vault Owners and Admins may choose to ignore pending requests. {% stepper %} {% step %} ### Investor deposit funds The investor submits a deposit request, which enters a dedicated queue. {% endstep %} {% step %} ### Deposit Processing - NAV Calculation and Reporting Before new Vault Shares can be issued, the Vault Owner or Admin must evaluate the portfolio's underlying assets and positions, and report the ***Portofolio Value*** in the Administration App. {% endstep %} {% step %} ### Deposit Processing - Deposit Request Execution The Vault Owner or Admin approves pending deposit requests. This action triggers the issuance of Vault Shares, proportionally to the stake held in the Vault, which are then transferred to the depositor’s wallet. {% endstep %} {% step %} ### Funds consolidation in the Vault Once approved, the deposited funds are transferred into and consolidated within the Vault smart contract. {% endstep %} {% step %} ### Transfer to Management Wallet After processing, Vault Owners or Admins may withdraw funds from the Vault smart contract to the Management Wallet. {% endstep %} {% step %} ### Strategy execution From the ***Management Wallet***, managers are free to deploy funds across any system, protocol, or asset in line with their strategy. {% endstep %} {% endstepper %} # Synchronous Deposits ## Synchronous Deposits In addition to the standard asynchronous deposit queues, vaults can also use **synchronous deposits** as an alternative or complementary deposit mechanism. ### Overview Synchronous deposits allow depositors to make **instant deposits** without going through a deposit queue and without requiring administrator approval. This feature is best suited for vaults with slowly changing portfolio values and share prices typically vaults focused on yield generation. It is **not recommended** for vaults with volatile portfolio valuations, when the NAV is not updated regularly as outdated share prices could expose the vault to arbitrage risk. {% hint style="warning" %} Unlike the standard deposit queue, a synchronous deposit is processed immediately at the current share price, the moment the depositor submits it. {% endhint %} ### Deposit Window To prevent deposits from being processed against an outdated share price, vault administrators can configure a **deposit window**. This defines the period during which synchronous deposits are accepted, starting from the most recent valuation update. {% hint style="info" %} #### Without a threshold duration Synchronous deposits are always open. There is no time restriction after a valuation update. Combined with our NAV automation mechanism, this enables a fully synchronous and automated framework. {% endhint %} {% hint style="info" %} #### With a threshold duration 1. The administrator updates the vault's valuation. 2. A **deposit window** opens immediately for the duration of the threshold. 3. Depositors can make instant deposits during this window. 4. Once the window expires, synchronous deposits are **refused** until the next valuation update. This mechanism ensures that if a valuation update is missed for any reason, deposits are automatically blocked rather than processed at a stale price. **Example 1:** If the vault NAV is updated every 24 hours and the deposit window is set to 12 hours, synchronous deposits will be available up until NAV Update H+12, for the remaining time before the next NAV update, sync deposits won't be possible. {% endhint %} ### Configuration Enzyme will set up the **Synchronous Deposits** and the **Deposit Window** at vault deployment but this can be configured and updated throughout the lifetime of the vault. Synchronous deposits can be configured in two ways: * **As an additional mechanism** used alongside the standard deposit queue, giving depositors both options. * **As a full replacement :** the standard deposit queue is disabled entirely, and all deposits go through the synchronous path.
### Deposit Assets The deposit queue and synchronous deposits operate independently. Deposit assets can differ between both methods, allowing managers to define distinct subscription paths with asset sets tailored to each deposit route. # Redemptions The default redemption mechanism is asynchronous and relies on a queue. **Redemption Requests** can : * Be arbitrarily processed by Vault Owners or Managers * Be executed in batch * Be cancelled by the depositor after a waiting period defined by the Vault Owner or Admins **Redemption Requests cannot** be cancelled by Vault Owner and Admins (*Subscriptions are on-chain transactions and only the initiator can revoke them*). However, Vault Owners and Admins may choose to ignore pending requests. {% stepper %} {% step %} ### Investor fill redemption requests The investor submits a redemption request, which enters a dedicated queue. {% endstep %} {% step %} ### Redemption Processing - NAV Calculation and Reporting "Before redemptions can be processed, the Vault Owner or Admin must assess the portfolio’s underlying assets and positions, and report the NAV in the Administration App to determine the value of the assets being redeemed, including any profits or losses. {% endstep %} {% step %} ### Redemption Processing - Deposit Request Execution Once NAV has been calculated and reported, Vault Owner or Admins can execute the Redemption Request, triggering the transfer of funds from the Smart to the Depositor Address. {% hint style="warning" %} The Vault smart contract must have sufficient liquidity, and managers must ensure that funds are transferred to the contract beforehand. {% endhint %} {% hint style="info" %} A depositor can request to redeem any % of their shares. However, each redemption request has to be executed in full, i.e. it can't be executed partially by the fund owner. {% endhint %} {% endstep %} {% endstepper %} # Cross-Chain Deposits and Redemptions {% hint style="success" %} **Onyx enables cross-chain deposits and redemptions.** * Cross-chain functionality is available across any EVM-compatible network. * Compatible with both synchronous and asynchronous deposit workflows. {% endhint %} ## Cross-Chain Deposits You can deposit into an Onyx vault from a blockchain different from the one the vault lives on. The transfer is secured by [Chainlink CCIP](https://chain.link/cross-chain), Chainlink's cross-chain interoperability protocol. {% hint style="info" %} The ***Source Chain*** is the chain where you hold the deposit asset and initiate the transaction. The ***Vault Chain*** is the chain where the vault lives and where your deposit ultimately settles and your shares are minted. {% endhint %} #### Bridging Time The deposit transactions are confirmed on the source chain within seconds. The CCIP message then travels to the vault chain, where deposit are processed and your shares are minted. Delivery typically takes **20–30 minutes**. After submission, an alert on the deposit page links to the **CCIP Explorer** (`https://ccip.chain.link/tx/{your-tx-hash}`) where you can track the bridging progress in real time. {% hint style="info" %} A cross-chain deposit pays an additional CCIP messaging fee on top of standard network gas. The fee is included in the **Execute Deposit** transaction — you do not need to send a separate payment. {% endhint %} ## Cross-Chain Redemptions Vault shares always live on the **vault's chain,** they are never bridged back to the source chain deposits are from. Despite that, investors do not need to switch their wallet to the vault chain to redeem them. The redeem page lets them initiate redemption directly from the source chain, and CCIP relays the request across for them. See [Redemptions](/onyx-user-documentation/enzyme-vault/subscription/redemptions) for the general redemption flow. {% hint style="info" %} Shares from a cross-chain deposit are held in a wallet on the vault chain that you control through your source-chain address. From your perspective, you simply stay on the source chain throughout deposit, redemption, and any cancellation. {% endhint %} # Control Enzyme Vaults provide flexible mechanisms for managers to define **who can invest, transfer shares, or interact with the Vault**. These controls allow Vaults to meet regulatory, compliance, or business-specific requirements while still leveraging the openness of blockchain infrastructure. ## Vault Share Transferability Vault Owners can configure the Vault Shares transferability to: * **Enable free transferability** → Shares can be traded or transferred like any other ERC20 token. * **Disable transferability** → Shares remain bound to the depositing address and cannot be moved. ## Whitelisting Vault Owners can choose to restrict participation by enabling a **whitelist**. * Only wallet addresses explicitly added by the Vault Owner or Manager will be able to deposit into the Vault. * Whitelists can be updated dynamically, giving managers full control over investor onboarding. ## KYC / KYB Enzyme does not enforce KYC (Know Your Customer) or KYB (Know Your Business) at the protocol level. **However,** Vault Owners and Managers can request to deploy an extra layer, using the service provider of their choice. # Funds transfer ## Upon Deposits Assets consolidated in the Vault smart contract can be withdrawn to the ***Management Wallet*** via the ***Management App***. {% stepper %} {% step %} ### Enter the recipient wallet address (Management Wallet) {% endstep %} {% step %} ### Determine the assets to be transferred {% endstep %} {% step %} ### Approve transaction {% endstep %} {% endstepper %} {% hint style="warning" %} Funds are transferred to the Management Wallet on the same network as the Vault. {% endhint %} ## Upon Redemptions To send funds to your Vault, send assets directly to its smart contract address **on the Vault’s network.** # Fees Enzyme Vaults support a flexible fee framework, allowing managers to define **types, recipients, and assets** for fee collection. ## Fee Types Enzyme.Onyx supports four fee types: * **Management Fee** → Custom logic defined by the manager * **Performance Fee** → Custom logic defined by the manager * **Entrance Fee** → Flat percentage applied on deposits * **Exit Fee** → Flat percentage applied on redemptions ## Fee Recipient * Each fee can be directed to any arbitrary **fee recipient address**. * If no fee recipient is set for the **entrance** or **exit** fee, the fee is **burned**, effectively redistributing it pro-rata to all existing shareholders. ## Fee Asset * All fees are distributed in the **fee asset** established at deployment. * The fee asset can be changed at any moment by the Vault Owner or Admins. {% hint style="success" %} For more information about fees management, please visit our Protocol Documentation [HERE](https://enzyme-finance.gitbook.io/onyx/onyx-protocol). {% endhint %} # Settlement {% tabs %} {% tab title="Management and Performance Fees" %} Management and performance fees **ARE ALWAYS** settled at the time of NAV update. {% endtab %} {% tab title="Entrance and Exit Fees" %} Entrance and exit fees **CAN** be settled during deposit and redeem flows. The deposit and redeem handler decides whether to invoke the fee. {% endtab %} {% endtabs %} {% hint style="info" %} Learn more about Fee Settlement [HERE](https://enzyme-finance.gitbook.io/onyx/onyx-protocol/general-flows/fee-settlement). {% endhint %} # Distribution Settled fees are not immediately distributed, but are tracked as debts, which are asynchronously distributed at a later time. Fees are distributed in the **fee asset.** When necessary, owed fees are converted from the value asset to an amount of the fee asset at the time of distribution. **Distribution can be triggered at any time by the Vault Owner or Vault Admins.** {% hint style="info" %} Learn more about Fee Settlement [HERE](https://enzyme-finance.gitbook.io/onyx/onyx-protocol/general-flows/fee-settlement). {% endhint %} # Programmatic Split Fee distribution can be programmatically configured to split payments across multiple addresses using Payment Splitter contracts. *For example: 70% of fees distributer to your Fee Recipient Address and 30% to a delegated manager* # High Watermark The **Administration App** allows **Managers** to set up **High Watermark** on performance fees.\ \ A **High Watermark** is a performance-based threshold ensuring that performance fees are only charged on new profits above the vault’s previous highest net asset value (NAV).\ \ Learn more [HERE](/onyx-protocol/contract-implementations/fees). # Hurdle Rate ## What the hurdle rate does A hurdle rate defines a minimum level of performance that must be achieved before any performance-based compensation becomes payable. If performance does not exceed this threshold, the effective performance fee is zero, regardless of the nominal fee rate. \ Put differently: * The hurdle rate does not cap returns * It does not introduce a separate fee * It conditions the existence of a performance fee on achieving a minimum level of performance * The hurdle rate therefore acts as a gatekeeper, not as an additional fee layer. ## How does it operate Conceptually, the mechanism works as follows: \ 1\. Performance is measured over the relevant period (commonly relative to a high-water mark).\ 2\. Performance is compared against the hurdle rate.\ 3\. If performance ≤ hurdle rate → No performance fee is payable.\ 4\. If performance > hurdle rate → A performance fee is calculated on the excess performance according to the defined fee rules.
The hurdle rate is applied within the performance fee calculation itself, not as a post-processing adjustment. ## Relationship to performance fees Key characteristics: * The hurdle rate is embedded within performance fee logic * It can reduce the effective performance fee down to zero * It is not a standalone or composable mechanism * It cannot be meaningfully layered with additional hurdle constructs
# Compliance Enzyme Vaults can enforce onchain compliance through [Chainlink ACE](https://docs.chain.link/ace) (Automated Compliance Engine), an onchain policy engine. Compliance rules live in dedicated policy contracts, separate from the vault's core logic, so they can be added, changed, or removed without redeploying the vault. ### What can be gated Compliance checks can be applied to the following vault actions: * **Deposits** — both synchronous deposits and request-based deposits * **Redemption requests** * **Share minting and burning** * **Share transfers** — any transfer of vault shares between wallets Checks are configured per action, and a vault may use none, some, or all of them. ### How it behaves When a gated action is performed, the vault passes the details of the action (such as the depositor wallet and the amounts involved) to the policy engine, which evaluates them against the configured policies in order. {% hint style="warning" %} If any policy rejects the action, the entire transaction reverts. The deposit, redemption, mint, burn, or transfer does not take place, and no assets or shares move. {% endhint %} ### Example policies Policies can, for example: * require that a wallet holds a verified identity credential (such as KYC or AML status), using Chainlink ACE's cross-chain identity framework * screen wallets against allowlists and denylists (e.g. sanctioned addresses) * restrict an action to wallets holding a specific role, such as verified or accredited investors * enforce volume or rate limits * pause a given action entirely, or restrict it to certain time intervals The exact set of rules is defined per vault, so the checks a depositor encounters depend on how that vault is configured. ### Configuration Only the vault owner or its admins can enable, replace, or disable compliance checks on a vault. The policy rules themselves are managed on the Chainlink policy engine. Chainlink ACE is one of the validation mechanisms available to Enzyme Vaults — share transfers, for example, can alternatively be restricted using address lists. # Overview Enzyme.Onyx provides a state-of-the art ***Administration App*** enabling users to manage their Vaults as well as collections. \ \ This section covers:\ – [Collection Management](https://enzyme-finance.gitbook.io/onyx/management-app/editor)\ – [Vault Management](https://enzyme-finance.gitbook.io/onyx/management-app/vault)

Enzyme Onyx Management App Homepage

# Log-In ## E-mail The access to the Administration App is gated with an email shared to Enzyme prior Vault deployment. {% stepper %} {% step %} ### Enter your email address on the login screen.
{% endstep %} {% step %} ### Check your inbox for a confirmation email.
{% endstep %} {% step %} ### Approve the login request by clicking the link in the email.
{% endstep %} {% endstepper %} *** ## Wallet Connection Connecting a wallet is required to proceed with on-chain actions within the ***Administration App*** such as updating the ***Holdings Valuation*** or processing the ***Deposit and Redemptions Queues***.\ \ Enzyme.Onyx allows you to connect with more than 470 wallets. **Only the Owner Wallet and Admin Wallets are authorized to execute transactions within the Administration App.** {% hint style="info" %} Learn more about Vault Admin whitelisting [HERE](https://enzyme-finance.gitbook.io/onyx/management-app/vault/configuration). {% endhint %} {% stepper %} {% step %} ### Click on Connect Wallet, choose the stack of your choice
{% endstep %} {% step %} ### Approve the connection in your custody stack {% endstep %} {% endstepper %} # Collections Collections are customizable catalogs that let you group different Vaults according to the strategy of your choice — such as underlying strategy, delegated manager, investment objectives and more...
**A Vault can belong to multiple Collections.** This section covers:\ – [Collection Creation](https://enzyme-finance.gitbook.io/onyx/management-app/editor/create-a-collection)\ – [Collection Management](https://enzyme-finance.gitbook.io/onyx/management-app/editor/manage-a-collection) {% hint style="info" %} Collections are also consumer-facing: you can share a Vault Collection with your users, along with the Vaults it contains. {% endhint %} # Create a Collection Users can create Collection from the ***Administration App*** Homepage.
In **Create Vault Collection**, insert: * Name of your tokenized product * Sub-domain: This is the URL where your investor vault page can be accessed. * Tagline * Description : share details about you, your **Collection** and any useful investor information
# Manage a Collection ## Vault Information A **Collection** information can be edited from the Vault Collection homepage using the **Edit** function.
Information You can update at any moment: * Collection Name * Subdomain * Tagline * Description
Icon
Cover
Social Channels
Theme Your customers will see Vault Collections in either Light or Dark mode, and you can customize the primary colors to reflect your brand.
## Adding a Vault Vaults can be added to **Collections** from the Vault Collection homepage using the **Edit Vault Selection** function.
Select the desired Vaults and **Save Selection**. The Vaults will appear in your Vault Collection, under **Managed Vaults**.
# Vault Each Vault you own has a dedicated interface, accessible from the ***Administration App*** homepage under **Managed Vaults**.
The Overview section provides key information about your Vault’s structure and activity, such as share price, depositors, and deposit/redemption queues. This section covers:\ – [Vault Configuration](https://enzyme-finance.gitbook.io/onyx/management-app/vault/configuration)\ – [Accounting Management](https://enzyme-finance.gitbook.io/onyx/management-app/vault/markdown)\ – [Subscription Management](https://enzyme-finance.gitbook.io/onyx/management-app/vault/subscription-management)\ – [Fee Management](https://enzyme-finance.gitbook.io/onyx/management-app/vault/fee-management)
# Configuration ## Vault Information Under **Vault Information**, you can update at any moment: * Vault Icon * Tagline * Description
## Vault Admins **Vault Admins** allow you to manage Admin roles for a specific Vault. ***Vault Admins*** are identified through ***Admin Wallets***. {% hint style="info" %} A ***Vault Admin*** is delegated role that can manage specific operational tasks such as accounting or subscription processing. *The Vault Admin role applies only at the Vault level and does not extend to the Collection level.* {% endhint %}
### Adding a Vault Admin Using **Add Admin**, simply enter the wallet address you wish to whitelist.
### Removing a Vault Admin Click the **Bin** icon next to the wallet you want to remove. Confirm removal.
## Advanced Configuration {% hint style="info" %} Advanced Configuration refers to key parameters related to the management of the Vault. Currently, changes can only be made by the Enzyme team, with self-service functionality coming soon. {% endhint %} {% tabs %} {% tab title="Vault" %}
{% endtab %} {% tab title="Valuation" %}
{% hint style="info" %} For more information about Valuation Handler and Tracked Positions, visit Protocol. {% endhint %} {% endtab %} {% tab title="Fees" %}
{% hint style="info" %} For more information about Fee Handler, Tracker visit Protocol.\ \ For more information about Fee Management, visit Fees. {% endhint %} {% endtab %} {% tab title="Deposits" %}
{% hint style="info" %} For more information about Deposit Handler, visit Protocol. For more information about Deposit Asset, visit Subscription. {% endhint %} {% endtab %} {% tab title="Redemptions" %}
{% hint style="info" %} For more information about Redemption Handler, visit Protocol. For more information about Redemption Asset, visit Subscription. {% endhint %} {% endtab %} {% tab title="Shares Transfer Validation" %} This page is mainly informational, it shows the following: * Shares transfer validator address * **Sender list** and **Recipient list** (with mode badges when applicable, e.g. Allow / Disallow) **Allow list** Only addresses on this list are treated as allowed; everyone else is blocked. **Disallow list** Addresses on this list are blocked; everyone else is allowed. * **SenderList - Allow Mode:** Only addresses on the sender list **may send** (transfer out) shares. * **SenderList - Disallow Mode:** Addresses on the sender list **may not send** shares; everyone else may (subject to other rules). * **RecipientList - Allow Mode:** Only addresses on the recipient list **may receive** shares. * **RecipientList - Disallow Mode:** Addresses on the recipient list **may not receive** shares; everyone else may (subject to other rules). To **change** which validator or lists are attached, use **Contact Us** button. To **add or remove addresses** on those lists, go to **Address Lists** and look for usage badges **Transfer shares (sender)** or **Transfer shares (recipient)**.
{% endtab %} {% endtabs %} # Accounting Management This section covers:\ – [Holdings Valuation](https://enzyme-finance.gitbook.io/onyx/management-app/vault/markdown/holdings-valuation)\ – [Tracked Assets](https://enzyme-finance.gitbook.io/onyx/management-app/vault/markdown/tracked-assets)\ – [Expenses and Income](https://enzyme-finance.gitbook.io/onyx/management-app/vault/markdown/expenses-and-income)\ [- Portfolio Value providers](https://docs.enzyme.finance/onyx-user-documentation/administration-app/vault/markdown/portfolio-value-providers) # Updating the NAV ## How to update the NAV manually 1\) Consolidate the underlying [**Portfolio Value**](/onyx-user-documentation/enzyme-vault/accounting/portfolio-value), with the method of your choice\ 2\) Under **Update Portfolio Value**, insert the proper amount. You can also fetch this amount automatically if you have set up a [Portfolio Value Provider](/onyx-user-documentation/administration-app/vault/markdown/portfolio-value-providers).

{% hint style="warning" %} As you are looking at [updating your NAV](/onyx-user-documentation/administration-app/vault/markdown/updating-the-nav), you should only be looking at reporting the value of your investments. As such, the Portfolio Value is not supposed to include:\ \- Any accrued fees (Onyx accrues this for you and takes it into account for the NAV Calculation)\ \- Any liquidity held in the Vault smart contract that hasn't been allocated yet - the [Liquidity Buffer](/onyx-user-documentation/enzyme-vault/accounting/liquidity-buffer)\ \- Any accounting positions which are to be recorded separately - see [Expenses and Income](/onyx-user-documentation/enzyme-vault/accounting/expenses-and-income)\ \ The App will show you the "Automatically Tracked Value" that correspond to the Liquidity Buffer and the recorded Expenses and Income. {% endhint %} 3\) Update the exchange rate if need be 4\) Execute the on-chain transaction ## Managing Asset Exchange Rate Exchange Rates ensure that the total value of your Vault’s underlying holdings is accurately reflected when tracked assets are denominated in different currencies. When updating Holdings Valuation, you can apply the current exchange rate to calculate the most precise NAV and Vault Share Price.
\ Vault Valuation allows you to define an exchange rate that never expires (useful when the rate is fixed or always equivalent).\ \ If the exchange rate is subject to change, Vault Valuation also lets you set an expiry date for the rate you apply.
# Reporting Expenses and Income The Accounting section provides an overview of existing capitalised expenses and deferred items, as well as the option to add new entries. {% hint style="info" %} Learn more about Expenses and Income [HERE](https://enzyme-finance.gitbook.io/onyx/enzyme-vault/accounting/expenses-and-income). {% endhint %}
## Adding a Capitalised Expense The ***Administration App*** allows you to add a new expense by specifying the total amount, start and end date, and a description.
## Adding a Deferred Income The ***Administration App*** allows you to add a new income by specifying the total amount, start and end date, and a description.
# Portfolio Value Providers Portfolio Value Providers allow you to connect your external portfolio or asset-management services directly to the platform. Once connected, you can **fetch the Net Asset Value (NAV)** from your selected provider using the **Fetch** button in the **Valuation Form**, helping reduce manual data entry and keeping valuations consistent and up to date. #### Key Features * Connect supported external portfolio or custody providers. * Fetch NAV data on demand directly from the Valuation Form. * Reduce manual input errors and streamline the valuation workflow. #### Supported Providers The **Supported Providers** subpages contain the full list of available Portfolio Value Providers. Each provider page includes detailed instructions explaining how to connect and configure the integration. # Octav This page describes step-by-step instructions on how to connect Octav to the Admin App. ### 1. Create a public Bundle In order for Enzyme Onyx to fetch the entire portfolio from Octav, a public bundle must be created.\ \ First, create a bundle in the Octav app:
Then, set its visibility to **Public** in the account settings.
This is how it should look. The bundle URL can be found on the screen below.\ In this example, the **Bundle Name** is `my-lite-bundle`, and the **Bundle URL ID** is `T6yrwgVC`. Write down these values, as you will need them in a later step.
### 2. Create an API key To create an API key, follow the steps in the Octav docs: .\ Save the API key in a secure place, as you will need it in the next step. ### 3. Connect Octav to Onyx in the Admin App Navigate to **Vault > Advanced > Portfolio Value Provider**. Fill out the form with the following values: * **API Key** – use the value from Step 2 * **Bundle Name** – use the value from Step 1; in our example, it is `my-lite-bundle` * **Bundle URL ID** – use the value from Step 1; in our example, it is `T6yrwgVC`
Click the **"Connect"** button. The values will be automatically verified upon submission, and you will receive a confirmation once the connection is successful. # 1Token This page describes step-by-step instructions on how to connect 1Token to the Admin App. ### 1. Create an API Key & Secret Go through the 1Token docs on creating an API Key & Secret: In the scope, choose the portfolio you want to use. For the permission, select `All Business Viewers (cannot export)`. This is the minimal access Onyx requires to retrieve the NAV of the portfolio. Store the API Key & Secret in a secure place — you will need them in the next step. ### 2. Get the Portfolio ID Go to **Ops & Accounting > Portfolio Setup**.\ Enable the **Portfolio ID** column (it is not shown by default).\ Copy and save the Portfolio ID, as you will need it in the next step.
### 3. Connect 1Token to Onyx in the Admin App Navigate to **Vault > Advanced > Portfolio Value Provider**. Fill out the form with the following values: * **Subdomain** – use the subdomain of the 1Token.tech domain you log in with.\ For example, if you access your account at , then `mysubdomain` is your subdomain. * **API Key** – use the value from Step 1 * **API Secret** – use the value from Step 1 * **Portfolio ID** – use the value from Step 2
Click the **"Connect"** button. The values will be automatically verified upon submission, and you will receive a confirmation once the connection is successful. # Subscription Management This section covers:\ \- [Deposit Queue](https://enzyme-finance.gitbook.io/onyx/management-app/vault/subscription-management/deposit-queue)\ \- [Redemption Queue](https://enzyme-finance.gitbook.io/onyx/management-app/vault/subscription-management/redemption-queue)\ \- [Funds Transfer](https://enzyme-finance.gitbook.io/onyx/management-app/vault/subscription-management/funds-transfer) # Deposit Queue Through **Deposit Requests**, you can view your Deposit Queue and process requests.
{% hint style="info" %} Fore more information, please visit [Deposit Flow](https://enzyme-finance.gitbook.io/onyx/enzyme-vault/subscription/queues/deposit-flow). {% endhint %} ## Updated Valuation A deposit triggers the issuance of new Vault Shares. Before shares can be issued, the Vault Owner or Admin must evaluate the portfolio’s underlying assets and positions, and record the ***Holdings Valuation*** in **Vault Valuation**. By default, deposit requests will prompt you to update the ***Holdings Valuation*** before execution. ⚠️ *No deposit can be executed unless you acknowledge and confirm that you have understood the warning.* ## Processing a deposit Deposits can be processed individually or in batches by selecting them. Deposit Requests cannot be rejected (as they are on-chain transactions), but they can be ignored.
The process of accepting a Deposit Request is an on-chain transaction :\ :arrow\_forward: Only Vault Owner and Vault Admins can execute such commands using their Owner Wallet and Admin Wallets\ :arrow\_forward: Triggers a transaction to approve in the wallet interface of either the Owner Wallet or the Admin Wallet executing the transaction # Redemption Queue **Redemption Requests** give you access to your ***Redemption Queue*** and process the requests. {% hint style="info" %} Fore more information, please visit [Redemption Flow](https://enzyme-finance.gitbook.io/onyx/enzyme-vault/subscription/queues/redemption-flow). {% endhint %} ## Updated Valuation A redemption triggers the burning of Vault Shares and the transfer of funds to the depositor. As a result, the ***Vault Owner*** or ***Admin*** must evaluate the portfolio’s underlying assets and positions before executing a redemption to ensure that depositors’ Vault Shares are accurately valued. By default, **Redemption Request** will prompt you to update the ***Holdings Valuation*** before execution. ## Transferring funds to the Vault smart contract Once the Holdings Valuation has been updated, the ***Vault Owner***, ***Vault Admin*** or ***Managers*** must transfer the value of the depositors portfolio to the Vault smart contract if liquidity is not sufficient. ## Processing a redemption Redemptions can be processed individually or in batches by selecting them. Redemption Requests cannot be rejected (as they are on-chain transactions), but they can be ignored. {% hint style="success" %} By executing Redemption Requests, you automatically trigger the burn of the Vault Shares as well as the funds transfer from the Vault smart contract to the Depositor Address. {% endhint %} The process of accepting a Redemption Request is an on-chain transaction :\ :arrow\_forward: Only Vault Owner and Vault Admins can execute such commands using their Owner Wallet and Admin Wallets\ :arrow\_forward: Triggers a transaction to approve in the wallet interface of either the Owner Wallet or the Admin Wallet executing the transaction # Cross Chain Enablement Cross-chain deposits allow users to deposit into your vault from a blockchain different from the one the vault lives on. The transfer between chains is handled by [Chainlink CCIP](https://chain.link/cross-chain), Chainlink's cross-chain interoperability protocol. {% hint style="info" %} A ***Cross-Chain Deposit*** is a deposit initiated on a chain different from the vault's home chain. The deposit asset is bridged via CCIP and settled on the vault's chain, where the depositor receives their shares. {% endhint %} ### Enabling Cross-Chain Deposits Cross-chain deposits are configured from your vault's **Advanced Configuration** under the **Cross Chain** tab. Each chain you enable here becomes a source chain that your users can deposit from. Users connected to any enabled chain will see it as an option on the deposit form. #### Adding a Source Chain Navigate to **Vault → Configure → Advanced → Cross Chain**. Click the **+** button to open the chain picker, select the chain you want to enable, and confirm. The chain becomes available to depositors immediately.
{% hint style="warning" %} Before enabling a new source chain, verify two things in the official [Chainlink CCIP Directory](https://docs.chain.link/ccip/directory): * The **lane** between the source chain and your vault's chain is active. * Your vault's **deposit token** is supported on that lane (has a CCIP token pool registered for the pair). If either is missing, depositors will see an "asset cannot be bridged" message and will be unable to deposit from that chain. {% endhint %} #### Removing a Source Chain To stop accepting new deposits from a chain, remove it from the list. Removal only blocks **future** deposits from that source — it has no effect on what has already happened. {% hint style="info" %} Removing a chain does **not** cancel pending cross-chain deposits already in flight; those continue to settle normally. Depositors who already hold shares minted from past cross-chain deposits can still redeem them as usual, regardless of whether the original source chain is still enabled. {% endhint %} ### What Your Depositors See Once a chain is enabled, depositors connected to that network can pick it from the **Chain** dropdown on your vault's deposit page. For the full depositor walkthrough, see [Cross Chain Deposits](/onyx-user-documentation/investor-interface/cross-chain-subscription) in the Investor Interface documentation. {% hint style="info" %} Cross-chain deposits incur an additional CCIP messaging fee paid by the depositor as part of the deposit transaction. Bridging from the source chain to the vault chain typically takes 20–30 minutes. {% endhint %} # Funds Transfer **Funds Transfer** allows you to move assets from your Vault smart contract to ANY ***Management Wallet.*** \ \ Simply add the address of the desired ***Management Wallet*** and click on **Move**.
The process of transferring funds to a ***Management Wallet*** is an on-chain transaction :\ :arrow\_forward: Only Vault Owner and Vault Admins can execute such commands using their Owner Wallet and Admin Wallets\ :arrow\_forward: Triggers a transaction to approve in the wallet interface of either the Owner Wallet or the Admin Wallet executing the transaction # Fee Management **Distribute Fees** allows you to transfer collected fees to the addresses configured as Fee Recipients.
## Total Fees Owed Total Fees Owed consolidates all fees accrued based on the fee types you have configured. {% hint style="info" %} Learn more about Fees, [HERE](https://enzyme-finance.gitbook.io/onyx/enzyme-vault/fees). {% endhint %} {% hint style="warning" %} **Total Fees Owed** represents the remaining fees owed that have not yet been distributed, rather than a life-to-date total. {% endhint %} ## Available Liquidity Available Liquidity refers to the funds currently held in the Vault smart contract. {% hint style="success" %} **Why would Total Fees Owed differ from Available Liquidity?** \ \ 1\) Fees are not automatically transferred to the Vault smart contract. They remain in your Management environment and must first be transferred to the Vault smart contract before being processed processed.\ \ 2\) Fees can be distributed using any liquidity available in the smart contract (*for example, funds collected from deposits*). However, liquidity may still fall short. {% endhint %} ## Distributing Fees 1\) Select the Fee Recipient\ 2\) Select the amount according to the Available Liquidity and Total Fees Owed\ 3\) Confirm with **Distribute Fees**\ \ The process of distributing fees is an on-chain transaction :\ :arrow\_forward: Only Vault Owner and Vault Admins can execute such commands using their Owner Wallet and Admin Wallets\ :arrow\_forward: Triggers a transaction to approve in the wallet interface of either the Owner Wallet or the Admin Wallet executing the transaction # Address Lists Management An **address list** is an on-chain contract that holds a set of wallet addresses. Your vault uses these lists to control **who can do what** — for example: * who may **send** or **receive** vault shares (transfer validation), or * who may **deposit** through a deposit handler (deposit allowlist). Address Lists appear only when they are **already connected** to your vault (transfer validator or a deposit handler). You manage **members** (add / remove addresses) on those lists. ### Address Lists Page #### **When the page is empty** You’ll see: *“No address lists are configured for this vault.”* That means no list is currently referenced by: * the shares **transfer validator** (sender or recipient list), or * an **ERC-7540 deposit queue** external allowlist, or * a **sync deposit handler** allowlist. Lists are not shown just because they exist on-chain — they must be **wired to your vault**. To attach a new list or change which list is used, contact [Enzyme support](mailto:support@enzyme.finance) #### **When lists appear** \ Each list is shown as a **card** with:
1. **List contract address** — the on-chain list (with explorer link). 2. **List type badge** * **Ownable** — standard ownable list. The owner of this list can be any chosen arbitrary wallet. * **Shares owned** — list tied to vault shares; same add/remove actions in the UI. Any admin or owner of the shares can manage it. 3. **Usage badges** — what this list controls for *your* vault, for example: * **Transfer shares (sender)** / **(recipient)** — linked transfer validator * **Deposit queue** — ERC-7540 external allowlist * **Sync deposit handler** — sync handler allowlist One list can have **multiple badges** if the same contract is used in more than one place. #### **Managing members (add / remove)** 1. Open **Address Lists**. 2. Find the list (usage badges help you pick the right one). 3. **Add address** — use **Add Address** button (wallet must be the owner of the Address List; confirm on-chain). You'll be taken to a new page where you can add addresses in that address list either one at a time, or in batch by copy pasting addresses separated by commas. Once you paste addresses, click the **Load** button to confirm set of addresses and submit transaction to add them.
4. **Remove addresses** — select checkboxes (or trash on a row) → **Remove Addresses** → confirm. (wallet must be the owner of the Address List) If you arrived from Deposit Requests with the **Address List** card, the correct list is **highlighted** and scrolled into view.
> ***Note:** Member addresses sync from the blockchain via the indexer. After a transaction confirms, the list may take a short time to update in the app.* # SDK and API Beyond the Administration App, **Enzyme Onyx** provides a complete **API and SDK suite** for developers and integrators. * The **API** lets you query comprehensive data related to your vaults and vault collections, including both current and historical states. * The **SDK** enables direct interaction with Onyx smart contracts, giving you full control over vault-level operations. Together, the API and SDK empower builders to create **custom frontends**, **reporting dashboards**, and **automation tools** tailored to their Onyx vaults.\ \ They offer managers a flexible sandbox to extend functionality, for example, implementing **automated NAV updates**, **deposit and redemption processing**, or other workflow integrations.\ \ Learn more about our [SDK](https://docs.enzyme.finance/onyx-sdk/) and [API](https://api.onyx.enzyme.finance/reference). # Overview Enzyme.Onyx provides a dedicated Investor Interface that enables investors to deposit directly into your tokenized product and redeem their shares with ease. This interface works seamlessly for both **Collections** and **Vaults**. {% hint style="success" %} A white-label integration via API and SDK will also be available soon. {% endhint %} ## Collection Overview
## Vault Overview The Vault Investor Interface provides investors with key information about your product, including share price, assets under management, balance sheet, and fees.
# Wallet Connection Depositor can engage with your product by connecting with a Wallet. Enzyme.Onyx allows you to connect with more than 470 wallets. {% hint style="info" %} While Enzyme.Onyx natively manages Vault access through wallet connections, Vault Owners can implement additional onboarding layers to support: * On-ramp solutions (e.g., bank transfers → crypto) * KYB / KYC verification * Other participation methods of their choice {% endhint %}
# Deposits ## Deposit Request
### Creation The Investor Interface allows investors to manage their deposits requests. \ \ After entering the desired amount, the investor must first **approve the transaction**, which grants permission for the Vault Owner or Admin to execute the request at a later stage. Next, the investor must **confirm the operation** to finalize the request. Both steps are on-chain transactions. ### Management Once a deposit is submitted, it is added to the **Deposit Queue** and awaits processing by the Vault Owner or Admins. Deposit requests can be cancelled by the investor at any time, unless the Vault Owner has defined a minimum holding period. Investors can view their Pending and Executed Deposit Requests directly in the Investor Interface. ### Allowlist If an allowlist has been set up, Enzyme.Onyx will verify the depositor’s wallet address and block any transaction from addresses not included on the list.
### Synchronous Deposits Synchronous deposits can be configured in two ways: * **As an additional mechanism** used alongside the standard deposit queue, giving depositors both options. * **As a full replacement :** the standard deposit queue is disabled entirely, and all deposits go through the synchronous path.
The deposit queue and synchronous deposits operate independently. Deposit assets can differ between both methods, allowing managers to define distinct subscription paths with asset sets tailored to each deposit route. # Redemptions ## Redemption Request
### Creation The Investor Interface allows investors to manage their redemption requests. \ \ After entering the desired amount, the investor must first **approve the transaction**, which grants permission for the Vault Owner or Admin to execute the request at a later stage. Next, the investor must **confirm the operation** to finalize the request. Both steps are on-chain transactions. ### Management Once a deposit is submitted, it is added to the **Redemption Queue** and awaits processing by the Vault Owner or Admins. Redemption requests can be cancelled by the investor at any time, unless the Vault Owner has defined a minimum holding period. Investors can view their Pending and Executed Deposit Requests directly in the Investor Interface. # Cross Chain Subscription ## Cross-Chain Deposits You can deposit into an Onyx vault from a blockchain different from the one the vault lives on. The transfer is secured by [Chainlink CCIP](https://chain.link/cross-chain), Chainlink's cross-chain interoperability protocol. {% hint style="info" %} The ***Source Chain*** is the chain where you hold the deposit asset and initiate the transaction. The ***Vault Chain*** is the chain where the vault lives and where your deposit ultimately settles and your shares are minted. {% endhint %} ### Making a Cross-Chain Deposit The cross-chain flow follows the same shape as a standard deposit — see [Deposits](/onyx-user-documentation/enzyme-vault/subscription/deposits) for the general lifecycle. The sections below cover only what is different when depositing from another chain. #### Selecting a Source Chain On the vault's deposit page, open the **Chain** dropdown next to the amount field. The dropdown lists every chain the vault admin has enabled as a source. Pick the chain you currently hold the deposit asset on. If your wallet is connected to a different network than the chain you select, you will be prompted to switch networks before continuing. The form inputs remain disabled until your wallet is on the correct chain.
#### Approving and Submitting Cross-chain deposits use the same two-step pattern as native deposits: first **Approve {Asset}**, then **Execute Deposit**. Both transactions are signed on the source chain. Tick the terms checkbox to enable the buttons. #### Bridging Time Once you submit **Execute Deposit**, the transaction is confirmed on the source chain within seconds. The CCIP message then travels to the vault chain, where your deposit is processed and your shares are minted. Delivery typically takes **20–30 minutes**. After submission, an alert on the deposit page links to the **CCIP Explorer** (`https://ccip.chain.link/tx/{your-tx-hash}`) where you can track the bridging progress in real time. {% hint style="info" %} A cross-chain deposit pays an additional CCIP messaging fee on top of standard network gas. The fee is included in the **Execute Deposit** transaction — you do not need to send a separate payment. {% endhint %} ### Redeeming Shares from a Cross-Chain Deposit Vault shares always live on the **vault's chain** — they are never bridged back to the source chain you deposited from. Despite that, you do not need to switch your wallet to the vault chain to redeem them. The redeem page lets you initiate redemption directly from the source chain, and CCIP relays the request across for you. See [Redemptions](/onyx-user-documentation/enzyme-vault/subscription/redemptions) for the general redemption flow. {% hint style="info" %} Shares from a cross-chain deposit are held in a wallet on the vault chain that you control through your source-chain address. From your perspective, you simply stay on the source chain throughout deposit, redemption, and any cancellation. {% endhint %} #### Selecting Where to Redeem From On the vault's redeem page, the **Chain** dropdown lists every chain from which you currently have redeemable shares, including any held from past cross-chain deposits. Each option shows the chain and the available share balance. Pick the entry that matches the source chain of your original deposit.
#### Submitting a Cross-Chain Redemption Connect your wallet to the source chain you selected. The submission signs a CCIP message on that chain, which travels to the vault chain and queues the redemption request there — you do not need to interact with the vault chain yourself. An additional CCIP messaging fee applies, similar to a cross-chain deposit. {% hint style="info" %} Cross-chain redemption goes through your vault's standard redemption queue once the CCIP message is delivered. Final settlement timing depends on the vault's redemption policy in addition to the 20–30 minute CCIP bridging window. {% endhint %} ### Cancelling a Cross-Chain Deposit Cross-chain deposits can be cancelled from the **Pending Deposit Requests** table once their cancellation window has elapsed. Because the original deposit travelled across chains, the cancellation must travel back the same way — this requires a second CCIP message, which has its own fee. #### Approving the Return Fee Connect your wallet to the **source chain** of the original deposit. The modal displays the wrapped native token required to pay the CCIP return-message fee (for example, **WETH** on Ethereum), the exact amount needed, and your current balance. Click **Approve** to authorise the fee token.
#### Submitting the Cancellation After the approval confirms, the modal advances to step two. Click **Cancel Deposit Request** to sign the cancellation. This sends a CCIP message from the source chain to the vault chain instructing it to return your deposit. #### Waiting for the Return CCIP relays the cancellation message and then ships the returned funds back to your wallet on the source chain. The full round trip typically takes a few minutes to around 30 minutes. A toast notification confirms submission and links to the CCIP Explorer. {% hint style="info" %} Do not submit a second cancellation for the same deposit while the first is in flight. Wait until the return is delivered before taking further action. {% endhint %} # Fund Migration Enzyme Onyx supports migration from any existing fund structure, whether assets are held on-chain, off-chain, or across a combination of both. This guide walks through the standard migration pathway, which requires no action from your investors. {% hint style="info" %} **Standard pathway:** The fund manager executes the entire process. Investors do not need to take any action and their proportionate economic interest is preserved in the new vault --> No redemption / Deposit is required here. {% endhint %} {% hint style="info" %} **No position exits required.** With Enzyme Onyx, asset management is separated from the tokenized vehicle. As part of your fund migration, you do not need to exit positions or plan for asset migrations. Your existing portfolio can be onboarded as-is. {% endhint %} ### Prerequisites Before initiating a migration, confirm all of the following conditions are satisfied. These apply to both on-chain and off-chain fund structures. | Prerequisite | Requirement | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Clean NAV | All fees, accrued liabilities, and pending expenses must be fully settled and claimed. The fund must hold only assets, no outstanding liabilities. | | Register | A complete and accurate register of investors is required, including each investor's wallet address and number of shares held. | | Portfolio valuation | The fund manager must be able to produce a total net asset value (NAV) figure for the portfolio at the time of migration. | ### Migration steps The migration is executed sequentially by the fund manager across five phases.
1. **Settle and claim all fees** Prior to any asset movement, all outstanding fees, management charges, performance allocations, and other liabilities must be settled and claimed within the existing fund structure. Upon completion, the fund's balance sheet should reflect a net asset position with no residual payables, ensuring the migrated NAV is a clean, unencumbered figure. 2. **Calculate total portfolio NAV** Calculate the total fair market value of all assets under management at the time of migration. This aggregate NAV will serve as the reference value for share issuance in the new Onyx vault and should be consistent with the fund's existing valuation methodology. 3. **Compile the investor register** Prepare a complete and verified list of all investors. For each investor, the following data points are required: * Wallet address * Number of shares currently held This register will be used to replicate the existing ownership structure in the new vault, preserving each investor's proportionate economic interest. 4. **Enzyme deploys the new vault** Enzyme deploys the Onyx vault using the configuration data provided by the fund manager. In addition to the standard vault parameters, the following inputs are required: * Total portfolio NAV (as of the migration date) * Register (wallet addresses and share quantities) 5. **New shares will be minted and transferred to the investors automatically** At vault deployment, Enzyme can trigger an initial share issuance without any prior deposits. {% hint style="info" %} **In practice for your investors :** \ \ \- They retain their existing shares in the legacy fund structure following the migration. However, as all assets will have been transferred to the new Onyx vault, those legacy shares will carry no residual economic value post-migration\ \ \- They receive shares in the new Enzyme Onyx vault, reflecting the same proportionate economic interest they held in the legacy fund. The allocation is derived directly from the register compiled in step 3 and the total NAV established in step 2.\ \ \- They won’t need to redeem from the old fund and subscribe to the new one. \ Once the vault is deployed, Enzyme will no longer be able to trigger any new share issuance. Issuance moving forward will always be linked to deposits. {% endhint %} # Onboarding Guide Congratulations on joining Onyx and taking a meaningful step toward modern, on-chain finance! Here are the first steps to take to gain full control of your vault and access all administrative features. {% stepper %} {% step %} ### Log into the Onyx Administration App We have created an account for you and your team in the Onyx manager app. Open the Onyx Manager app here: {% endstep %} {% step %} ### Accept ownership of the vault To finalize the setup of your new vault, you’ll need to accept the ownership. Go to your vault in the Manager App, connect your vault owner wallet, and click **“Accept Ownership”** in the banner at the top of the page. Accepting the Ownership is an on-chain transaction. {% endstep %} {% step %} ### Vault setting verification Before deploying your strategy, please ensure that all vault settings are properly setup {% endstep %} {% step %} ### Create your first vault collection Follow our tips[ HERE](/onyx-user-documentation/administration-app/editor/create-a-collection). {% endstep %} {% endstepper %} You’re now ready to start using **Enzyme Onyx**. To dive deeper: → Explore the **Administration App** features [HERE](/onyx-user-documentation/administration-app/images-and-media).\ → Learn more about your **investor journey** [HERE](/onyx-user-documentation/investor-interface/overview). # Risks ### Smart Contract Risk When interacting with any smart-contract protocol, there is always some degree of risk that an edge case or code vulnerability can result in funds being lost. We take security very seriously and have extensively engaged multiple auditors across every release of new code, and maintain a comprehensive unit and integration testing suite. It’s important to note that despite these precautions, there is still a risk that some edge case or bug exists which could result in user funds being lost. You can review the latest audit report [here](https://audit.enzyme.finance/). # Portofolio Automation - 31Third Onyx enables asset managers to deploy strategies with full flexibility across both on-chain and off-chain asset classes. **That flexibility is now enhanced with native automation.** Managers can program and execute automated portfolio strategies directly on-chain through 31Third’s execution infrastructure — with no custom development required. This integration allows Safe-controlled vaults to define allocation rules and trigger portfolio actions autonomously. Managers can set target weights, rebalance across multiple assets in a single transaction, and execute basket trades efficiently — all within their existing Onyx structure. Rather than placing trades individually, strategies can now rely on predefined logic that adjusts positions based on allocation drift or threshold conditions. For tokenized fund operators, this unlocks: * Strategy logic configured off-chain * Automated rebalancing across digital asset baskets * Efficient multi-asset execution * Streamlined portfolio management within Safe controls * Reduced execution overhead for systematic strategies
**No Custom Development Required** Deploying automated rebalancing is straightforward: 1. Create a Safe 2. Connect to 31Third Automation : 3. Configure assets and target allocations 4. Deploy the Safe module 5. Execution runs automatically
**Note:** Rebalancing automation is currently available on Base and can be extended to other EVM networks upon request. # Onyx Overview Onyx (by Enzyme Protocol) is a set of EVM-compatible smart contracts to tokenize on- and off-chain value. The purpose of this document is to provide a high-level overview of the aims, architecture, governance, and idiosyncrasies. What it does: * creates an ERC20 tokenized representation of shares * supports arbitrary deposit and redeem mechanisms, e.g., async queues * supports customizable fees * supports customizable tracking of credits and debts What it does NOT do: * monitor, track, or restrict what actually happens with the tokenized value i.e., the on-chain component of Onyx is only concerned with Shares on/off-boarding, fees, and misc accounting; not asset management itself. ### Example FooBar has wallets spread across Arbitrum, Ethereum, and Solana, and holds US Treasuries off-chain. FooBar deploys "FBAR" shares on Arbitrum via Onyx. They add a management and performance fee. They add an async deposit requestor and a first-come, first-served redeem queue.\ \ FooBar adds a line-item expense of $12,000 for an account administrator, to be written-down linearly over 12 months.\ \ After 1 month, FooBar's administrator totals the value of all asset holdings across all on- and off-chain accounts, and posts the total value of holdings. The linear debt simulates a $1,200 (10%) write-down, and then fees are run against the net value. The final NAV share value is stored on-chain. In the meantime, depositors and redeemers have made requests to their respective deposit and redeem handlers. An administrator executes all requests at the lastest NAV share value. # Contract Addresses ## Deployment Files The contract addresses are maintained in the source code deployment files. Click the links below to view the current addresses for each network: ### Ethereum Mainnet (Chain ID: 1) 📄 [**View Ethereum deployment →**](https://github.com/enzymefinance/onyx-sdk/blob/main/packages/environment/src/deployments/ethereum.ts) ### Arbitrum (Chain ID: 42161) 📄 [**View Arbitrum deployment →**](https://github.com/enzymefinance/onyx-sdk/blob/main/packages/environment/src/deployments/arbitrum.ts) ### Base (Chain ID: 8453) 📄 [**View Base deployment →**](https://github.com/enzymefinance/onyx-sdk/blob/main/packages/environment/src/deployments/base.ts) ### Plume (Chain ID: 98866) 📄 [**View Plume deployment →**](https://github.com/enzymefinance/onyx-sdk/blob/main/packages/environment/src/deployments/plume.ts) # User roles ## Management ### Owner Each Onyx instance has one owner. The owner must be fully-trusted. The owner can add/remove "admin" users. Owner is generally given permission to perform any "admin" action. Ownership is transferrable. ### Admin An Onyx instance can have multiple admins, set by the Owner. Each admin must be fully-trusted. Admins can generally perform any administrative action, other than, e.g., adding/removing admins. Admin role is non-transferrable. ### Limited admin roles To synthetically create scoped trust-throttled roles, peripheral contracts can be added as "admin" that define their own rules for allowed callers and callees. ## Shares holders By default, any account can deposit for, redeem, and transfer Shares, which are ERC20 representations of value held across on- and off-chain accounts. Share holders can be restricted by admins (i.e., who can deposit and receive transfers or any other limitation). Trust of share holders may vary depending on specific setups, but generally they are treated as untrusted. # Architecture Overview The Onyx Protocol implements a highly modular architecture designed for creating bespoke tokenized value vaults. ## Contracts Layout Though modular, all vaults sit within a common core architecture consisting of four types of contracts: ### 1. Shares `Shares` is the central contract for an Onyx instance. It is an ERC20 tokenized representation of all portfolio holdings and a registry of settings, rules, and roles for the rest of the system. ### 2. Components Components are specialized contracts that provide modular functionality to individual `Shares` deployments. Each component is: * Uniquely deployed for a single `Shares` contract * Focused on a specific domain (fees, valuation, issuance, etc.) * Replaceable and upgradeable independently * Can be nested within other components (e.g., a PerformanceFee can be a component of a FeeManager) ### 3. Global settings and factories `Global` is the top-level, shared contract that contains common settings for Onyx. e.g., it defines the global "owner" role, which is used primarily for access-control of proxy upgrades Factories are used to deploy `Shares` and its components. ### 4. Shared Infrastructure There are also specialized contracts that do not relate to a specific Onyx instance. Such common infrastructural contracts may also be used by Shares and its Components. e.g., price conversion oracles ## Architecture Diagram {% @mermaid/diagram content=" graph TB %% Styling classDef global fill:#e1f5fe,stroke:#01579b,stroke-width:3px classDef shares fill:#f3e5f5,stroke:#4a148c,stroke-width:2px classDef component fill:#fff3e0,stroke:#e65100,stroke-width:2px classDef factory fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px classDef infra fill:#fce4ec,stroke:#880e4f,stroke-width:2px ``` %% Global Layer Global[Global]:::global %% Infrastructure subgraph Infrastructure[Shared Infrastructure] Oracle1[Oracle]:::infra Oracle2[Oracle]:::infra end %% Factories subgraph Factories[Factory System] SharesFactory[Shares Factory]:::factory ComponentFactories[Component Factories]:::factory end %% Fund Instance subgraph Fund1[Vault Instance 1] Shares1[Shares]:::shares subgraph Components1[Attached Components] Val1[Valuation Manager]:::component Fee1[Fee Manager]:::component Dep1[RFQ Deposit Handler]:::component Red1[In-Kind Redeem Handler]:::component end end %% Fund Instance 2 subgraph Fund2[Vault Instance 2] Shares2[Shares]:::shares subgraph Components2[Attached Components] Val2[Valuation Manager]:::component Fee2[Fee Manager]:::component Queue2[Deposit/Redeem Queue]:::component end end %% Relationships Global --> Factories Global --> Infrastructure SharesFactory --> Shares1 SharesFactory --> Shares2 ComponentFactories --> Components1 ComponentFactories --> Components2 Shares1 -.->|manages| Components1 Shares2 -.->|manages| Components2 Components1 -.->|may use| Infrastructure Components2 -.->|may use| Infrastructure" %} ``` # Shares and Components ## Shares `Shares` is the central contract for an Onyx instance. It is: * an ERC20 tokenized representation of all portfolio holdings * a registry of the "value asset" (e.g., "USD") used for all reporting (e.g., share value) * a registry of roles (owner and admins) * a registry of primary "components" (e.g., handlers for fees, valuation, deposits, redemptions) * a safe for ERC20 token flows for deposits, redemptions, and fees There is one `Shares` contract per Onyx instance. ## Components "Components" are contracts that are associated with a specific `Shares` deployment, and can be thought of as belonging to that instance. ### Structure The only requirement of all components is that they are proxies that implement `IComponentProxy`. This interface provides a `.SHARES()` getter to query which `Shares` instance it belongs to. Most component implementation contracts inherit a `ComponentsHelpersMixin` to assist with parsing common values from its proxy's associated Shares instance. Note: All components know which Shares they are *meant* to belong to (though there is no on-chain validation of this when admins set components) ### Core Components (set on \`Shares\`) #### \`IValueHandler\` `IValueHandler` is responsible for value-related reporting and conversions. For example: * calculate, store, and report share price * convert the "value asset" to/from other assets (e.g., quoting share price in different assets) There is one `IValueHandler` contract per Onyx instance. #### \`IFeeHandler\` `IFeeHandler` is responsible for tracking and settling any fees. There is one `IFeeHandler` contract per Onyx instance. #### \`ISharesTransferValidator\` `ISharesTransferValidator` is responsible for validating that a specific transfer of Onyx shares is allowed (to whom, from whom, for what amount). To allow all transfers: leave unset (i.e., `address(0)`) To disallow all transfers: set to any arbitrary address that does not have the required callback, e.g., `address(1)`` ` There is one `ISharesTransferValidator` contract per Onyx instance. #### Deposit Handlers Deposit handlers are accounts that are allowed to perform actions related to deposits, e.g., minting shares and triggering entrance fee settlement. Deposit handlers can be EOAs or Component contracts. There can be multiple per Onyx instance. #### Redeem Handlers Redeem handlers are accounts that are allowed to perform actions related to redemptions, e.g., burning shares, withdrawing assets, and triggering exit fee settlement. Redeem handlers can be EOAs or Component contracts. There can be multiple per Onyx instance. # Deployments and Upgrades Currently, all contracts are deployed as upgradable proxies. `Shares` and all Components are deployed via factories as beacon proxy instances. Shared infrastructural contracts are deployed as transparent proxies. All proxies are upgradable by the global owner (set on `Global`). Note: there are no hard requirements for upgradability, and it is possible for Onyx instances to use their own upgrade mechanism or immutable contracts. # Share Value ## Core Concepts The Onyx valuation system is designed to aggregate diverse **positions** into a single **value**. ### Positions **Positions** are totally arbitrary and can be: * on-chain (e.g., ERC20 tokens, NFT, RWA) * off-chain (e.g., bank account balance, real estate appraisal) * cross-chain * on EVM chain or non-EVM chain * debts (e.g., pro-rata management costs) * credits (e.g., pro-rata rewards) ### Value **Value** is ALWAYS quoted: * in the "**value asset**" (e.g., "USD") set in `Shares` * with 18-decimal precision (e.g., 1e18 = $1) ### Share Value vs Share Price The system distinguishes between two related but different concepts: **Share Value**: The **net value per share**, inclusive of all positions and fees **Share Price**: The issuance rate for deposits and redemptions, which may include premiums, discounts, or other repricing behavior Generally, **share value** and **share price** are the same, except where value is 0, in which case price defaults to one unit of the value asset (i.e., `1e18`). ### Timestamps **Share value** and **share price** include a timestamp indicating when the calculation was performed. It is then the responsibility of consumers to assess the staleness of the timestamp. ## Share Value Calculations Value calculations are handled by `ValuationHandler`. There are three categories of value that are aggregated: 1. **Tracked positions**: holdings or liabilities that are explicitly added to `ValueInterpreter` via `IPositionTracker` instances. These are automatically reported during share value updates. 2. **Untracked positions**: any holdings or liabilities not added as (1). These are self-reported during share value updates. 3. **Unclaimed fees**: any fees that have been assessed but not transferred to the recipient ### Basic formula value = tracked positions + untracked positions - unclaimed fees share value = value / total shares ## Share Value Update Flow See [Share Value Update](/onyx-protocol/general-flows/share-value-update) # Fees Onyx is designed to flexibly handle bespoke fee structures. The current standard `FeeHandler` implementation described below may be expanded to facilitate further use cases. ## Configuration ### Fee types The current `FeeManager` implementation supports four fees: * management fee (custom logic) * performance fee (custom logic) * entrance fee (flat %) * exit fee (flat %) All values are updatable. ### Fee recipients Each fee can be directed to any arbitrary **fee recipient**. If no fee recipient is set for entrance or exit fee (i.e., `address(0)`), the fee will be burned, effectively distributing the fee pro-rata to all share holders. All fee recipients are updatable. ### Fee asset All fees are distributed in the **fee asset** (e.g. USDC) set on `FeeManager`. Fee asset is updatable. ## Settlement Management fee and performance fee are *always* settled during the [share value update](/onyx-protocol/general-flows/share-value-update) flow. Management fee is settled prior to performance fee, so that performance fee takes into account the settled management fee. Entrance and exit fees *can* be settled during deposit and redeem flows (the deposit/redeem handler decides whether to invoke the fee). ### Tracking owed fees Settled fees are not immediately distributed, but are tracked as debts, which are asynchronously distributed at a later time. Fee debts are stored per user, quoted in the [**value asset**](/onyx-protocol/architecture/share-value#value) (rather than the **fee asset**). ## Distribution Fees are distributed in the **fee asset** set on `FeeManager`. Owed fees are converted from the **value asset** to an amount of the **fee asset** at the time of distribution, using the **asset rate** provided by `ValuationHandler`. There must be enough **fee asset** available in `Shares` . If there is not, then an external wallet must transfer the shortfall to `Shares`. Distribution is triggered: * per user * at any time * by an `admin` ## Fee Settlement and Distribution Flows See [Fee Settlement](/onyx-protocol/general-flows/fee-settlement) ## **Important notes for management and performance fees** * If migrating value and shares to Onyx from another vehicle, do not add any fees until: 1. all Onyx shares have been minted 2. share value has been set in `ValuationHandler` * Updating individual fee config (e.g., a rate) does not automatically settle fees since the previous settlement. The latest config will always be used during settlements. If desired, settle fees using the previous config prior to updating. # Deposit and Redeem Shares issuance (minting and burning in exchange for assets) is performed by **deposit handlers** and **redeem handlers**. ## Handler Requirements An Onyx instance can have multiple **deposit handlers** and **redeem handlers**, each of which can act according to its own custom logic.\ \ **Deposit handlers** and **redeem handlers** do not need to be contracts; an EOA can also be given the handler role. ## Async Deposit and Redeem Handlers Though not a requirement, most deposit and redeem handler contracts will be **async**; they work in a multi-step process whereby: 1. Investors submit requests to a deposit/redeem handler 2. An admin executes these requests 3. The shares/assets resulting from the execution are made available to the investor # Compliance Onyx vaults can enforce on-chain compliance through the [Chainlink Automated Compliance Engine (ACE)](https://docs.chain.link/ace). When enabled, compliance-relevant actions — shares transfers, deposits, redemptions, and direct mints and burns — are checked against a set of policies before they take effect. Any action that a policy rejects reverts, so it never happens. Compliance gating is opt-in and configured per vault. A vault with no validators attached performs no ACE checks; a vault can also gate only a subset of actions, leaving the others ungated. #### How Validation Works Every gated action follows the same pattern. The contract that owns the action — an issuance handler, or the Shares contract itself for transfers — calls a dedicated validator before (or, for some actions, immediately after) committing the action. The validator forwards the check to its attached policy engine. The engine looks up the extractor registered for that action, which decodes the action's details from the call data, and then evaluates its ordered chain of policies against those details. If every check passes, execution continues; if any policy rejects, the entire transaction reverts and the action does not happen. If the chain produces no explicit result, the engine's configured default (allow or reject) applies. ```mermaid sequenceDiagram participant Caller participant Component as Handler or Shares participant Validator participant Engine as Policy Engine participant Extractor participant Policy as Policies Caller->>Component: action (transfer, deposit request, mint, ...) Component->>Validator: validate action Validator->>Engine: run policy check Engine->>Extractor: extract action details from call data Extractor-->>Engine: decoded details loop ordered policy chain Engine->>Policy: evaluate Policy-->>Engine: allow / reject end alt all policies allow Engine-->>Validator: allowed Validator-->>Component: continue Note over Component: action proceeds else any policy rejects Note over Caller,Policy: transaction reverts and the action does not happen end ``` Each gated action has its own validator. An issuance validator is bound to exactly one handler and only accepts calls from it, and the shares transfer validator only accepts calls from the Shares contract. Each validator carries its own policy engine attachment, so different actions can be pointed at the same engine or at different ones. #### Shares Transfers The Shares contract can be configured with a shares transfer validator. When one is set, every shares transfer — direct transfers and approved third-party transfers alike — is run through the policy engine before the balances move. A rejected transfer reverts. When no validator is set, transfers are unrestricted. #### Deposits and Redemptions The async deposit queue and redeem queue each expose two gating points: * **Before a request is accepted.** When a depositor submits a deposit or redemption request, the request is validated before it is committed to the queue and before any assets or shares are taken from the depositor. A rejection reverts the request transaction, so nothing is escrowed. * **After a request is executed.** When the vault operator executes queued requests, each executed request is validated again in the same transaction, after shares are issued (for deposits) or after the redemption settles. A rejection reverts the execution, undoing the settlement. Because requests are executed in batches, one rejected request reverts the whole batch. The two hooks are independent: a vault can gate only request submission, only execution, or both. Sync deposits have a single gating point: the deposit is validated in the same transaction that settles it, immediately after shares are minted and the deposit assets are transferred. A rejection unwinds the entire deposit atomically — the depositor keeps their assets and no shares are issued. #### Direct Mint and Burn Vaults that mirror off-chain settlement use the mint handler and burn handler to issue and destroy shares directly. Both are gated the same way: each mint or burn is validated before it is committed. When a batch of mints or burns is submitted, a single rejection reverts the whole batch. #### Configuration and Roles Two parties control the two sides of the system: * **The vault admin or owner** controls the Onyx side: setting or unsetting the shares transfer validator on the Shares contract, setting or unsetting each handler's hooks (an empty value disables gating for that action), and replacing the policy engine attached to any validator. * **The policy engine's own administrator** controls the compliance rules themselves: which policies run, their order, the extractors, and the engine's default allow-or-reject behavior. Policies can be added, removed, or reordered on the engine without any change to the vault's contracts. #### Policies Policies are composable rule modules that live in the policy engine, outside of Onyx. What a given vault enforces depends entirely on which policies its engine runs. Illustrative examples of what policies can express — not a statement of what any particular vault has deployed — include: * allowlists or denylists of addresses permitted to transact, * volume caps that limit amounts per transaction or per time window, * a pause policy that temporarily rejects all activity. For the full policy model, the library of prebuilt policies, and guidance on composing them, see the [Chainlink ACE documentation](https://docs.chain.link/ace). # Cross-Chain Deposit and Redeem Onyx supports deposits and redemptions from other chains via [**Chainlink CCIP**](https://docs.chain.link/ccip). Cross-chain support is a transport layer wrapped around the ordinary deposit and redeem flows on the vault's chain: the vault and its issuance components are unaware of cross-chain activity — from their perspective, they are dealing with an ordinary depositor on their own chain. ### Wallets Manager The vault-chain side is coordinated by the **wallets manager** (the `WalletsManager`), a vault component that is the receiver of all incoming CCIP messages. For each message, it deploys the sender's depositor wallet if needed, forwards any bridged tokens to it, and executes the message's instructions through it. It is the only account authorized to operate the depositor wallets, and always on behalf of each wallet's one depositor. ### Depositor Wallets Each (**source chain**, **depositor**) pair gets its own dedicated **depositor wallet** contract on the **vault chain** (the `DepositorWallet`), deployed by the wallets manager the first time a message arrives from that depositor. The depositor wallet acts as the depositor's on-chain representative on the vault chain: * It holds the depositor's bridged assets and shares. * It is the account that the vault's deposit and redeem handlers see as their depositor and request controller. Depositor wallet addresses are deterministic, so a depositor's wallet address can be computed in advance — before it is deployed — and used as a parameter in the instructions of the first message. ### Deposit Flow A cross-chain deposit is a single CCIP message from the source chain, carrying the deposit asset together with instructions for what to do with it: 1. The depositor sends a CCIP message from the source chain, bridging the deposit asset and including instructions (e.g. approve and deposit). 2. On the vault chain, the wallets manager deploys the depositor wallet if it does not yet exist, and forwards the bridged asset to it. 3. The depositor wallet executes the instructions, performing the ordinary vault-chain deposit — either a sync deposit (shares minted immediately) or a request to the async deposit queue (executed later in a batch by an admin). 4. Shares are minted to the depositor wallet, where they remain held on the depositor's behalf. ```mermaid sequenceDiagram participant Depositor as Depositor (source chain) participant Manager as Wallets manager (vault chain) participant Wallet as Depositor wallet (vault chain) participant Vault as Deposit handler + vault Depositor->>Manager: CCIP message (asset + instructions) Manager->>Wallet: deploy (first use) and forward asset Manager->>Wallet: execute instructions Wallet->>Vault: deposit (sync or request) Vault-->>Wallet: shares minted to wallet ``` ### Getting Tokens Back Shares minted on deposit remain in the depositor wallet on the vault chain — they do not need to be bridged, since the wallet holds them on the depositor's behalf and can use them for a later redemption. Assets, on the other hand — after a redemption or a cancellation — are sent back to the depositor on the source chain via CCIP. There are two ways this happens: * **Batched by a keeper**: an admin-authorized keeper triggers the return for many depositor wallets at once (typically right after executing a batch of queued requests), paying the CCIP fees. * **Triggered by the depositor**: the depositor sends a follow-up CCIP message instructing their wallet to return specified tokens. The CCIP fee is deducted from the returned token amount (or paid from a fee token bridged along with the message). The same return leg can carry any token held by the depositor wallet — including shares, though bridging shares to the source chain is not part of the standard flow. ### Redeem Flow A cross-chain redemption reuses the same machinery, but with the token movement reversed: nothing is bridged in — the shares are already in the depositor wallet on the vault chain — and the redeemed assets are bridged out over the return leg: 1. The depositor sends a CCIP message from the source chain carrying only instructions (no tokens). 2. The wallets manager executes the instructions through the depositor wallet, which submits a redeem request to the vault's redeem handler. 3. An admin executes the queued request; the redeemed assets land in the depositor wallet. 4. The assets are sent back to the depositor on the source chain — batched by a keeper or triggered by the depositor, as described above. ```mermaid sequenceDiagram participant Depositor as Depositor (source chain) participant Manager as Wallets manager (vault chain) participant Wallet as Depositor wallet (vault chain) participant Vault as Redeem handler + vault Depositor->>Manager: CCIP message (instructions only) Manager->>Wallet: execute instructions Wallet->>Vault: redeem request (shares) Note over Vault: admin executes queued requests Vault-->>Wallet: redeemed assets to wallet Wallet-->>Depositor: assets returned via CCIP ``` ### Cancellation While a queued deposit or redeem request is still pending, the depositor can cancel it with a follow-up cross-chain message. The refunded tokens land back in their depositor wallet and can be sent back to the source chain within the same message. ### Failure Safety * **Failed instructions**: the token transfer and the instructions are decoupled. If the instructed action fails on arrival (e.g. a misconfigured deposit), the bridged tokens still land safely in the depositor wallet — nothing reverts back to the bridge. The depositor simply sends a follow-up message to retry the action or pull the tokens back. * **Isolation**: each depositor's funds only ever touch their own depositor wallet, so a failure or pending state for one depositor never affects another. ```mermaid sequenceDiagram participant Depositor as Depositor (source chain) participant Manager as Wallets manager (vault chain) participant Wallet as Depositor wallet (vault chain) Depositor->>Manager: CCIP message (asset + instructions) Manager->>Wallet: forward asset Manager--xWallet: instructions fail (asset stays in wallet) Depositor->>Manager: follow-up message (retry / return) Manager->>Wallet: execute follow-up instructions Wallet-->>Depositor: tokens returned via CCIP ``` # Assets All tokens flow through the `Shares` contract, which acts as a safe for tokens that are collected or provisioned for use within the system: * deposit handlers send fulfilled token deposits to `Shares` * redeem handlers withdraw tokens from `Shares` to fulfill redemptions * fee handler withdraws tokens from `Shares` to pay fees To access tokens stored in `Shares`, admins must call `Shares.withdrawAssetTo().` To provide tokens to `Shares` for Onyx use, tokens must be transferred from external wallets to `Shares`. e.g.: * after fulfilling a new batch of deposits `Shares` has a balance of 5 ETH * there are 3,000 USDC in fees owed * there are 3 ETH of redeem requests to fulfill * the shortfall in `Shares` is 3,000 USDC for fees and 2 ETH for redemptions * a manager would transfer these amounts from an asset management wallet to `Shares` **This creates a hard division between asset management holdings (external to Onyx) and shares holdings, where stealing the former via Onyx is impossible.** ## **Asset Flows Diagram** {% @mermaid/diagram content="graph LR Users\[Investor] ``` subgraph Onyx[Onyx Protocol] DH[Deposit Handler] SC[Shares] RH[Redeem Handler] FH[Fee Handler] SPACER2[ ] end AMW[External Wallet] FR[Fee Recipients] Admins[Admins] Users --> DH DH --> SC AMW --> SC Admins -.->|"withdrawAssetTo()" | SC SC -.->|"via withdrawAssetTo()" | AMW SC --> RH SC --> FH RH --> Users FH --> FR style SC fill:#e3f2fd,stroke:#1976d2,stroke-width:3px style AMW fill:#e8f5e8,stroke:#388e3c,stroke-width:2px style SPACER2 fill:transparent,stroke:none" %} ``` # Share Value Update {% @mermaid/diagram content=" sequenceDiagram actor Admin as admin participant VH as ValuationHandler participant PT as Position Trackers participant FM as FeeManager participant S as Shares ``` Admin->>VH: update share value:
- $untrackedPositionsValue VH->>PT: getPositionValue() for each PT-->>VH: trackedPositionsValue VH-->>VH: totalPositionsValue =
$untrackedPositionsValue + trackedPositionsValue VH->>FM: settle dynamic fees (management + performance) Note over FM: see "Fee Settlement" flow VH->>FM: get: total fees owed FM-->>VH: totalFeesOwed VH-->>VH: netPositionsValue = totalPositionsValue - totalFeesOwed VH->>S: get: total supply of shares S-->>VH: shares supply VH-->>VH: netShareValue = netPositionsValue / shares supply VH->>VH: store netShareValue with timestamp" %} ``` # Fee Settlement ## Settlement ### Management and Performance Fees {% @mermaid/diagram content="sequenceDiagram participant VH as ValuationHandler participant FH as FeeHandler participant MFT as ManagementFeeTracker participant PFT as PerformanceFeeTracker ``` Note over VH,FH: During share value update VH->>FH: settle dynamic fees FH->>MFT: settle management fee MFT-->>FH: value owed FH->>FH: increase value owed: management fee recipient FH->>PFT: settle performance fee PFT-->>FH: value owed FH->>FH: increase value owed: performance fee recipient" %} ``` ### Entrance Fee {% @mermaid/diagram content="sequenceDiagram participant DH as DepositHandler participant FH as FeeHandler ``` Note over DH,FH: During deposit DH->>FH: settle entrance fee FH-->>FH: value owed = deposit value * entrance fee % FH->>FH: increase value owed: entrance fee recipient" %} ``` ### Exit Fee {% @mermaid/diagram content="sequenceDiagram participant RH as RedeemHandler participant FH as FeeHandler ``` Note over RH,FH: During redeem RH->>FH: settle exit fee FH-->>FH: value owed = redeem value * exit fee % FH->>FH: increase value owed: exit fee recipient" %} ``` ## Distribution {% @mermaid/diagram content="sequenceDiagram actor Admin as Admin participant FH as FeeHandler participant VH as ValuationHandler participant S as Shares participant FR as Fee Recipient ``` Admin->>FH: distribute:
- $value
- $feeRecipient FH->>FH: decrease value owed to $feeRecipient FH->>VH: convert: $value
to fee asset amount VH-->>VH: fee asset rate VH-->>FH: fee asset amount FH->>S: withdraw fee asset amount to $feeRecipient S->>FR: transfer fee asset tokens" %} ``` # Async Deposit and Redeem Though [deposit and redeem handlers are totally arbitrary](/onyx-protocol/architecture/deposit-and-redeem), most will follow an asynchronous approach with 3 steps: 1. Create request 2. Execute batched requests 3. Distribute shares (deposit) or assets (redeem); can be synchronous with (2) ## Deposit ### Request {% @mermaid/diagram content="sequenceDiagram actor U as Investor participant DQ as DepositHandler participant Asset as ERC20 ``` U->>DQ: request deposit:
- $assetAmount DQ-->>DQ: validate request DQ->>DQ: record request DQ->>Asset: transferFrom() Asset->>DQ: transfer $assetAmount" %} ``` ### Fulfillment {% @mermaid/diagram content="sequenceDiagram actor Admin as Admin participant DQ as DepositHandler participant VH as ValuationHandler participant FH as FeeHandler participant Asset as DepositAsset participant S as Shares actor User as Investor ``` Admin->>DQ: execute requests:
- $requests DQ->>VH: get:
- share price
- asset rate VH-->>DQ: share price, asset rate DQ-->>DQ: calculate shares due for $requests DQ-->>DQ: calculate total assets for $requests DQ->>FH: settle entrance fee DQ->>Asset: transfer() Asset->>S: transfer total assets DQ->>S: mint Note over S, User: possibly separate claim step S->>User: transfer shares" %} ``` # Suggested Subscription Rounds There are no built-in rounds/epochs or other procedural requirements for handling deposits, redemptions, and fees, but there is a general procedure that should be followed: 1. Investors submit deposit requests and redeem requests ([flow](/onyx-protocol/general-flows/async-deposit-and-redeem)) 2. Admin calculates requests to fulfill and triggers share value update 1. update all asset rates via `ValuationHandler` 2. update share value via `ValuationHandler` ([flow](/onyx-protocol/general-flows/share-value-update)) 3. transfer redeem (and fee) assets shortfall to `Shares` 3. execute deposit requests ([flow](/onyx-protocol/general-flows/async-deposit-and-redeem#fulfillment)) 4. execute redeem requests (flow: see deposit requests) 5. (optional) distribute fees ([flow](/onyx-protocol/general-flows/fee-settlement#distribution)) 6. withdraw assets surplus from `Shares` for asset management # Shares The core-most contract. See [Shares and Components](/onyx-protocol/architecture/shares-and-components) for its roles, configuration, and mechanics. # Fees ## FeeHandler The core contract for registering, settling, and distributing fees. See [Fees](/onyx-protocol/architecture/fees) for the configuration and mechanics. ## Management Fees ### ContinuousFlatRateManagementFeeTracker Uses an annualized rate (e.g., 10%) to apply a time-based fee on net value. Config: * `rate` : annualized fee percentage Setup: 1. Call `setRate(rate)`: sets `rate` 2. Call `resetLastSettled()`: initializes fee with current timestamp Notes: * `resetLastSettled()` can be called at any time to re-initialize fee with current timestamp (e.g., after updating the rate). ## Performance Fees ### ContinuousFlatRatePerformanceFeeTracker Uses a flat rate (e.g., 10%) to apply a performance-based fee on net share value growth. Config: * `rate` : fee percentage applied to share value growth Setup: 1. Call `setRate(rate)`: sets `rate` 2. Call `resetHighWaterMark()`: initializes fee with current share price as the HWM Fee Mechanics: * If `currentNetShareValue > HWM`, then: * the fee is settled as: `fee = rate * valueIncreasePerShare * numberOfShares` * HWM is updated * Performance is *only* charged on value increase above the HWM Notes: * `resetHighWaterMark()` can be called at any time to re-initialize fee with the current share price as HWM (e.g., to have granular performance periods). * Due to the fee mechanics, to the extent and duration that `currentNetShareValue < HWM`, investors have a "free ride". # Issuance ## ERC7540LikeDepositQueue Ordered queue for handling async deposits of a specific asset for shares. Partially compatible with ERC-7540. Config: * `asset` : the ERC20 token deposited in exchange for shares * `minRequestDuration` : minimum time before a request is cancellable * `depositRestriction` : deposit request restriction * `None` : no restrictions * `ControllerAllowlist` : in-contract allowlist for depositors Usage: * depositors create requests for specific amounts of `asset` * `asset` amounts for pending requests are escrowed in the queue contract * admins selectively execute requests; shares are minted to depositors, `asset` amounts of executed requests are moved to `Shares` Notes: * Charges entrance fee, if set on `FeeHandler` * Request execution order and timing is at the discretion of admins * Whether or not to execute specific requests is at the discretion of admins ## ERC7540LikeRedeemQueue Ordered queue for handling async redemptions of shares for a specific asset. Partially compatible with ERC-7540. Config: * `asset` : the ERC20 token withdrawn in exchange for shares * `minRequestDuration` : minimum time before a request is cancellable Usage: * redeemers create requests for specific amounts of shares * shares amounts for pending requests are escrowed in the queue contract * admins selectively execute requests; shares are burned from escrow, `asset` amounts are distributed to redeemers Notes: * Charges exit fee, if set on `FeeHandler` * Request execution order and timing is at the discretion of admins * Whether or not to execute specific requests is at the discretion of admins # Value ## ValuationHandler The core contract for value calculations and conversions. See [Share Value](/onyx-protocol/architecture/share-value) for the mechanics of share value updates. Config: * `positionTrackers`: instances of `IPositionTracker` that are called during share value updates to aggregate value that is tracked on-chain * "**asset rates**": rates of each asset used within the system (deposits, redemptions, fees), quoted in the [Shares value asset](/onyx-protocol/contract-implementations/value) Notes: * **asset rates** must always be updated prior to updating share value, as the latter uses the former in its calculations * for a constant **asset rate** (e.g., 1 USDC = $1), expiry can be set to the max value, leaving no need for future updates ## Position Trackers ### AccountERC20Tracker Tracks and returns the value of specified ERC20 tokens held by a specific account. Config: * `account`: The account for which to report the value of held `assets` * `assets`: The ERC20 tokens to report ### LinearCreditDebtTracker Tracks and returns the value of arbitrary line-items representing debts and/or credits, which can be written-down linearly over any durations. # Risks and Limitations This is not an exhaustive list, but details key risks (with possible mitigations) and limitations of core architecture. ## Hack ***core mitigation:*** the only assets that Onyx has access to are the assets held inside its contracts: pending async deposits, unclaimed provisioned fees, unexecuted provisioned redemptions. Asset management wallets are never directly pulled from (assets must always be externally transferred into Shares for use). This creates a full partition between Onyx and any number of asset management wallets themselves, leaving no opportunity attackers to steal from non-pending holdings. ## Trusted Roles ### risk:`owner` and `admin` are fully-trusted See [User roles](/onyx-protocol/user-roles). They can, e.g., * inflate/deflate shares supply * set arbitrary share prices * withdraw all ERC20 tokens held in Shares ***user mitigation example:** instead of an EOA admin, use a smart contract that limits allowed calls* ***core mitigation**: see* [#hack](#hack "mention") mitigation ## System ### risk: tiny shares supply (e.g., donation attacks) Rather than apply a core mitigating pattern, this is left to individual Onyx instances. ***user mitigation example:** an `admin` can mint "existential shares" to an unaccessible address* ***user mitigation example:** an `admin` must not execute deposit/redeem requests for tiny shares amounts* ### limitation: irregular ERC20 token behaviors Contracts are not intended to handle irregular token behaviors such as: * fee-on-transfer * rebasing * re-enterable callbacks # Bug Bounty ## Bug Bounty Program The bug bounty program is hosted on [Immunefi](https://immunefi.com/bug-bounty/enzyme-onyx). All submissions must follow Immuenfi and program rules. # Overview This section covers the tools available for building custom interfaces and integrations on Enzyme Onyx. * [**SDK**](/onyx-sdk/sdk) - TypeScript library for interacting with Onyx smart contracts (deposits, redemptions, approvals, vault management) * [**API**](https://api.onyx.enzyme.finance/reference) - Public read-only REST API for vault data, financials, and deposits (no authentication required) * [**FAQ**](/onyx-sdk/faq) - Common questions about SDK and API usage, troubleshooting, and integration patterns ## Support If you encounter issues or have questions: 1. Check the [GitHub Issues](https://github.com/enzymefinance/onyx-sdk/issues) 2. Start a [Discussion on GitHub](https://github.com/enzymefinance/onyx-sdk/discussions) # SDK The Onyx SDK is a TypeScript library for interacting with the Enzyme Onyx protocol - an Ethereum-based platform for decentralized on-chain asset management. This SDK provides tools for building depositor-facing interfaces and vault administration applications. ## Installation Install the Onyx SDK and its peer dependencies using your preferred package manager: ```bash pnpm add @enzymefinance/onyx-sdk pnpm add @enzymefinance/onyx-environment @enzymefinance/onyx-abis viem ``` > **Note**: `@enzymefinance/onyx-environment`, `@enzymefinance/onyx-abis`, and `viem` are peer dependencies that must be installed alongside the main SDK package. ## Prerequisites * Node.js 18 or later * TypeScript 5.0 or later * Basic understanding of Ethereum and smart contracts * Familiarity with [Viem](https://viem.sh) (the underlying Ethereum client library) ## Supported Networks The Onyx SDK supports the following networks: * **Ethereum Mainnet** (Chain ID: 1) * **Arbitrum** (Chain ID: 42161) * **Base** (Chain ID: 8453) * **Plume** (Chain ID: 98866) For deployed contract addresses on each network, see [Contract Addresses](https://docs.enzyme.finance/onyx-protocol/contract-addresses). ## Quick Start Set up a Viem client to interact with the blockchain: ```typescript import { createPublicClient, createWalletClient, http, parseEventLogs } from "viem"; import { mainnet } from "viem/chains"; import { privateKeyToAccount } from "viem/accounts"; // Public client for reading data const publicClient = createPublicClient({ chain: mainnet, transport: http(), }); // Wallet client for sending transactions const account = privateKeyToAccount("0x..."); const walletClient = createWalletClient({ account, chain: mainnet, transport: http(), }); ``` ## Depositor Actions These are the primary actions for building depositor-facing interfaces (subscriptions and redemptions). > **Note**: The addresses required below (deposit queue, redeem queue, shares contract) can be retrieved from the [Onyx API](https://api.onyx.enzyme.finance/reference) or your vault's configuration. Similarly, after submitting a deposit or redemption request, you can retrieve your request ID either by parsing the transaction receipt events (shown below) or by querying the API for your pending requests. > > **Controller vs Owner**: In deposit/redeem requests, `controller` is the address authorized to cancel the request, while `owner` is the address that will receive the shares (for deposits) or redeemed assets (for redemptions). These can be the same address. ### Approve Tokens Before depositing, approve the deposit queue to spend your tokens: ```typescript import * as Asset from "@enzymefinance/onyx-sdk/Asset"; // Check current allowance const allowance = await Asset.getAllowance(publicClient, { asset: "0x...", // Token address (e.g., USDC) owner: "0x...", // Depositor address spender: "0x...", // Deposit queue address }); // Approve if needed const approveTransaction = Asset.approve({ asset: "0x...", spender: "0x...", // Deposit queue address amount: 1000000n, // Amount to approve }); const hash = await walletClient.writeContract(approveTransaction); // Wait for approval to be confirmed before depositing await publicClient.waitForTransactionReceipt({ hash }); ``` ### Request Deposit Submit a deposit request to the queue: ```typescript import * as Components from "@enzymefinance/onyx-sdk/Components"; import { ERC7540LikeDepositQueueAbi } from "@enzymefinance/onyx-abis"; const depositTransaction = Components.ERC7540LikeDepositQueue.requestDeposit({ queueAddress: "0x...", // Deposit queue address amount: 1000000n, // Amount to deposit controller: "0x...", // Address that can cancel the request owner: "0x...", // Address that will receive shares }); const hash = await walletClient.writeContract(depositTransaction); // Get the request ID from the transaction receipt const receipt = await publicClient.waitForTransactionReceipt({ hash }); const logs = parseEventLogs({ abi: ERC7540LikeDepositQueueAbi, logs: receipt.logs, eventName: "DepositRequest", }); if (logs.length === 0) { throw new Error("DepositRequest event not found"); } const requestId = logs[0].args.requestId; ``` ### Cancel Deposit Cancel a pending deposit request. > **Note**: A pending deposit request can only be cancelled after the queue's minimum request duration has elapsed. The contract stores a `canCancelTime` for each request; calling `cancelDeposit` before that time reverts with `MinRequestDurationNotElapsed`. Check whether a request is cancellable by fetching it with `getDepositRequest` and comparing `canCancelTime` to the current block timestamp. ```typescript const cancelTransaction = Components.ERC7540LikeDepositQueue.cancelDeposit({ queueAddress: "0x...", requestId: 1n, // ID of the deposit request }); const hash = await walletClient.writeContract(cancelTransaction); ``` ### Check Deposit Status Query the status of a deposit request: ```typescript const depositRequest = await Components.ERC7540LikeDepositQueue.getDepositRequest( publicClient, { queueAddress: "0x...", requestId: 1n, }, ); ``` ### Request Redemption Submit a redemption request: ```typescript import { ERC7540LikeRedeemQueueAbi } from "@enzymefinance/onyx-abis"; const redeemTransaction = Components.ERC7540LikeRedeemQueue.requestRedeem({ queueAddress: "0x...", // Redeem queue address amount: 1000000000000000000n, // Amount of shares to redeem controller: "0x...", // Address that can cancel the request owner: "0x...", // Address that will receive the redeemed assets }); const hash = await walletClient.writeContract(redeemTransaction); // Get the request ID from the transaction receipt const receipt = await publicClient.waitForTransactionReceipt({ hash }); const logs = parseEventLogs({ abi: ERC7540LikeRedeemQueueAbi, logs: receipt.logs, eventName: "RedeemRequest", }); if (logs.length === 0) { throw new Error("RedeemRequest event not found"); } const requestId = logs[0].args.requestId; ``` ### Cancel Redemption Cancel a pending redemption request. > **Note**: A pending redemption request can only be cancelled after the queue's minimum request duration has elapsed. The contract stores a `canCancelTime` for each request; calling `cancelRedeem` before that time reverts with `MinRequestDurationNotElapsed`. Check whether a request is cancellable by fetching it with `getRedeemRequest` and comparing `canCancelTime` to the current block timestamp. ```typescript const cancelTransaction = Components.ERC7540LikeRedeemQueue.cancelRedeem({ queueAddress: "0x...", requestId: 1n, }); const hash = await walletClient.writeContract(cancelTransaction); ``` ### Check Redemption Status Query the status of a redemption request: ```typescript const redeemRequest = await Components.ERC7540LikeRedeemQueue.getRedeemRequest( publicClient, { queueAddress: "0x...", requestId: 1n, }, ); ``` ### Read Share Balance and Price Query fund share information: ```typescript import * as Shares from "@enzymefinance/onyx-sdk/Shares"; // Get user's share balance const balance = await Asset.getBalanceOf(publicClient, { owner: "0x...", // User address asset: "0x...", // Shares contract address }); // Get current share price const sharePrice = await Shares.sharePrice(publicClient, { sharesAddress: "0x...", // Shares contract address }); // Get total supply const totalSupply = await Asset.getTotalSupply(publicClient, { asset: "0x...", // Shares contract address }); ``` ## Admin Actions These actions are for vault admins to configure and administer funds. ### Get Network Environment Use the environment package to get deployment addresses and configurations: ```typescript import { Network, getEnvironmentGroup, Deployment, } from "@enzymefinance/onyx-environment"; // Get the environment for Ethereum mainnet const environmentGroup = getEnvironmentGroup(Deployment.ETHEREUM); const environment = environmentGroup.getEnvironment(); // Access deployed contract addresses const globalAddress = environment.contracts.global.address; ``` ### Execute Deposit Requests Process pending deposit requests: ```typescript const executeTransaction = Components.ERC7540LikeDepositQueue.executeDepositRequests({ queueAddress: "0x...", requestIds: [1n, 2n, 3n], // IDs of requests to execute }); const hash = await walletClient.writeContract(executeTransaction); ``` ### Execute Redemption Requests Process pending redemption requests: ```typescript const executeTransaction = Components.ERC7540LikeRedeemQueue.executeRedeemRequests({ queueAddress: "0x...", requestIds: [1n, 2n], }); const hash = await walletClient.writeContract(executeTransaction); ``` ### Configure Fees Set up fund fees: ```typescript // Set entrance fee const entranceFeeTransaction = Components.FeeHandler.setEntranceFee({ feeHandlerAddress: "0x...", feeBps: 50, // 0.5% recipient: "0x...", }); // Set management fee rate const managementFeeTransaction = Components.ContinuousFlatRateManagementFeeTracker.setRate({ tracker: "0x...", feeBps: 200, // 2% annual }); // Set performance fee rate const performanceFeeTransaction = Components.ContinuousFlatRatePerformanceFeeTracker.setRate({ tracker: "0x...", feeBps: 2000, // 20% }); ``` ### Manage Deposit Allowlist Control who can deposit: ```typescript // Add address to allowlist const addTransaction = Components.ERC7540LikeDepositQueue.addAllowedController({ queueAddress: "0x...", allowedControllerAddress: "0x...", }); // Remove address from allowlist const removeTransaction = Components.ERC7540LikeDepositQueue.removeAllowedController({ queueAddress: "0x...", allowedControllerAddress: "0x...", }); // Set deposit restriction mode const { DepositRestriction } = Components.ERC7540LikeDepositQueue; const restrictionTransaction = Components.ERC7540LikeDepositQueue.setDepositRestriction({ queueAddress: "0x...", depositRestriction: DepositRestriction.ControllerAllowlist, // or DepositRestriction.None }); ``` ### Update Valuations Update asset prices and share value: ```typescript const updateTransaction = Components.ValuationHandler.setAssetRatesThenUpdateShareValue({ valuationHandlerAddress: "0x...", assetRateInput: [ { asset: "0x...", // Asset address rate: 1000000n, // Price in value asset terms expiry: Math.floor(Date.now() / 1000) + 3600, // Rate expiry timestamp }, ], untrackedPositionsValue: 0n, // Value of any untracked positions }); const hash = await walletClient.writeContract(updateTransaction); ``` ## TypeScript Support The SDK is built with TypeScript and provides full type safety: ```typescript import type { Address } from "viem"; import * as Asset from "@enzymefinance/onyx-sdk/Asset"; import * as Components from "@enzymefinance/onyx-sdk/Components"; // All addresses are typed const asset: Address = "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"; const owner: Address = "0x..."; // Function parameters are fully typed const tx = Components.ERC7540LikeDepositQueue.requestDeposit({ queueAddress: "0x..." as Address, amount: 1000000n, controller: owner, owner: owner, }); ``` ## Common Patterns ### Transaction Simulation Before sending transactions, simulate them to catch errors: ```typescript const transaction = Asset.approve({ asset: "0x...", spender: "0x...", amount: 1000000n, }); // Simulate first const { result } = await publicClient.simulateContract(transaction); // Then execute const hash = await walletClient.writeContract(transaction); ``` ### Batch Operations Use Promise.all for multiple read operations: ```typescript const [balance, allowance, sharePrice] = await Promise.all([ Asset.getBalanceOf(publicClient, { owner: "0x...", asset: "0x..." }), Asset.getAllowance(publicClient, { owner: "0x...", spender: "0x...", asset: "0x...", }), Shares.sharePrice(publicClient, { sharesAddress: "0x..." }), ]); ``` *** *This SDK is under active development. APIs may change between versions. Always check the changelog before upgrading.* # FAQ Common questions about the Enzyme Onyx SDK and API. *** ## When should I use SDK vs API? | Aspect | API | SDK | | ------------------- | -------------------------------------- | ------------------------------------ | | **Read Data** | Indexed, cached, fast (\~10s cache) | Direct RPC, real-time but slower | | **Write Data** | Not supported | Full transaction support | | **Historical Data** | Time-series financials, past deposits | Current state only | | **Rate Limits** | Per IP (capacity reviewed regularly) | RPC provider limits | | **Authentication** | None required | Wallet signature for writes | | **Use Case** | Dashboards, analytics, read-heavy apps | Deposits, redemptions, admin actions | | **Dependencies** | None (REST/fetch) | viem, wallet provider, RPC | | **Offline Support** | Can cache responses | Requires live RPC | **Recommendation:** Use a hybrid approach: * **API** for reading vault data (metrics, deposits, history) - it's faster and doesn't count against RPC limits * **SDK** for user transactions (deposits, redemptions, approvals) - required for blockchain writes **Example Architecture:** ``` Your App ├── Display vault list → API (GET /vaults) ├── Show vault metrics → API (GET /vaults/{id}) ├── Show user balance → API (GET /vaults/{id}/deposits/{wallet}) ├── Request deposit → SDK (Components.ERC7540LikeDepositQueue.requestDeposit) └── Approve tokens → SDK (Asset.approve) ``` *** ## What networks are supported? | Network | Chain ID | | ---------------- | -------- | | Ethereum Mainnet | 1 | | Arbitrum One | 42161 | | Base | 8453 | | Plume Mainnet | 98866 | *** ## Do I need an API key? **No.** The Onyx Public API requires no authentication. You can start making requests immediately. *** ## What's the rate limit? The API is rate-limited per IP address. Capacity is reviewed regularly. # Frequently Asked Questions New updates and improvements ## General
Are Vault shares transferable? Enzyme Vault Shares are issued **as ERC-20 tokens**, with transferability and parameters configurable by the Vault owner. Vault Owners can configure the Vault Shares to **enable** or **disable transferability**.\ \ *Learn more about Vault Shares and Subscription HERE*
Are Enzyme.Onyx Vaults ERC-4626? **ERC-4626** is a standard for tokenized vaults that defines how deposits, withdrawals, and share accounting should work. It’s designed to make vaults interoperable across protocols. **Why not ERC-4626?** We opted for our own protocol because Enzyme Vaults require greater flexibility than ERC-4626 allows. Our architecture supports complex features—like custom fee logic, multi-asset strategies, advanced permissions, and integrations—that go beyond the scope of the standard. ERC-4626 is a useful baseline for simple yield vaults, but it can’t capture the breadth of tokenized strategies Enzyme enables.
Is it possible to integrate a KYT process into the deposit flow? Enzyme does not enforce KYC (Know Your Customer) or KYB (Know Your Business) at the protocol level. \ \ **However,** Vault Owners and Managers can request to deploy an extra layer, using the service provider of their choice.
Do you provide SDK and API? Yes, Enzyme Onyx provides a full suite of SDK and APIs. See it as a modular architecture, Onyx is designed to accommodate bespoke development and plug-in solutions.
How do funds deposited into the Vault travel towards my Management Wallet?
## Accounting
How is NAV calculated? Vaults deployed with Onyx operate under a non-continuous accounting model.\ \ Vault owners or managers are required to consolidate the valuation of the underlying portfolio and to report it directly as the GAV (Gross Asset Value) into the Onyx ***Administration App,*** which will take care of calculating the NAV an updating the Share price. With Enzyme.Onyx, the valuation method is left open—Vault Owners and Managers can handle it internally, work with their preferred provider, or ask Enzyme for partner recommendations.
Can I connect the Management App to a broker or a platform to streamline NAV computation? Portfolio valuation must consolidate all underlying assets and positions that make up the Vault’s strategy. If relying on a single broker or platform, no direct connection to the Accounting tool of the Management App is available at this time. Vault Owners can consolidate the value of their holdings and positions and simply report them manually into the Management App.
## Subscription
Are investors able to cancel deposit and redemption requests? If yes, what are the conditions? Investors can cancel deposit and redemption requests. The Vault Owner may define a time window after which a depositor is allowed to cancel a request, provided it has not yet been executed.
## Management
Can I delegate Vault management to a third-party provider, and how is control maintained? A Vault Owner can delegate responsibilities at two levels: **Vault** and **Wallet**. * **Vault level** – The Vault Owner can assign roles to Admins and delegate macro-responsibilities such as accounting and subscription management. (See *Management App / Roles*.) * **Wallet level** – The Vault Owner can leverage the ***Management Wallet*** capabilities to delegate strategy execution to a third party. \ *For instance, a Safe-based **Management Wallet** can harness Zodia's role-based access solutions to delegate and control micro-strategy management.*
Can I include traditional securities and commodities in my Vault strategy? Yes. Enzyme.Onyx allows you to tokenize any on-chain or off-chain asset, provided you can reliably assess its value.
Can I move the assets deposited in my Vault to another blockchain? Absolutely. Vault Owners and Admins can withdraw funds from the Vault smart contract into their Management Wallet. Withdrawals occur on the Vault’s native network — bridging is not yet integrated. Once received, managers may bridge the funds externally to the desired chain.(Cf Deposit Flow)
Can I connect my Vault directly to a broker or a platform? Enzyme.Onyx doesn't technically connects to external platforms or brokers. However, they allow seamless transfer of funds towards wallets. What does it mean?
* If the broker or platform provides its own wallet or custody infrastructure, funds can be sent directly there through the deposit flow. * If no such wallet is available, an easy workaround is to withdraw funds to any ***Management Wallet*** and then transfer them to the broker or platform, using off-ramp if needed.
* CONFIRM THIS
## Fees
How do fees payout work? * Management fee and performance fee are *always* settled during the [share value update](https://enzyme-finance.gitbook.io/onyx-general-spec/general-flows/share-value-update) flow. * Entrance and exit fees *can* be settled during deposit and redeem flows (the deposit/redeem handler decides whether to invoke the fee). \ Settled fees are not immediately distributed, but are tracked as debts, which are asynchronously distributed at a later time.
Fees are distributed in the **fee asset.** When necessary, owed fees are converted from the value asset to an amount of the fee asset at the time of distribution.
**Distribution can be triggered at any time by the Vault Owner or Vault Admins.**
Can I establish a programmatic fee collection? Yes. Fee distribution can be programmatically configured to split payments across multiple addresses — *for example, 70% to you and 30% to a delegated manager* — using Payment Splitter contracts.
# What is Enzyme Blue? **Enzyme Blue is the all-around platform to create and manage tokenized products.** Build smarter, innovate faster, manage better. Enzyme.Blue equips industry leaders to embrace decentralized finance at scale, offering a comprehensive environment for streamlined execution, compliance, and analytics. # Architecture All the tools you need in one streamlined environment. **Enzyme.Blue** is your gateway to decentralized finance. Featuring a state-of-the-art integrated app, a comprehensive SDK, and robust APIs, Enzyme Blue enables you to seamlessly deploy and manage Enzyme Vaults and interact with on-chain protocols directly from a single platform. --- [Next Page](/llms-full.txt/1)