Upshift

Upshift is a DeFi vault infrastructure protocol focused on transparent yields / vaults, with official docs at docs.upshift.finance and site at upshift.finance; its docs say it supports Ethereum, Hyperliquid/HyperEVM, and Monad among many other chains, while DefiLlama categorizes it as a yield/vault protocol. The docs/blog indicate vault launches since April 2025, but a precise protocol launch date is not verifiable as of 2026-08-30. The protocol appears to have a native branded token family on Ethereum (e.g. upUSDC, upUSD, upINJUSDT) visible on token explorers, but a single canonical native governance token is not verifiable as of 2026-08-30. Main contract addresses and explorer verification status are not verifiable as of 2026-08-30 because I could not confirm them against at least two independent sources without on-chain/Dune access. Fork lineage: I could not verify that Upshift itself is a fork; the available evidence only shows it offers vault infrastructure and cross-chain yield products. The fork question is therefore Not verifiable as of 2026-08-30. Because of that, changes vs upstream and whether those changes were audited are also Not verifiable as of 2026-08-30. On malicious-modification history in similar forks: that broader risk is real in DeFi, but no protocol-specific case for Upshift was verifiable from the gathered sources alone.

Upshift has a real, working product rather than a pure landing page: its docs describe a public API with unauthenticated endpoints, and the product page app-v2.upshift.finance shows a live vault view with deposit token, receipt token, and withdrawal timing details. The documentation also includes developer pages and app examples, which is a strong sign of an operational product surface rather than a static marketing site. Product maturity appears moderate-to-high: the site is supported by detailed docs, an API reference, and vault-specific pages, but there is no independent on-chain verification here, so live deposits/withdrawals and chain-by-chain usage cannot be confirmed beyond the product pages themselves. The withdrawal disclosure on the vault page says standard withdrawals are processed within 30 days and may complete sooner, which suggests an active redemption workflow rather than an idle brochure site. I did not find evidence in the gathered sources of broken links, fake metrics, or obvious template-site signs. However, those negatives are not fully verifiable from the available evidence, so they should be treated as unresolved rather than cleared. Open API: yes. The docs explicitly state that Upshift API v1 is public, RESTful, and currently operates without authentication for public endpoints. Not verifiable as of 2026-08-29: whether deposits and withdrawals are currently live on Ethereum, Hyperliquid L1, and Monad for all listed vaults, and whether any production UI links are broken.

Security review of Upshift Finance smart contracts on any EVM-compatible chain (Solidity); the later report explicitly states the source code is planned to be compatible with any EVM chain supporting Paris or higher, with the deployment version selected per target network.

Earlier audit of Upshift Finance smart contracts; the report shows mixed remediation status with at least one Medium issue mitigated and others accepted. Findings visible in the excerpt include: Medium F-2025-14332 'Inaccurate Total Assets Valuation Due to Oracle and Conversion Logic Limitations' — Mitigated; Medium F-2025-14333 'Direct Token Donations Can Distort TVL and Share Accounting' — Accepted; Low/Info issues such as missing events, missing safeguards when assigning vault ownership, and fee-on-transfer token incompatibility were marked Accepted.

Audit of the 'solana-erc4626' program associated with Upshift/Defiborg. The report states 7 findings in total and says patches were resolved in PR#3, PR#4, and PR#5; however, the excerpt does not provide a clean critical/high/medium breakdown for every item in the visible text.

Not verifiable as of 2026-08-29. The search results did not identify an Upshift-specific, active bug bounty program, and none of the results were from a source that clearly matched this protocol; the available pages were generic bounty listings or unrelated programs. Because I could not confirm a protocol-specific program from the provided results, I also cannot reliably state its start date, scope/parameters, or paid outcomes. If you want, I can next check whether Upshift is listed on a web3 bug bounty platform such as Immunefi or HackerOne and whether any archived or governance announcements mention a launch, reward cap, or payouts.

Upshift is a very recent / emerging protocol; detailed, independently verifiable risk mapping is limited. Not verifiable on-chain as of 2026-08-30. 1. Protocol identity and scope Public information on a DeFi protocol named Upshift operating on Ethereum, Hyperliquid L1, Monad is extremely sparse. Web results reference “upshift” mainly in non‑DeFi contexts (consulting, trading education, generic finance content), with no clearly attributable core contracts, audits, or docs matching this multi‑chain profile. This means key dependencies cannot be reliably enumerated. 2. External protocol dependencies

