Fusion by IPOR

Fusion by IPOR appears to be a real, live product portal rather than a static landing page: the main site advertises a “Live App” and points users to the Fusion app, while the docs describe a working depositor flow with strategy selection, deposits, withdrawal requests, status monitoring, and final withdrawal. The documentation also includes dedicated developer pages for smart contracts, security/audits, and an API, which is a strong sign of a mature product and developer surface. What could not be verified from the available web evidence is whether deposits/withdrawals are currently functioning end-to-end on Arbitrum, Base, and Ethereum, or whether any specific links are broken; those checks are Not verifiable as of 2026-08-29. The presence of product documentation, markdown docs, and a structured API page suggests the UX is beyond template-level marketing, but any claims about live balances, TVL, or operational status remain Not verifiable as of 2026-08-29 without on-chain verification. On the open API question: yes, the docs explicitly expose an API page and even describe query-based access to documentation, which indicates a public developer interface is available.

Ackee Blockchain audited prior IPOR protocol versions; the docs indicate the audit covered the currently live contracts for the cited version, but the listing provided here does not include the detailed findings table.

BlocSec audited the updated IPOR Fusion stack; IPOR docs say this report covers the currently live contracts.

Protofire audited IPOR Fusion and IPOR docs say the report covers the currently live contracts.

Fusion by IPOR does appear to have an active bug bounty program via Immunefi. The program is marked Live Since 11 April 2023, with the latest Immunefi page update on 30 March 2026; the scope page also shows the program as live and requires a PoC for valid reports. The published parameters are:

• Coverage: 30 IPOR smart contracts.
• Reward range: originally stated as $1,000 to $100,000 in crypto assets in IPOR’s announcement, while the current Immunefi listing shows $5,000 minimum and $20,000 maximum.
• Severity model: Immunefi’s classification system (V2.2), from None to Critical.
• Submission channel: only through Immunefi.
• Review policy: bounties may be adjusted as the protocol grows. Results: I did not find a public disclosure page in the provided sources listing total reports, payouts, or confirmed bounty-triggering incidents for Fusion/IPOR, so the program’s outcome is Not verifiable as of 2026-08-29.

Custody in Fusion by IPOR is organized as per-vault, onchain-segregated custody rather than pooled custody. Each Fusion Vault is described as an isolated ERC-4626 vault / mandate vehicle with dedicated custody, meaning assets are held by the specific vault contract and are not commingled with other vaults. The protocol says execution is separated from custody: Fuses are stateless connectors used to interact with external DeFi venues, while all assets and accounting remain inside the vault contract. Operationally, custody is governed by role-based onchain controls. IPOR describes separate roles for Owner, Atomist, Fuse Manager, Alpha, and Guardian, where the Owner controls admin permissions and timelocks, the Atomist sets risk parameters, the Fuse Manager controls allowed integrations, Alpha executes within whitelisted limits, and the Guardian can pause or veto changes. This means custody is not managed by a single offchain custodian; instead, control over what the vault can do is enforced by smart-contract permissions. For institutions, IPOR also says Fusion can integrate with qualified custody arrangements and keep assets inside the custodial perimeter; its news materials mention BitGo-qualified custody for dedicated client vaults. That is a partnership/usage claim rather than a protocol-level custody guarantee, but it indicates Fusion is designed to work with institutional custodians when required. In short: assets sit in isolated vault contracts onchain, strategy execution is routed through constrained fuses, and operational authority is split across predefined roles with timelocks and emergency controls.

IPOR’s stated response was to work with Blockaid and Hexagate for detection, SEAL for recovery, and other security firms to trace the funds; IPOR also said the DAO treasury would cover the shortfall and all affected depositors would be made whole. Reported reimbursement was full repayment from the treasury, with DefiLlama marking the returned funds as $336,000.

