> For the complete documentation index, see [llms.txt](https://docs.diversifi.trade/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.diversifi.trade/protocol-risk-methodology.md). # Protocol risk & methodology DeFi products do not only depend on their own code. They depend on every layer they rely on to function: assets, oracles, bridges, wrappers, routing venues, yield sources, backend execution, and admin controls. The real question is not only "is it audited?" It is also: **what does this product depend on, and how far down does that dependency chain go?** This page explains how DiversiFi thinks about that chain for portfolio vaults and dTokens. ## 1. Dependency chains in DeFi A DeFi product is rarely just one system. Losses often propagate from a layer behind the product the user thinks they are using. Examples: * Lending markets depend on oracles and every accepted collateral asset. * Wrapped and bridged assets depend on the issuer, bridge, verification layer, and reserves behind the token. * Liquid staking and restaking tokens depend on the staking layer beneath them, and sometimes on bridges as well. * Derivatives venues depend on oracles, liquidity, and margin engines. * Yield-bearing assets depend on the source that produces the yield. * Vaults and aggregators inherit the dependency chain of every strategy they route into. The failing layer is often not the product the user evaluated. It is a layer behind it. DiversiFi's design goal is to keep the core dependency chain short and inspectable. A standard DiversiFi portfolio vault relies on: * the vault's own smart contracts, * the assets held inside the vault, * the oracles used to price assets, * Jupiter for swap execution, * backend services for the current execution model, * and admin controls for protocol configuration. Capital does not durably leave the vault unless a strategy explicitly includes an external yield-bearing asset. Nothing is lent out, looped, or routed into hidden external strategies by default. Bridges are not part of the core vault design unless a selected asset itself carries bridge exposure. A short dependency chain is not a guarantee. It is simply easier to inspect end to end. ## 2. Protocol and branded strategies DiversiFi has two product layers: 1. **The portfolio protocol** - infrastructure for creating, accounting for, minting, redeeming, and managing portfolio vaults. 2. **DiversiFi-branded strategies** - curated strategies built by DiversiFi on top of the protocol. The protocol can also support user-owned or integration-defined portfolio vaults. In that model, asset selection and portfolio construction may belong to the user or integration, while protocol, execution, backend, admin, and smart contract risks remain DiversiFi infrastructure risks. | Layer | What it means | Main risk implication | | ---------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | Portfolio protocol | Infrastructure for portfolio vaults and dTokens | Protocol, execution, backend, admin, and smart contract risks apply | | DiversiFi-branded strategies | Curated strategies built by DiversiFi | Strategy design and selected asset exposures are DiversiFi product decisions | | User-owned portfolio vaults | Vaults defined by users or integrations | Asset selection may belong to the user or integration, while protocol risks remain infrastructure risks | ## 3. What a DiversiFi portfolio vault is A DiversiFi portfolio vault is a Solana-native portfolio primitive. It packages multiple on-chain assets into one fungible SPL token, called a dToken. Each dToken represents exposure to a portfolio of underlying assets according to predefined rules. A DiversiFi portfolio vault provides: * portfolio exposure represented through a fungible SPL token, * mint and redeem functionality, * on-chain accounting of vault assets, * and automated portfolio management according to the vault's rules. The vault is what generates the position value because it actually holds the underlying assets. DiversiFi's protocol role is to create, account for, rebalance, mint, and redeem portfolio vault positions. External yield-source exposure is introduced only when a strategy deliberately includes tokenized yield-bearing assets. ## 4. What a DiversiFi portfolio vault is not Unless explicitly stated for a specific portfolio vault, a DiversiFi portfolio vault is not: * a lending strategy, * a leveraged yield strategy, * a delta-neutral strategy, * a market-making strategy, * a restaking strategy, * a bridge-dependent yield product, * a discretionary hedge fund, * a product that rehypothecates user assets into hidden external strategies, * or a promise of yield, income, principal protection, or guaranteed return. ## 5. dToken backing and redemption dTokens are backed by the assets held in the corresponding portfolio vault. DiversiFi portfolio vault accounting is designed so that issued dTokens correspond to underlying assets held by the vault. dTokens are redeemable through the protocol without a lockup period, subject to protocol availability, liquidity, execution conditions, and the risks described on this page. DiversiFi does not operate or rely on liquidity pools as the canonical pricing venue for dTokens. The canonical entry and exit route is mint and redemption through the vault itself, priced against the assets the vault actually holds. Any external liquidity pool would be secondary to vault mint/redeem mechanics. ## 6. Current execution model DiversiFi's current minting process is multi-step. A user submits an intent. The protocol records the intent, and the backend picks it up for execution. The backend then executes the required swap and mint operations. Each swap and mint operation is atomic at its own step, but the overall process is multi-step. DiversiFi is actively working on a more atomic execution model, currently targeted for the end of Q3 2026. Until that upgrade is live, users should understand the current execution assumptions. | Question | Current answer | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | Can a swap fail? | Yes. DiversiFi has retry logic. If retries fail, the unswapped portion can be reclaimed by the user. | | Can users cancel? | Not like an off-chain order. Users can withdraw or reclaim unswapped funds if execution does not complete. | | Is there a timeout? | No explicit timeout today. Leftover deposited amounts from missed swaps can be refunded through user-initiated reclaim. | | What protects execution? | Oracle freshness checks before swaps, plus Jupiter-level slippage protection. | ## 7. Backend, keeper, pause, and admin risk DiversiFi is currently backend-dependent. The project intends to migrate toward a keeper network in v2. Until then, users should treat backend dependency and admin control as explicit protocol risks. | Current dependency | Disclosure | | -------------------- | ----------------------------------------------------------------------------------------------------- | | Backend availability | If backend services are unavailable, minting and redemption may be delayed until service is restored. | | Protocol pause | The protocol can be paused. | | Admin controls | DiversiFi can update vault composition, fees, weights, rebalance thresholds, and fee destination. | | Custody | The protocol is non-custodial. User funds are not custodied by SolutioFi in an off-chain account. | Admin keys are secured through multisig and secure signing practices. Admin risk is reduced by these controls, but not eliminated. ## 8. Yield-bearing assets A yield-bearing asset is the visible end of a machine. The chain is whatever produces the yield. The critical questions are: * Is the yield mechanism single and identified, or does it rotate across strategies? * Is the credit collateralized, and enforced by what? * Does the yield originate on this chain? * If not, what carries it here? Yield products that fail often fail because the yield comes from strategies running on other protocols, and one of those protocols is the layer that breaks. | Strategy category | Return drivers | Primary risks | | ----------------------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Portfolio vault without external yield | Underlying asset performance, portfolio construction, rebalancing, and execution costs | Market exposure, liquidity, execution, smart contract, backend, and admin risk | | Portfolio vault with yield-bearing assets | All portfolio drivers plus external asset, issuer, or protocol yield | All portfolio risks plus issuer, credit, liquidity, bridge, wrapper, upstream protocol, or contagion risk | Some DiversiFi strategies use yield-bearing assets for the stable portion of the portfolio, such as syrupUSDC and/or PRIME, depending on the strategy. These assets are evaluated on two criteria: 1. The chain should be direct: a single, identified yield mechanism, not strategies rotating across DeFi protocols. 2. The yield should diversify the portfolio's risk surface rather than simply add more Solana DeFi dependency. This is a trade, not an elimination of risk. Contagion exposure may be reduced, but issuer, credit, liquidity, bridge, wrapper, and counterparty risks remain. Strategy-by-strategy disclosure states which external yield-bearing assets each portfolio holds and in what proportion. ## 9. Wrapped and bridged assets A wrapped asset is a claim on an asset that lives somewhere else. The dependency chain depends on who mints the claim and how. Two models exist: * **Issuer-custodied:** a regulated entity holds the native asset and mints the representation directly on Solana. * **Bridge-minted:** the native asset is locked on its origin chain and a bridge mints the representation on Solana. An issuer-custodied wrapper has one main link: the issuer, with its custody, solvency, redemption process, and freeze powers. A bridge-minted wrapper has at least two: the bridge and everything behind the underlying asset. For BTC exposure, DiversiFi currently uses cbBTC, issued natively on Solana by Coinbase. This keeps the dependency chain to one named issuer/custodian, but it also means Coinbase-related custody, solvency, redemption, and freeze-authority risks apply. For ETH and BNB exposure, available Solana representations are bridge-minted. Wormhole's lock-and-mint model and guardian verification are therefore carried as explicit dependencies. ## 10. Real-world assets An RWA token extends the dependency chain off-chain. At minimum, the chain includes: * the custodian physically holding the asset, * the issuer and the legal claim represented by the token, * the attestation process verifying that supply matches reserves, * and the redemption mechanism converting the token back into the asset. These links cannot be audited by reading contracts. Failure modes include custody, legal, regulatory, attestation, and redemption risks. For gold exposure, DiversiFi uses $GOLD by ORO. $GOLD is issued natively on Solana, so there is no bridge link. The underlying gold is vaulted with regulated custodians, insured, and physically redeemable through a partner network. Backing is verified through monthly proof-of-reserves attestations by an independent audit firm. DiversiFi holds $GOLD unstaked. ORO offers a leasing yield on staked gold, but staking requires a twelve-month lease lockup, which is incompatible with the protocol's redemption and rebalancing requirements. Vault assets must remain liquid enough to support the strategy. As additional RWA categories are added, each one's chain should be documented before inclusion. ## 11. Primary risk factors ### Market exposure Underlying assets can decline in value. Diversification does not guarantee protection against losses. ### Liquidity risk Poor liquidity can increase slippage, widen execution costs, delay execution, or make rebalancing less efficient. DiversiFi uses Jupiter-level slippage protection to mitigate execution at unacceptable prices. ### Execution and routing risk Minting, redemption, and rebalancing depend on routing, DEX liquidity, transaction execution, oracle freshness, and network conditions. ### Smart contract risk Smart contracts may contain bugs, design flaws, or vulnerabilities. Audits reduce risk but do not eliminate it. ### Backend and operational risk The current system depends on backend services for routing, execution coordination, minting, redemption, and operational support. ### Admin and governance risk Admin control over protocol and vault parameters can create risk through misconfiguration, compromise, or poor governance decisions. ### External yield-source risk When a vault includes a third-party yield-bearing asset, it inherits that asset's issuer, credit, liquidity, bridge, wrapper, upstream protocol, and counterparty risks. ## 12. Concrete failure scenarios | Scenario | What can happen | Main risk bucket | Mitigation | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | --------------------------- | ---------------------------------------------------------------------------------- | | Underlying asset collapse | One or more assets fall sharply or become illiquid | Market exposure / liquidity | Vault-specific composition is disclosed to users | | Swap or route fails | DiversiFi retries execution. If retries fail, unswapped funds can be reclaimed by the user | Execution | Jupiter-level slippage protection and reclaim mechanics reduce execution-loss risk | | Backend outage | Minting and redemption may be delayed until service is restored | Backend / operational | DiversiFi runs several backend instances to improve uptime | | Oracle issue | Execution may fail or be delayed if oracle data is stale or unavailable | Oracle / execution | Oracle freshness checks are performed before swaps | | Admin compromise | Vault parameters could be changed maliciously or incorrectly | Admin / governance | Admin keys are secured through multisig and secure signing practices | | Third-party yield asset failure | syrupUSDC, PRIME, or another external asset may suffer issuer, credit, liquidity, wrapper, bridge, or upstream protocol loss | External yield-source | External yield-source exposure is disclosed strategy by strategy where applicable | ## 13. User-facing disclosure principles For DiversiFi-branded strategies, DiversiFi discloses: * assets held, * whether external yield sources are used, * primary risks, * external issuer or protocol dependencies, * strategy-specific constraints. For protocol-level user-owned portfolio vaults, asset selection and portfolio construction may be defined by the user or integration, while DiversiFi continues to disclose the protocol, execution, backend, admin, and smart contract risks of the infrastructure. ## 14. Audits and security DiversiFi has conducted security reviews. Audits and external reviews are important risk controls, but they are not guarantees. Audited systems can still fail. Audit reports are available on the [Audits](/audits.md) page: * [DiversiFi v1 Audit by Sec3 - Program - November 2025](https://github.com/SolutioFi-io/gitbook/blob/main/.gitbook/assets/solutiofi_final_report.pdf) * [DiversiFi v1 Audit by Iron Node - dApp - January 2026](https://github.com/SolutioFi-io/gitbook/blob/main/.gitbook/assets/IronNode-DiversiFi_dApp_Audit_Report_Final.pdf) * [DiversiFi v1 Audit by Sec3 - Program - April 2026 Incremental Review](https://github.com/SolutioFi-io/gitbook/blob/main/.gitbook/assets/solutiofi_incremental_final.pdf) ## 15. Short positioning DiversiFi portfolio vaults are designed as transparent portfolio primitives, not opaque yield farms. For vaults without yield-bearing assets, returns come primarily from the underlying assets, vault design, and rebalancing, not from hidden external yield dependencies. This does not make them risk-free. It makes the core risk surface easier to inspect. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.diversifi.trade/protocol-risk-methodology.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.