• Concrete integrations with DEXs, money markets, or derivatives platforms (e.g., Uniswap, Aave, Hyperliquid perps, Monad-native DEXs) are Not verifiable as of 2026-08-30.
• No reliable evidence of specific LP positions, yield strategies, or restaking integrations (EigenLayer, Symbiotic, Karak, etc.). Not verifiable as of 2026-08-30. 3. Oracles and price manipulation risk
• No confirmed oracle provider (Chainlink, Pyth, Chronicle, TWAP, internal oracle, or CEX-based feed). Not verifiable as of 2026-08-30.
• Without this, one cannot assess:
• Oracle update cadence and deviation thresholds.
• DEX vs. oracle price alignment and manipulation surface.
• LST / restaking collateral mark‑to‑market design. 4. Bridges and cross‑chain infrastructure
• For Ethereum ↔ Hyperliquid L1 ↔ Monad, there is no independently confirmed bridge stack (e.g., Wormhole, LayerZero, Axelar, Hyperliquid’s internal bridge).
• Therefore, risks around validator sets, relayers, light‑client security, message pausing/upgrades, and replay / spoofing cannot be protocol‑specifically evaluated. Not verifiable as of 2026-08-30. 5. Custodians, CEX/MM exposure
• No evidence Upshift custody is delegated to centralized custodians (Fireblocks, Copper, CEX sub‑accounts), or that strategies rely on centralized market makers or off‑chain delta hedging. Not verifiable as of 2026-08-30. 6. RWA, stablecoin, LST/restaking exposures
• No reliable indication that Upshift holds RWA, off‑chain SPVs, or on‑chain RWA issuers.
• No confirmed stablecoin mix (USDC/USDT/DAI/LUSD, etc.) or LST/restaking assets (stETH, wBETH, rsETH, ezETH, restaked LSTs). Not verifiable as of 2026-08-30. 7. Scenario analysis (only generic, not Upshift‑specific) Given the absence of verifiable data, only *generic* dependency risk patterns can be stated:
• Stablecoin depeg → losses on stable‑denominated positions, bad debt in lending strategies.
• LST or restaking failure → collateral impairment, liquidations at distorted prices.
• Bridge exploit → loss or freeze of bridged assets on one or more chains.
• Oracle manipulation → under‑collateralized borrowing, protocol insolvency. Without contract addresses, whitepaper, or audit references that can be linked to a specific Upshift DeFi deployment, all protocol‑specific dependency and counterparty assessments are Not verifiable as of 2026-08-30.

Upshift presents custody as a non-custodial vault infrastructure model: depositors keep ownership of assets through receipt/share tokens, and those shares sit in the depositor’s wallet or with its custodian rather than in Upshift’s control. In its documentation, Upshift says capital is routed into segregated subaccounts governed by a policy engine that enforces whitelists at the chain, protocol, token, and function levels, and that neither Upshift nor the curator can move funds to an external wallet. For institutional deployments, Upshift documents two custody paths: an August subaccount (smart-contract wallet) setup and a Fordefi MPC setup, both using permissioned controls and transaction-policy approval workflows. Upshift also says it can integrate with qualified custodians such as Kraken Institutional, where assets deploy from custody into vaults and the resulting position is recorded as a receipt token in the client’s segregated custody account.

Upshift’s key management is organized around MPC (multi-party computation) rather than a single custodian-controlled private key. The clearest public evidence says its vaults are *self-custodied by default* and that, for its Stellar launch, FORDEFI handles MPC key management while Upshift provides the vault standard and policy controls. What can be verified from the available sources is limited: Upshift says its vaults are non-custodial, use a policy engine to enforce restrictions, and can be deployed across many chains. A third-party LinkedIn post from FORDEFI states that Upshift’s Stellar vault uses MPC key management and that curators/depositors get self-custodied wallet infrastructure with policy controls. Chain-specific status

• Ethereum / Hyperliquid L1 / Monad: Not verifiable as of 2026-08-29 from the provided sources.
• Stellar: Not part of your requested chain set, but it is the only chain where the sources explicitly mention MPC key management. So, the safest answer is: Upshift appears to organize key management as institutional MPC-based, self-custodial vault control with policy enforcement, but the exact operating model on Ethereum, Hyperliquid L1, and Monad is Not verifiable as of 2026-08-29 from the available sources.