Fusion by IPOR has one publicly reported incident since launch: on Jan. 6, 2026, a legacy USDC Fusion Optimizer vault on Arbitrum was exploited, causing about $336,000 in USDC losses; the attacker used a smart-contract logic flaw in the vault’s fuse/withdrawal path and EIP-7702 delegated execution to inject malicious logic and drain funds. The affected scope was limited to that one old vault; IPOR said other Fusion vaults were not impacted.

Fusion by IPOR organizes key management through hierarchical role-based access control (RBAC) rather than a single shared operator key. The main roles are Atomist (strategy/vault curator), Alpha (strategy executor with limited API keys), Risk Manager, and Guardian (emergency controller), with an Owner role able to enforce global minimum delays; this creates separation of duties for strategy design, execution, risk oversight, and emergency response. Operationally, the Atomist defines the approved assets, execution adapters (Fuses), and risk bounds, while the Alpha role can execute and rebalance only within that pre-set envelope and cannot exfiltrate funds or call unauthorized protocols. The docs also state that different accounts assigned to the same role can have different timelocks, so key control is not just role-based but also delay-based. The architecture is further split by vault isolation: each Fusion Vault is an independent ERC-4626 vault with siloed risk and dedicated configuration, so operational keys for one vault do not automatically govern another. Protocol interaction is mediated by immutable, stateless Fuses, which are whitelisted and managed through their own access-control layer, limiting which execution paths keys can activate. If you want the shortest characterization: Fusion uses a multi-role, least-privilege operator model with timelocks and emergency pause authority, not a conventional single custodial private-key setup.

IPOR Fusion uses a polymorphic vault architecture with a central PlasmaVault that holds user funds and stateless Fuses connecting to external markets; most risk is concentrated in vault configuration and access control, not in per‑strategy contracts. ### Contract set & verification

• Core components (per docs): Fusion/Plasma Vault, Base Fuses, Rewards Manager, Access Management, Price Oracle Middleware, Prehooks, Context Manager, Withdraw Manager.
• Deployed addresses for Ethereum, Arbitrum, Base are listed in IPOR’s “deployed contracts” and GitHub ABI repo; these are the main reference for contract mapping.
• On‑chain verification status, exact addresses, and proxies are Not verifiable as of 2026‑08‑29 (no direct chain access this turn). ### Upgradeability & proxy/admin design
• Docs state Fuses are non‑upgradeable, stateless adapters; strategy extension is achieved by adding/removing Fuses and configuration, not upgrading the central PlasmaVault.
• Access control is integrated with OpenZeppelin Access Manager per audit scope and Protofire announcement, implying role‑based permissions for upgrades, configuration changes, and sensitive functions.
• Whether the Vault itself is behind a proxy and the exact proxy admin type, timelock contracts, or on‑chain delays is Not verifiable as of 2026‑08‑29. ### Roles, permissions & emergency controls Based on docs and audit scope (interpretation, not on‑chain verified):
• Likely privileged roles: protocol admin, access manager admin, curator/“Atomist” roles controlling strategy configuration, keeper/“Alpha” operators.
• Sensitive functions probably gated by Access Manager:
• vault configuration (asset/market limits, Fuses enabled),
• fee parameters and rewards manager settings,
• oracle middleware configuration,
• pause/withdraw manager behavior.
• Exact role addresses, whether ownership is renounced, and concrete timelock delays are Not verifiable as of 2026‑08‑29. ### User exit, worst‑case key compromise, rug/freeze risk
• PlasmaVault is the single stateful holder of user assets; configuration mistakes or malicious admin changes can misroute funds or block withdrawals.
• Docs emphasize “transparent and secure allocation” and non‑upgradeable Fuses, but do not guarantee that users can always exit without admin cooperation (e.g., if Withdraw Manager or vault can be paused).
• Worst case with compromised admin keys:
• reconfiguration of Fuses to malicious markets,
• disabling or rerouting withdrawals,
• fee/oracle manipulation affecting strategies and valuations.
• Due to reliance on centralized access management, there is material admin/rug‑style control risk until ownership is demonstrably distributed, timelocked, or renounced on‑chain (Not verifiable as of 2026‑08‑29). ### Architecture map (text)
• PlasmaVault (per chain): custody & accounting.
• Access Manager: role/permission layer guarding vault, Fuses, rewards, oracle, withdraw logic.
• Fuses: stateless adapters to external DeFi markets.
• Price Oracle Middleware: feeds valuations and parameters to vault/strategies.
• Withdraw Manager / Context Manager / Prehooks: orchestrate deposits, withdrawals, and strategy execution paths. Diagram (conceptual, not on‑chain verified): User → PlasmaVault → (via Access Manager‑gated calls) → Fuses → External Protocols; side modules: Rewards Manager, Oracle Middleware, Withdraw/Context/Prehook managers.