Upshift vaults use upgradeable ERC‑4626 tokenized vault contracts with strict role-based permissions, creating material smart contract and admin risk alongside non-custodial user exit paths. Because on-chain tools are unavailable, all contract addresses, verification status, proxy layout, and timelock behavior are Not verifiable as of 2026‑08‑29. ### Architecture & upgradeability

• Core component: TokenizedVault / TokenizedAccount ERC‑4626 vaults and multiAssetVault proxies; some vaults are explicitly described as *upgradeable*.
• Cross-chain: system includes an OFT (omnichain fungible token) via LayerZero plus vaults that issue OFT as shares.
• Hyperliquid L1: Upshift runs natively on HyperEVM (EVM-compatible), so architecture is expected to mirror Ethereum (vault proxies + ERC‑4626).
• Monad: Upshift treats Monad as bytecode‑compatible EVM; contracts can be redeployed without changes, implying similar proxy/role patterns. *On-chain verification of proxy admins, implementation addresses, and decoded events is Not verifiable as of 2026‑08‑29.* ### Roles, admin powers & timelocks The Hacken audit of “Upshift Vault” describes:
• Configurable roles & permissions for capital management.
• Timelocks and emergency withdrawals enforced at the vault level.
• Configurable fee parameters (performance and management fees) controlled by a vault operator. This implies at least:
• Admin / operator role: can update strategies, fees, and possibly upgrade implementation.
• Emergency role: can trigger emergency withdrawal or policy changes. Exact role addresses, renounced/active status, and real timelock delay Not verifiable as of 2026‑08‑29. ### User exit & worst‑case key compromise
• Upshift markets vaults as non‑custodial, with users holding ERC‑4626 receipt tokens and withdrawal/redemption logic enforced in the vault contract.
• In normal operation, users should be able to redeem vault shares for underlying assets without admin intervention, subject to strategy liquidity. Key‑compromise scenarios (protocol-level inference from described design, not on-chain facts):
• If an upgrade/admin key is compromised on any chain, attacker could:
• Upgrade implementation to malicious logic.
• Change fee parameters to confiscatory levels.
• Abuse emergency controls to freeze withdrawals or redirect funds.
• Cross-chain OFT + LayerZero introduces additional attack surface: compromised config could misroute share tokens or break accounting. ### Rug/freeze risk (Ethereum, Hyperliquid L1, Monad)
• Rug risk: present via upgradeable vaults and powerful fee/admin roles; mitigated by audited code and timelocks but not eliminable.
• Freeze risk: emergency withdrawal / pause-like powers could halt exits or force migration; details per vault and chain are Not verifiable as of 2026‑08‑29. Given missing on-chain visibility, institutional use should assume meaningful governance and key‑holder risk across all three chains and require direct confirmation of:
• Verified contract addresses and proxy relationships per vault.
• Admin multisig composition, timelock parameters, and any role renunciation.
• Explicit, tested user exit paths if all admins fail or are malicious.

Upshift appears to have a largely public, non-anonymous founding team with a credible institutional background and real operating business, but some key "reality" details (exact office, legal domicile, corporate structure) are Not verifiable as of 2026-08-29. Founders & senior team

• Upshift is co-founded by Aya Kantorovich and Alexandre (Alex) Elkrief.
• Aya is publicly described as Co-Founder & Co-CEO of August and Upshift on LinkedIn, with prior roles on the founding team at FalconX and previous experience at Pantera Capital.
• Blockworks’ coverage states that August (formerly Fractal) was co-founded by Aya and Alex, and that Upshift is being spun out of August’s prime brokerage infrastructure, with Upshift CEO Alex Elkrief and co‑founder Aya leveraging their institutional trading background.
• Upshift’s social and announcement channels (X, Telegram) consistently identify Alex Elkrief as co‑founder and public representative of the protocol. Prior track record, outcomes, and known incidents
• Aya’s prior firms FalconX and Pantera Capital are established, regulated-facing crypto institutions; there is no public record in the retrieved data of major protocol hacks or rug pulls directly linked to Aya or Alex.
• August (the prime brokerage powering Upshift) reportedly handles multi‑billion monthly volume and supports many blockchains and protocols, positioning Upshift as a yield layer on top of this infrastructure.
• No credible sources in the retrieved data report security incidents, insolvencies, or enforcement actions specifically tied to Upshift or August. Not verifiable as of 2026-08-29 for more exhaustive checks. Public vs anon; credibility signals
• Founders use real names, public profiles (LinkedIn, X) and appear regularly in media, podcasts and industry events, which is consistent with non-anonymous, reputationally anchored leadership.
• Upshift’s X account lists institutional backers including Dragonfly and 6th Man Ventures, which are known venture investors in crypto, giving some external credibility. Real office, onshore/offshore, business vs web-front
• The available data strongly indicates a real operating business (August + Upshift) serving institutional clients and powering multi-chain DeFi vaults.
• Exact registered entity name, jurisdiction, and office address are Not verifiable as of 2026-08-29 from independent sources in the retrieved data.
• No independent regulatory filings, licenses, or court/regulator records were surfaced; therefore the protocol’s regulatory posture and domicile remain unverified. Reality check
• Upshift is best characterized as a venture-backed, institution-facing DeFi yield protocol spun out of August, led by identifiable, experienced founders with prior institutional crypto careers.
• However, corporate/legal details, office, and comprehensive regulatory status remain Not verifiable as of 2026-08-29 and should be treated as key due-diligence gaps for an institutional risk assessment.

Upshift’s public reputation is broadly positive on credibility signals, but it remains an early-stage protocol with unresolved trust and operational risks. Public reporting identifies the founders as Alexandre Elkrief and Aya Kantorovich; Blockworks says both are experienced crypto operators, and a later report says Upshift/parent August raised $10 million led by Dragonfly, with participation from Hack VC, 6th Man Ventures, Robot Ventures and others. On security, Upshift says its vault contracts have been audited by Hacken, ChainSecurity, Sigma Prime, and Zellic, and its docs claim multiple audits plus independent NAV validation and monitoring. That is a positive signal, but the claims are primarily protocol- and sponsor-sourced unless corroborated by the audit PDFs themselves; I could not independently verify audit scope or findings beyond the references surfaced here. The main negative sentiment found is not a proven exploit or insolvency allegation against Upshift itself, but a separate late-2026 report that an exploit affecting a LayerZero-powered Kelp DAO bridge caused emergency freezes across several lending markets, including Upshift. That indicates exposure to external protocol risk, not necessarily misconduct by Upshift. I did not find credible evidence in the gathered sources of a confirmed rug pull, fraud case, insolvency event, or sanctions/regulatory action specifically against Upshift. One third-party post explicitly claims prior fraud allegations were debunked and says no FCA warning was found for upshift.finance, but that source is not authoritative and should be treated cautiously. Upshift’s own FAQ also says it is not available to U.S. users, implying jurisdictional caution rather than a legal action. Unresolved concerns are typical DeFi ones: reliance on curators, multisig/governance complexity, dependency on third-party infrastructure, and the fact that several positive claims about transparency and risk controls are still unverified marketing claims absent on-chain or regulator-grade confirmation.

Upshift’s publicly available docs describe a non-custodial vault system and a multi-asset vault model, but they do not provide a protocol-wide treasury or reserve disclosure with a size, wallet list, composition breakdown, custody map, or reserve policy in the materials reviewed. The docs state that users maintain control over their assets in the vault structure, and that multi-asset vaults accept multiple ERC-20 deposits while withdrawals are settled in a single reference asset, but this is product design rather than a treasury attestation. What is verifiable from the available sources is limited to product architecture: Upshift is an operating system for institutional onchain asset management, with V1 single-asset ERC-4626 vaults and V2 multi-asset vaults. However, no source here discloses the protocol’s own reserves, treasury addresses, or on-chain balances across Ethereum, Hyperliquid L1, or Monad. Not verifiable as of 2026-08-29. I also found a third-party post mentioning a “USDC reserve pool” for a specific Upshift Clear redemption flow, but it appears to describe a product-level redemption pool for a partner workflow, not a protocol treasury disclosure; it should not be treated as proof of Upshift’s overall reserves.

Based on currently available off-chain data, Upshift does not have a live native protocol token on Ethereum, Hyperliquid L1, or Monad as of 2026‑08‑29.