Fusion by IPOR is a product of the IPOR Protocol, so team assessment focuses on IPOR’s core contributors rather than a separate “Fusion” entity. 1. Founders & core team

• IPOR was co‑founded by Lukasz (Luke) Juśkiewicz and Piotr Wójcik, both publicly visible and active on social media and in conference presentations.
• The project describes itself as built by a team with backgrounds in tradfi risk management, structured products, and derivatives (ex‑banking and consulting), but these claims are primarily self‑reported. → unverified marketing claim. 2. Public vs. anonymous; credibility signals
• Key contributors use real names and LinkedIn profiles, suggesting a non‑anonymous core team.
• IPOR has been live since 2022 with interest‑rate swaps and structured DeFi products; Fusion is a later product iteration, not a new protocol.
• Multiple security audits of IPOR smart contracts have been conducted by firms such as Quantstamp and others; Fusion relies on these underlying IPOR primitives. This provides moderate technical‑credibility, though audits are not guarantees. 3. Prior projects / outcomes / hacks
• No major protocol‑level hacks or insolvencies of IPOR are documented in independent media or incident databases as of 29 Aug 2026. Not verifiable as of 29 Aug 2026 for smaller or undisclosed incidents.
• The founders’ prior individual projects outside IPOR are mentioned in bios (tradfi roles, startups), but details and outcomes are sparse and largely self‑reported → unverified marketing claim. 4. Corporate presence: office, jurisdiction, business reality
• IPOR presents itself as a decentralized protocol; public materials do not clearly state a single operating company or domicile tied specifically to Fusion.
• There are references to a European background for the team, but no independently confirmed, specific registered corporate entity, office address, or onshore jurisdiction associated with Fusion by IPOR. Not verifiable as of 29 Aug 2026.
• No records in major regulator/court/sanctions databases explicitly referencing “IPOR” or “Fusion by IPOR” as of 29 Aug 2026. Not verifiable as of 29 Aug 2026 for smaller jurisdictions. 5. Reality check for institutional use
• Pros: non‑anonymous founders, multi‑year operating history, audited core IPOR contracts, and no widely known catastrophic events.
• Gaps: lack of clearly documented legal entity and jurisdiction for Fusion, limited independently verified track record of founders’ prior ventures, and dependence on self‑reported professional background. For an institutional risk book, Fusion by IPOR currently screens as a credible but relatively lean, founder‑driven DeFi protocol with typical decentralization/legal‑entity ambiguities that warrant enhanced legal and KYC/ODD review before material exposure.

Fusion by IPOR appears to be a fixed‑rate / structured yield product built on IPOR’s interest‑rate derivatives (IRDs), but key economic‑model metrics are only partially documented. Not verifiable on-chain as of 2026‑08‑29. ### Strategy & Assets

• IPOR offers interest rate swaps and derivatives on stablecoin money markets (USDC/USDT/DAI), aiming to transform *variable DeFi yields into fixed rates*.
• Fusion is described in IPOR communications as a managed strategy that allocates into IPOR IRDs and money‑market protocols to deliver target yields while hedging rate risk. This is an *unverified marketing claim*.
• Typical underlying venues mentioned for IPOR ecosystem are Aave/Compound‑like money markets and stablecoin pools, implying stablecoin in, stablecoin out with exposure to lending‑borrow rates. This mapping to Fusion specifically is *not verifiable as of 2026‑08‑29*. ### Yield Source: Organic vs Subsidized
• IPOR’s core yield comes from interest rate differentials and swap fees paid by traders/hedgers in its IRD markets.
• No current evidence of ongoing token incentives or large external subsidies tied specifically to Fusion. Not verifiable as of 2026‑08‑29. ### Risk Profile (Directional vs Market‑Neutral; Leverage)
• Design intent is rate‑hedging / pseudo market‑neutral exposure, using swaps to offset variable lending rates. This is conceptual; Fusion’s exact hedge ratios and residual directionality are Not verifiable as of 2026‑08‑29.
• No public documentation confirming user‑level leverage, looping, or restaking inside Fusion; likely reliant on underlying protocols’ leverage only. Not verifiable as of 2026‑08‑29. ### Lock‑ups, Withdrawals, Collateral
• IPOR derivatives generally use stablecoins as collateral and margin.
• Fusion‑specific lock‑up periods, withdrawal queues, gates, or circuit‑breakers are Not verifiable as of 2026‑08‑29. ### Fees, Limits, Protocol Revenue
• IPOR charges trading fees and possibly funding/settlement fees on IRDs, forming protocol revenue.
• How much of this accrues to Fusion depositors vs IPOR DAO/treasury is Not verifiable as of 2026‑08‑29.
• Product‑level deposit caps, per‑wallet limits, and emergency withdrawal mechanics are Not verifiable as of 2026‑08‑29. ### TVL & APY (by Chain/Product, Trend)
• Public aggregators (e.g., DeFiLlama) show IPOR TVL mainly on Ethereum, with smaller exposure on Arbitrum and Base; Fusion is not always broken out as a separate line item, so per‑product TVL is Not verifiable as of 2026‑08‑29.
• Historical APY, volatility, and sustainability metrics for Fusion specifically are Not verifiable as of 2026‑08‑29. Contradiction box: Any specific Fusion TVL/APY numbers found only in IPOR marketing or UI without independent aggregator confirmation are unverified marketing claims and must not be treated as economic facts.

Fusion by IPOR’s reserve / treasury is not fully verifiable from the available web sources. The only explicit balance-related claim I found is that IPOR Labs said the Arbitrum exploit loss of $336K USDC would be fully refunded from treasury reserves, and that these reserves were less than 1% of total assets managed by Fusion. Because no on-chain treasury wallet addresses, token-by-token balances, custody structure, reserve policy document, or attestation were available in the search results, those items are Not verifiable as of 2026-08-29. What can be stated from the sources:

• Fusion is a multichain protocol on Arbitrum, Base, and Ethereum.
• Public sources describe a broader platform scale of $35.83M liquidity (Bathymark open-data read) and $55.23M TVL (MrDeFi), but these are protocol-level metrics, not treasury reserves.
• IPOR’s own site reports TVM $154.3M and 92 vaults, again not reserve assets.
• Following the Arbitrum incident, IPOR stated it would use treasury reserves to make depositors whole. What remains unverified:
• Treasury size: Not verifiable as of 2026-08-29.
• Treasury/reserve wallet addresses: Not verifiable as of 2026-08-29.
• Composition (USDC, ETH, governance tokens, etc.): Not verifiable as of 2026-08-29.
• Custody / control (multisig, timelock, EOAs, DAO control): Not verifiable as of 2026-08-29.
• On-chain balances via Dune: Not verifiable as of 2026-08-29.
• Reserve policy / attestations: Not verifiable as of 2026-08-29. The key risk note is that the only treasury-related evidence in the search results is a post-incident statement about refund funding, not a transparent reserve disclosure or independently verifiable on-chain treasury report.

IPOR’s Fusion appears to use the existing IPOR token (IPOR) rather than a separate “Fusion” token, and there is no evidence of a distinct native token for Fusion itself. Below focuses on IPOR; on‑chain verification is not possible in this run. Native token & contracts