• A 2025 analysis explicitly states that Upshift Finance has not issued its native governance token.
• Public protocol overviews (DefiLlama, Alchemy dApp listing, MrDeFi) describe Upshift as a multichain yield / vault platform with TVL on Ethereum, Hyperliquid and others, but do not list any native token (no ticker, no token contract, no market cap/FDV entry), which is atypical if a token were live.
• Upshift’s own docs and app front‑end describe vault share tokens (ERC‑4626 receipt tokens like coreUSDC, multi‑asset vault LP tokens, etc.), but not a protocol governance/utility token. There is a private/working “tokenomics” draft circulating for SHIFT / stSHIFT (utility + staking/governance design, emissions to LPs, stSHIFT voting on emission weights, 7‑day unbonding), but it appears as an internal Notion document, not an implemented on‑chain system. Because there are no corroborating explorer records (no verified SHIFT contract, no exchange listings, no circulating‑supply or market‑cap data, no unlock transactions), this must be treated as a design proposal, not an active token. Given that:
• Native token name/ticker & contract: Not live; no verifiable on‑chain token contract for a protocol token on Ethereum, Hyperliquid L1, or Monad. Any SHIFT/stSHIFT design is pre‑launch and unconfirmed.
• Total vs circulating supply; market cap & FDV: Not applicable; no launched token, no reliable circulating supply or valuation.
• Token utility, governance, revenue share, buybacks, burns, staking rewards: Only described at the design level (SHIFT emissions to LPs; stSHIFT for governance/emissions voting) in internal materials; not verifiable as of 2026‑08‑29.
• Emissions / unlock schedule; team/investor/treasury/community allocations; insider wallets; mint/blacklist/fee‑switch: Not verifiable as of 2026‑08‑29. No public token smart contract or unlock transactions to analyze.
• DEX liquidity, listings: No evidence of a traded Upshift native token on major DEXes/CEXes; analytics dashboards and listings focus on Upshift vaults, not a governance/utility token. For now, the only tokens directly tied to Upshift that can be described are vault share / receipt tokens per vault (e.g., coreUSDC on Ethereum), each with its own ERC‑20‑like contract, but these are product‑level tokens, not a protocol‑wide native token. If a native token launches later, all above items (supply, unlocks, insider allocations, control functions, liquidity) would need to be re‑evaluated against on‑chain data. Currently, they are Not verifiable as of 2026‑08‑29.

A Bitcoin move below $10,000 would be a severe tail-risk stress for any BTC-linked or BTC-collateralized Upshift vault; Upshift’s own documentation says vaults use a configurable withdrawal liquidity buffer, NAV volatility protection, and an emergency multi-sig pause/migration function designed to handle volatility, oracle issues, and rapid redemptions. However, the provided sources do not identify Upshift’s actual live vault exposures, collateral composition, chain-specific AUM, or whether any current strategies are directly exposed to BTC, so the protocol-specific loss estimate is Not verifiable as of 2026-08-29.

Not verifiable as of 2026-08-29 10:25 UTC. The available sources identify Upshift as a multi-chain institutional DeFi vault protocol and confirm that its risk framework includes a configurable withdrawal liquidity buffer, but they do not provide enough on-chain or vault-level exposure data to calculate the loss impact of a 20% depeg in the largest collateral asset. The web results also do not establish which specific collateral is the largest across Ethereum, Hyperliquid L1, and Monad, nor the share of TVL exposed to it, so any numeric stress loss would be speculative. What can be said from the sources is limited to qualitative risk controls: Upshift documents a non-custodial architecture and a withdrawal liquidity buffer intended to support redemptions without forcing strategy unwind. One third-party article also notes that vault automation includes depeg-risk monitoring. However, neither source quantifies the buffer size, collateral composition, or chain-by-chain exposure needed for a credible 20% collateral-depeg stress test. If you want, I can next produce a *qualitative* stress assessment template for Ethereum, Hyperliquid L1, and Monad that lists the exact data points needed to turn this into a quantified scenario.

For a top-counterparty insolvency event, Upshift’s loss path appears to be strategy-level first, then vault NAV, then users via lower share value / delayed redemption, but the exact chain-by-chain contract flow is Not verifiable as of 2026-08-30. The docs state that funds move only between the vault and whitelisted strategy contracts, that a configurable withdrawal liquidity buffer is maintained, and that NAV volatility protection caps share-price movement; they also say curators/ops monitor counterparty risk and react to alerts.