• Token name/ticker: IPOR (IPOR Protocol).
• Primary chain: Ethereum; DeFiLlama shows IPOR as an Ethereum governance token for IPOR Protocol.
• Contract address: Not verifiable as of 2026‑08‑29. Supply, market cap, FDV
• DeFiLlama and major trackers list IPOR with a fixed/max supply and circulating supply, but exact numbers diverge slightly across platforms, suggesting data from different APIs.
• Precise total vs circulating supply, market cap and FDV: Not verifiable as of 2026‑08‑29 (no consistent, independently cross‑checked figures). Token utility & governance role
• IPOR is described as the governance token for the IPOR interest‑rate derivatives ecosystem.
• Fusion by IPOR is positioned as a yield product built on top of IPOR’s protocol; multiple media and listing sources link Fusion back to IPOR as the parent protocol, implying governance via IPOR, not a separate Fusion token.
• Concrete governance mechanics (voting contract, quorum rules): Not verifiable as of 2026‑08‑29. Revenue share, buybacks, burns, staking rewards
• Public listings and basic docs describe IPOR as a governance/utility token but do not clearly document any revenue share, buyback, or burn program tied specifically to Fusion yields.
• Staking/LP incentives for IPOR exist in broader IPOR liquidity programs, but direct Fusion‑specific reward flows are unclear.
• Therefore: Fusion‑specific revenue share, buybacks, burns, and staking rewards are not verifiable as of 2026‑08‑29. Emissions & unlocks; allocations
• Several token‑listing pages reference a fixed supply and mention team/investor/community allocations in general terms for IPOR, but do not provide a full vesting schedule or unlock calendar that can be cross‑checked independently.
• Emissions schedule, unlock schedule, and whether unlocks occurred on‑chain: Not verifiable as of 2026‑08‑29.
• Detailed allocations to team/investors/treasury/community: Not verifiable as of 2026‑08‑29. Top holders, control functions, liquidity
• Without on‑chain tools, top‑holder concentration, insider wallets, and existence of mint/blacklist/fee‑switch functions in the token contract cannot be checked: Not verifiable as of 2026‑08‑29.
• Fusion by IPOR deposits and liquidity are reported on Arbitrum, Base and Ethereum, with IPOR‑related pools on major DEXes (e.g., Uniswap on Ethereum), but exact DEX depth and pair breakdown per chain are not verifiable as of 2026‑08‑29. Contradictions: Several trackers disagree on exact IPOR supply and market cap figures; without on‑chain confirmation, none can be treated as authoritative.

For Fusion by IPOR, a Bitcoin drop below $10,000 is a severe collateral-value shock, but the exact protocol impact is Not verifiable as of 2026-08-29 because the available results do not identify Fusion’s BTC exposure, liquidation parameters, or chain-specific positions. The only protocol-specific source available here is the project’s own page, which says Fusion exposes vault mechanics and onchain activity, but it does not provide the needed risk data in the search results. What can be said from the market context is that a move below $10,000 would imply an extremely deep BTC drawdown, and one cited scenario frames it as requiring a broad liquidity shock, forced deleveraging, and a crypto-wide confidence collapse. Another source notes that some bearish market commentary has discussed $10,000 as a possible downside target, but those are market opinions, not protocol-specific loss estimates. For a DeFi stress view, the relevant effects would be:

• If BTC is held as collateral, vault NAV could fall sharply and liquidation risk would rise.
• If BTC is the borrowed asset, lender-side losses depend on overcollateralization, liquidation speed, and oracle update latency.
• If exposure is indirect, the effect depends on whether strategy assets are BTC-linked, BTC-denominated LPs, or options/structured products. Because the chain-by-chain vault composition for Arbitrum, Base, and Ethereum is not exposed in the results, the distribution of risk across chains is Not verifiable as of 2026-08-29. No onchain verification was possible in this run, so any figure for TVL, open interest, collateral ratios, or liquidation thresholds would be speculative and should not be inferred.

A 20% depeg in the largest collateral asset would most likely be absorbed first by Fusion’s vault-level risk controls and could trigger automatic deleveraging or liquidity withdrawal rather than immediate cross-vault contagion, because Fusion states that risks are siloed by vault and that the system can reduce or eliminate DeFi exposure during market stress. However, the exact loss for the Arbitrum, Base, and Ethereum deployments is Not verifiable as of 2026-08-29 because the available sources do not provide the current vault-by-vault collateral composition, leverage, liquidation thresholds, or live exposures needed to size the shock. The protocol’s own materials say Fusion vaults can automatically withdraw liquidity in stress conditions and that strategies may include deterministic risk controls with automated deleverage triggers. IPOR also says risk can be monitored for asset depegs and that a guardian or Alpha role can recall funds from external protocols if threats are detected. One important contradiction is that an independent write-up reported a prior Arbitrum USDC Fusion Optimizer vulnerability that caused a $336,000 loss in January 2026, while IPOR’s materials emphasize resilient, automated stress handling; that incident shows that implementation risk can still materialize despite design controls. I cannot verify from the provided sources whether that incident changed current exposures or whether any of the three chains carries the largest share of risk today.

For the fraud-by-DAO/owners stress scenario, I found no verifiable evidence that Fusion by IPOR’s DAO or owners committed fraud. The available reports describe a smart-contract exploit on a legacy Arbitrum USDC vault, with the protocol stating the DAO will fully compensate affected depositors from treasury; that is a response to a loss event, not proof of fraud by the DAO/owners. What is verifiable is that the incident involved a $336k loss on a legacy vault, was attributed publicly to a vulnerability in older vault logic and EIP-7702-related abuse, and IPOR said other vaults were unaffected. If the question is whether a fraud allegation exists against the DAO or owners, that is not verifiable as of 2026-08-29 from the provided sources. The strongest supported interpretation is operational/security failure on a legacy vault, not intentional misappropriation by governance or ownership.

Fusion by IPOR’s primary yield source negative 30d stress scenario is not verifiable as of 2026-08-29 from the available sources. The search results confirm only that Fusion is a multi-strategy onchain vault infrastructure with allocations, performance, costs, and onchain activity exposed, and that it routes across yield sources rather than relying on a single clearly identified primary yield engine. What can be said from the available evidence is limited to protocol context: DefiLlama shows Fusion is active across Ethereum, Base, and Arbitrum, with current fee and revenue activity split across chains, but it does not identify a primary yield source or provide a 30-day yield-stress attribution model. The protocol’s own materials and third-party posts describe Fusion as an automation and execution layer for yield strategies, not as a single-strategy protocol with a disclosed funding-rate or carry-trade dependence that would let us model a “negative 30d” primary-yield shock. Because Dune/on-chain verification is unavailable in this run, any chain-level exposure percentages, strategy P&L sensitivity, or proof that a specific yield source would become negative for 30 days would be speculative. Not verifiable as of 2026-08-29.

Fusion by IPOR appears to be operationally centralized with role-based controls, not a token-governed DAO. IPOR’s own docs say critical actions are executed through an owner / atomist / fuse-manager access model with optional, configurable timelocks; by default, administrative actions can be immediate, so on-chain delay is not guaranteed unless configured. The docs also say management should use a multisig, and that different configurations may use 4/6 or 5/8 style thresholds, but the exact live signer set, threshold, and independence are Not verifiable as of 2026-08-29 because on-chain verification is unavailable in this run. A DAO exists more as a governance construct than as a clearly permissionless control layer. The docs describe a DAO-style owner setup as one option, but they also emphasize that the owner governs admin roles and timelock settings, which means real control can still sit with a small operator group if the multisig and delays are centrally configured. There is no evidence here of a live voting process, proposal forum, or token-weighted governance system controlling protocol funds or upgrades; that is Not verifiable as of 2026-08-29. For the frontend, IPOR’s terms refer to hosted user interfaces at app.ipor.io and fusion.ipor.io, but the legal operator/entity, jurisdiction, registration number, and directors are Not verifiable as of 2026-08-29 from the gathered sources. Similarly, I cannot verify which wallet(s) currently control contracts, treasury/funds, or whether a timelock is actually active on Arbitrum, Base, and Ethereum without chain-state verification; those chain-by-chain exposures are Not verifiable as of 2026-08-29. If you want the institutional risk view in one line: governance is predominantly team/multisig-controlled, with timelocks optional and DAO participation not evidenced as binding control.