• Expected loss path: if a borrower, venue, or strategy counterparty becomes insolvent, the immediate economic loss is borne by the affected strategy position, reducing the vault’s asset value.
• Who absorbs it first: the vault and its LP/shareholders absorb the mark-to-market loss through a lower NAV/share price; there is no evidence in the sources of an external backstop or insurance layer at protocol level.
• Compensation / mitigation: the only explicit mitigants found are the liquidity buffer for redemptions and NAV guardrails that slow sudden changes; these can smooth withdrawals and limit update spikes, but they do not create principal compensation.
• Impact through smart contracts: the documented flow is vault whitelisted strategy contracts redemption module; under stress, the buffer can satisfy some withdrawals, while the keeper processes available redemptions and the remaining exposure stays trapped until the strategy is unwound or value recovers. Chain notes: Upshift says it supports Ethereum, HyperEVM, and Monad among other chains, but the web results do not provide chain-specific insolvency waterfall terms for each of the three requested chains, so per-chain loss-sharing details are Not verifiable as of 2026-08-30.

For the DAO/owners committed fraud stress scenario, I found no verifiable evidence in the provided web results that Upshift’s DAO or owners have committed fraud. The strongest available source is Upshift’s own Terms of Use, which describe the protocol as open-source smart contracts with Vaults managed by third-party strategy managers, but that is not evidence of fraud or innocence. There is one audit finding showing a technical vulnerability in an Upshift Solana ERC-4626 vault: the report says the vault is vulnerable to the ERC-4626 inflation/donation attack, which could let an attacker skew share calculations and drain victim deposits. That is a smart-contract risk, not proof that the DAO or owners committed fraud. A Binance Square post claims earlier fraud allegations were debunked and says no FCA warning for the protocol was found, but this is an independent media/analysis claim and not authoritative enough to settle the issue on its own. Assessment: committed fraud by the DAO or owners = Not verifiable as of 2026-08-29. The evidence currently supports a scenario of possible smart-contract exploitation or operational failure, not confirmed fraud by governance or owners.

Upshift’s primary yield source can be negative over a 30-day window if the underlying strategy’s carry turns adverse; for example, the protocol’s own materials note that funding-rate strategies lose money when funding turns negative, and liquidity provision can also be negative against hold. However, for Upshift’s current vaults I could not verify on-chain or independently confirm the actual 30-day yield inputs for Ethereum, Hyperliquid L1, or Monad, so the precise stress outcome is Not verifiable as of 2026-08-29. The clearest risk implication is that a negative 30-day primary yield usually signals fee, spread, or funding drag at the strategy level rather than an immediate linear principal loss, but the magnitude and persistence depend on the vault’s exact allocation mix and leverage. Upshift’s own documentation says its vault yield comes from real yield, protocol rewards, and yield tokenization, and its strategy blog explicitly notes that lending, funding, and LP strategies have distinct downside modes.

Upshift governance is partially decentralized but remains materially team-controlled, with limited verifiable detail on-chain. 1. Core control (contracts, frontend, funds)

• Smart contracts and protocol parameters are controlled by the Upshift multisig / core team; multiple sources describe Upshift as a “team-driven” perp protocol with an active core dev group, not a fully autonomous DAO.
• Exact ownership structure of Ethereum / Hyperliquid L1 / Monad contracts (proxy admins, upgrade rights) is Not verifiable as of 2026-08-29 due to lack of accessible verified-contract data tied to Upshift and missing Dune on-chain queries.
• Frontend hosting (domain, servers) is Not verifiable as of 2026-08-29; standard pattern for similar perp protocols suggests company-controlled web infrastructure, but this is inference, not evidence. 2. Governance mechanism & DAO reality
• No independent documentation (auditors, governance forums, analytics) shows a robust, on-chain proposal system (e.g. Governor-style contracts, executable proposals) for Upshift.
• Public references frame Upshift more as a protocol with a token than a mature on-chain DAO; governance appears symbolic/limited rather than fully controlling contracts.
• Without confirmed governance contracts or proposal archives, the effective DAO power is Not verifiable as of 2026-08-29. 3. Voting concentration & top holders
• There are no reliable Dune dashboards or explorer-based holder analyses specifically attributable to Upshift’s token that can be confirmed as this protocol rather than a namesake.
• As a result, token distribution, top holders, and voting concentration are Not verifiable as of 2026-08-29. 4. Multisig, timelock, signers, powers
• No independent disclosures (audits, DeFiSafety-style reports, bug bounty docs) provide multisig addresses, signer identities, thresholds, or timelock parameters for Upshift that can be matched to known contracts.
• Therefore: multisig composition, independence, and timelock use are Not verifiable as of 2026-08-29. 5. Legal entity & ToS
• Web search does not surface a clearly identified operating company (name, jurisdiction, registration number, directors) for Upshift in reputable registries or legal disclosures.
• No independently archived Terms of Service could be confirmed as belonging to this protocol rather than unrelated "Upshift" entities.
• Consequently, legal entity details and ToS are Not verifiable as of 2026-08-29. Overall, from an institutional risk perspective, Upshift should be treated as opaque governance / team-controlled until verifiable contract admins, multisig details, and a real on-chain proposal system are disclosed and independently validated.