Fusion by IPOR appears to be operated by IPOR Labs AG and its interface terms are governed by Swiss law; the terms also say the interface is for users outside the U.S., China, and other sanctioned/embargoed jurisdictions, and that users are solely responsible for complying with applicable securities, AML/KYC, privacy, and tax laws. The privacy policy exists and provides a contact email, but the details of actual data-processing practices were not fully visible in the gathered material. On restrictions and compliance, the terms explicitly treat the protocol as a decentralized service while stating the interface does not control the protocol; they also impose broad legal-responsibility language on users, which is typical of DeFi front ends but leaves real enforcement risk at the smart-contract and jurisdictional level. IPOR’s own materials further describe vault-level access controls, including optional KYC/KYB-gated deposits and blacklist/whitelist functionality, and mention a MiCA-authorised entity using Fusion; these are useful indicators of compliance-oriented design, but they are still unverified marketing claims without independent legal review or on-chain corroboration. I found no verified court cases, regulator actions, or sanctions designations specifically tied to Fusion by IPOR in the gathered sources. As a legal-risk assessment, the key issue is the gap between the interface’s restrictive terms and the fact that the protocol is described as decentralized: if control is exercised by users, vault operators, or governance participants rather than a single regulated operator, legal exposure may attach to multiple actors, not just the front-end entity. In short: the identifiable legal wrapper is Swiss, the public interface is geofenced/restricted, and the design explicitly contemplates KYC/AML and privacy compliance; however, the actual legal risk remains higher than the interface terms suggest, because decentralized, cross-border vault activity can create securities, sanctions, AML, and data-protection exposure across several jurisdictions.

The stablecoin used by Fusion by IPOR appears to be USDE / USDe in at least one Fusion vault listing, and I found no verifiable evidence in the provided sources that this stablecoin depegged while used by the protocol. The protocol/aggregator materials I can see only mention vault operations and risk exposure; they do not provide a depeg history for the underlying stablecoin itself. Because the available sources do not identify a specific depeg event for Fusion’s stablecoin, the number of depegs is not verifiable as of 2026-08-29. The last depeg time and the depeg percentage are therefore also not verifiable as of 2026-08-29. If you want, I can do a second-pass source check focused specifically on the exact stablecoin composition of each Fusion vault and then compare it against independent depeg reports.

Fusion by IPOR’s top risks are: (1) strategy/operator risk—vault performance and safety depend on fund-manager/Alpha execution, and a malicious or buggy strategy can misroute or drain assets; (2) composability risk—vaults route into other DeFi protocols, so any downstream exploit or failure can hit depositors; (3) smart-contract risk—bugs or vulnerabilities in Fusion code, reserve tokens, or integrated components can create loss events; (4) oracle risk—incorrect price or redemption data can cause bad valuations or actions; and (5) network / governance / admin-risk concentration—protocol behavior depends on chain conditions and on privileged emergency roles such as guardians or pausing powers, even if user funds are intended to be siloed by vault.

Fusion by IPOR’s top strengths are: (1) modular execution with broad DeFi connectivity — it offers a single integration point to multiple yield venues and pre-built fuse modules for 40+ onchain protocols and 170+ interaction methods; (2) strong risk isolation — vaults are siloed so losses or failures do not spill over between vaults; (3) automated optimization — it includes intelligence-driven execution for rebalancing, allocation, and risk management, with the ability to withdraw during stress; (4) institutional-grade structure — each vault has dedicated custody, independent configuration, and ERC-4626 compatibility; and (5) security-oriented design — it emphasizes battle-tested contracts, audited infrastructure, immutable/stateless connectors, and role-separated access control.