Upshift’s legal posture is BVI-based: its Terms of Use say disputes are governed by British Virgin Islands law, litigation is exclusively in BVI courts, and notice is addressed to Trinity Chambers in Road Town, Tortola. The terms also state the Services are not offered to U.S. residents and bar users prohibited under BVI law or other applicable jurisdictions; the privacy policy says the services cover the platform/UI, API, and related sites, and provides a contact email for privacy questions. Upshift’s FAQ says partners can impose KYC requirements and wallet screening, and that vault mandates are restricted to on-chain policies; it also describes vault operators as KYC’d institutional yield managers, indicating a compliance-oriented operating model rather than permissionless retail access. I did not find verifiable evidence of public enforcement actions, court cases, or sanctions specifically naming Upshift as of 2026-08-30; Not verifiable as of 2026-08-30. The main regulatory risk is structural rather than case-specific: the protocol’s own legal terms and compliance controls suggest a centralized service wrapper around on-chain activity, so the practical risk is that users may face jurisdictional restrictions, geofencing, KYC/KYB, AML/sanctions screening, and potential loss of access if compliance policies change. Any claim that Upshift itself has a formal licensed entity beyond the BVI terms is Not verifiable as of 2026-08-30.

Not verifiable as of 2026-08-29. The provided search results do not identify which stablecoin Upshift used, and I cannot confirm any depeg history for the protocol’s specific stablecoin from the available sources. The results only discuss depegs of unrelated stablecoins such as USDC, USDT, UST, FDUSD, and sUSD, which are not evidence about Upshift’s treasury or collateral token. If you want, I can help check the specific stablecoin once you provide its ticker or contract address.

Top 5 protocol risks for Upshift are: 1) Counterparty/strategy risk — vault returns depend on external DeFi strategies and institutional borrowers; a strategy exploit or borrower default can impair vault assets. 2) Smart contract risk — the vault, share-accounting, withdrawal, and whitelist logic can still contain bugs despite a template-based design. 3) Centralization/operational risk — a small set of managers plus multisig/emergency controls means key-person failure, misconfiguration, or compromise can halt or redirect protocol operations. 4) Oracle/NAV manipulation risk — NAV updates rely on price and share-to-asset calculations, and Upshift explicitly uses max-change constraints to mitigate faulty feeds and latency arbitrage, which indicates this remains a relevant risk surface. 5) Liquidity and market risk — redemptions may face delays or losses if buffers are insufficient or underlying positions are illiquid during stress.

Upshift’s main strengths are its institutional-grade vault infrastructure, broad multi-chain and multi-strategy coverage, strong composability via ERC-4626 vaults, risk controls, and non-custodial / transparent design. The strongest verifiable points from the sources are: 1) it positions itself as an operating system for institutional onchain asset management, 2) it supports vaults across 30+ chains and 70+ protocols, including both DeFi and CeFi strategies, 3) its vaults are built on ERC-4626 and are designed to be modular and integrable, 4) it includes explicit risk controls such as whitelisted strategies, withdrawal buffers, NAV-volatility protection, timelocks, and emergency pause functions, and 5) it states that funds remain non-custodial and that users can view strategy allocations onchain in real time. A practical fifth strength is its claimed “prime stack” / distribution layer, which the protocol says helps reach institutional LPs and supports faster vault distribution, though this is a protocol claim rather than independently verified on-chain data.

• Institutional focus: built for professional asset management, not just retail yield.
• Multi-chain breadth: vaults can be deployed across 30+ chains and 70+ protocols, which widens sourcing opportunities.
• Strategy flexibility: combines DeFi and CeFi strategies in a single vault architecture.
• Composable vault standard: ERC-4626 makes vault shares easier to integrate with other DeFi systems.
• Risk management: whitelisted contracts, buffer liquidity, timelocks, and emergency controls are explicit design features.