ZEROBASE CeDeFi

Not verifiable as of 2026-08-29: I was unable to reliably identify a DeFi protocol called ZEROBASE CeDeFi with slug zerobase-cedefi across Arbitrum, BSC, Base, Ethereum, Optimism, and Polygon using independent sources. Given the constraints (no Dune, only web search) and the name-collision rule, I must avoid guessing based on potentially unrelated or marketing-only references. The following key elements therefore remain not verifiable:

• Canonical protocol identity (brand, website, docs)
• Category / product type (e.g., yield aggregator, lending, CDP, CeDeFi hybrid, etc.)
• Launch date
• Confirmed chain deployment set (Arbitrum, BSC, Base, Ethereum, OP, Polygon)
• Native token (ticker, contract addresses, tokenomics)
• Main protocol contract addresses on each chain, including their verification status on explorers
• Fork lineage (whether ZEROBASE CeDeFi is a fork of a known protocol, what was modified vs. upstream, and whether those changes were audited)
• History of malicious or risky modifications in similar forks of the same upstream codebase Because contract addresses and chain deployments cannot be tied unambiguously to this specific protocol, I would risk mixing in phishing/clone contracts or entirely different projects, which violates the name-collision and evidence standards. Without at least two independent sources confirming the same addresses and basic metadata, no on-chain–level identification is defensible. Key risk-analyst takeaways, given the non-verifiability:
• Treat any TVL, yield, or security claims made only on self-hosted sites or social channels for “ZEROBASE CeDeFi” as unverified marketing claims.
• Do not rely on this protocol for institutional exposure until you have:
• Confirmed contract addresses per chain directly in explorers (Etherscan, BscScan, Arbiscan, Basescan, Polygonscan, Optimistic Etherscan) and
• At least one independent analytics platform (e.g., DeFiLlama, Token Terminal) tracking it under the same identity.
• Absence from major analytics and audit platforms is itself a red flag for institutional risk mandates. If you can supply a specific contract address or official URL known to be associated with ZEROBASE CeDeFi, I can rerun identification focused on that anchor (still without Dune, but with explorers and analytics) and give you a crisper protocol profile within the same methodology.

ZEROBASE CeDeFi appears to be a real, active product rather than only a static landing page: its main site and docs are live, the docs include a staking user guide with connect-wallet, deposit, and withdraw flows, and the protocol’s published API documentation includes programmatic endpoints for proof-generation and node discovery. The product page also references a staking layer with deposit/withdraw functionality and a 14-day redemption path plus a flash-withdraw option, which is consistent with an operational app rather than a brochure-only site. That said, maturity is not fully verifiable from the available web evidence alone. The search results do not confirm in-browser execution of deposits/withdrawals, nor do they verify whether every chain listed in the protocol profile is live and supported in the UI; those parts should be treated as not verifiable as of 2026-08-29. I also did not find web evidence of major broken-link issues, template reuse, or clearly fake metrics in the pages returned, so those concerns are not verifiable from the current evidence set. On API availability, the protocol does appear to have an open/public API surface: the docs expose proof-network endpoints and even show example requests such as a GET to a hub node endpoint, which is enough to say an API is documented and externally callable in principle.

OpenZeppelin audited a ZeroBase token / cross‑chain economics codebase. The public summary states audit type cross-chain, language Solidity, timeline Aug 6 2025 → Aug 6 2025. Scope: the ZeroBase-Pro/Economics repository at commit 3c55c3f; the set of in‑scope files is listed in the report. Findings summary: total 13 issues (10 resolved, 2 partially resolved), with severity split: 0 critical, 0 high, 0 medium, 3 low (2 resolved, 1 partially resolved); plus 10 notes (8 resolved, 1 partially resolved). By OpenZeppelin’s own summary, all significant severity levels (critical, high, medium) are absent, but several low‑severity and informational issues remain only partially remediated. This audit focuses on the token/economics code, not explicitly on the vault contracts that hold user assets on Arbitrum, BSC, Base, Ethereum, OP, Polygon. Whether all current token/economic contracts on those chains match the audited 3c55c3f commit is Not verifiable as of 2026-08-29 without bytecode comparison.

PeckShield audited Zerobase Staking / ZeroBase Vault v1.0 smart contracts, described as Ethereum smart contracts written in Solidity for the Zerobase staking system. Scope is the staking/vault contracts (ZKFi v1.0) with whitebox review, static analysis, semantic checks, and DeFi logic review. The report notes the contracts are generally well engineered but lists several issues, including 3 medium‑severity vulnerabilities; no critical or high findings are mentioned in the exposed snippet. Detailed issue list and fix status (whether each medium finding is fully remediated) are only visible inside the full PDF and Not verifiable as of 2026-08-29 from the provided excerpt. The audit predates later Salus V1/V2 reviews and appears focused on early staking/vault code; it does not explicitly state that it covers all currently deployed contracts across Arbitrum, BSC, Base, Ethereum, OP, Polygon. Without on‑chain bytecode matching, whether the audited commit/bytecode equals currently deployed contracts on each chain is Not verifiable as of 2026-08-29.

Salus audited ZeroBase – Vault v1 contracts. The report is dated Dec 24 2024 with assessment logs from Dec 16 and Dec 24 2024. Scope: ZeroBase Vault v1 Solidity repository at commit acc403f, with specific files and SHA‑1 hashes listed in the report; objective was to identify security issues, code quality, and adherence to specs and best practices. Findings summary: 0 high‑severity, 1 medium‑severity, 0 low‑severity, 1 informational issue. The detailed description and remediation status of the single medium‑severity issue are inside the PDF and Not verifiable as of 2026-08-29 from the snippet. The report does not state chain coverage; given the shared vault address across Ethereum, BSC, Polygon, Arbitrum, AVAX‑C, OP, Base noted in project GitHub/docs, it is plausible but not confirmed that this vault implementation is reused multi‑chain. Without on‑chain bytecode comparison for each chain, whether the audited commit matches live vault contracts on Arbitrum, BSC, Base, Ethereum, OP Mainnet, Polygon is Not verifiable as of 2026-08-29.

Salus performed a later audit of ZeroBase – V2 contracts. The certificate states name “ZeroBase – V2”, version v2, Solidity code, with logs on Aug 22 2025 and Sep 16 2025 and audit date Sep 16 2025. Scope: ZeroBase V2 repository (files listed in Appendix‑1), focusing on security, code quality, and best‑practice adherence. Vulnerability summary: 0 high, 0 medium, 3 low‑severity, 2 informational issues (total 5). One of the low‑severity items is explicitly a centralization risk. The report does not enumerate per‑issue fix status in the visible snippet; overall remediation status is therefore Not verifiable as of 2026-08-29. It is not clearly stated whether V2 fully replaces V1 vault logic or only some components, nor whether all live contracts on Arbitrum, BSC, Base, Ethereum, OP, Polygon use this exact V2 bytecode. Without on‑chain confirmation, coverage of currently deployed CeDeFi yield contracts is Not verifiable as of 2026-08-29.

Salus also audited ZEROBASE – ZBT v2 (likely the ZBT token/economics contracts rather than the vault). The certificate notes name “ZEROBASE – ZBT”, version v2, Solidity, with logs and audit date Sep 17 2025. Scope: ZeroBase ZBT v2 repository (file list in Appendix‑1), again targeting security issues, quality, and best practice adherence. Findings: 0 high‑severity, 1 medium‑severity, 1 low‑severity, 4 informational issues (total 6). The medium issue relates to possible breach of SUPPLY_CAPD restrictions. The snippet does not show explicit remediation outcomes; full fix status per issue is therefore Not verifiable as of 2026-08-29. This audit focuses on the ZBT token/economic logic rather than the multi‑chain vaults used for CeDeFi yield. Whether the audited ZBT v2 contracts are those currently deployed on each supported chain (Arbitrum, BSC, Base, Ethereum, OP, Polygon) is Not verifiable as of 2026-08-29 without on‑chain bytecode matching.

I could not verify an active bug bounty program for ZEROBASE CeDeFi from the provided web results. The search results show general bug-bounty platforms and unrelated programs, but none that can be confidently matched to this protocol after a name-collision check, so the correct status is Not verifiable as of 2026-08-29. Because the program itself is not verifiable, its start date, scope/parameters, and disclosed results are also Not verifiable as of 2026-08-29. What I can say from the available sources is only that:

• HackenProof and Immunefi host many Web3 bug bounty listings, but the snippets provided do not identify ZEROBASE CeDeFi specifically.
• The other results are clearly unrelated protocols or generic bounty pages, so they do not establish a bounty for ZEROBASE CeDeFi. If you want, I can help you do a tighter source-by-source verification checklist for ZEROBASE CeDeFi across HackenProof, Immunefi, GitHub, and governance records.

ZEROBASE CeDeFi’s main counterparty dependency is centralized-exchange basis trading: independent analysis says user stablecoins are deployed to Binance for execution, so users bear exchange custodial/solvency risk rather than purely smart-contract risk. ZEROBASE’s own materials also state that prover-node staked stablecoins are used for trading arbitrage via CEFFU, indicating additional dependency on a centralized execution venue/custodian path. The project’s white paper and MiCA paper explicitly acknowledge third-party service provider risk, including trading platforms and custodians, where failure or insolvency can impair access or recovery. The protocol also carries strategy risk: returns depend on basis-trading/perpetual funding conditions, and independent coverage notes that negative funding regimes can turn yield adverse or cause losses. Its ZK verification helps attest to trading activity, but it does not remove the underlying CEX/venue risk. For oracle/manipulation risk, the available sources do not identify a meaningful on-chain price-oracle dependency for the core vault logic; ZEROBASE’s disclosed model is centered on off-chain trading plus ZK proofs, so the dominant manipulation vector is execution/settlement at the exchange rather than oracle manipulation. Not verifiable as of 2026-08-29. For bridges, I found supported deployment across Ethereum, BSC, Polygon, Arbitrum, OP Mainnet, and Base, but no independent disclosure of a material bridge/cross-chain dependency beyond multichain deployment. Not verifiable as of 2026-08-29. For RWA issuer/SPV, I found no verified RWA issuer or SPV dependency. Not verifiable as of 2026-08-29. For stablecoin/LST/restaking exposure, ZEROBASE’s user-facing staking flow is stablecoin-based (e.g., USDT/USDC), and the protocol’s risk is therefore tied to the solvency and redemption quality of those stablecoins as well as the centralized trading venue. I found no verified LST/restaking dependency. Not verifiable as of 2026-08-29. Failure/depeg/insolvency scenarios: Binance/venue insolvency or withdrawal restrictions; prolonged negative funding leading to capital erosion; stablecoin depeg or issuer freeze/redemption failure; and a failure of the ZK proof/ops stack to correctly attest positions or strategy state.

ZEROBASE CeDeFi’s custody appears to be organized as a hybrid model: user funds are deposited into ZEROBASE vault/staking contracts, but the yield layer relies on Ceffu (Binance Custody) and Binance-linked execution for CeFi strategies. The protocol’s own materials say users’ stablecoins are collected through a distribution platform such as Binance, the issuer does not directly custody proceeds, and ZEROBASE partners with Ceffu for enterprise custody/liquidity; a third-party analysis also says user stablecoins are deployed to Binance, implying centralized-exchange counterparty exposure. In practice, that means custody is not purely self-custodial on-chain. Users may hold LP tokens or staking claims on-chain, while the underlying assets are handled through Ceffu/Binance custody and exchange infrastructure for basis trading and related yield generation. The exact custody split across Arbitrum, BSC, Base, Ethereum, OP Mainnet, and Polygon is not verifiable as of 2026-08-29 from the available sources, and the sources do not provide chain-by-chain custody segmentation.

For ZEROBASE CeDeFi, the public materials do not clearly describe a dedicated key-management model for user or protocol operational keys, so the answer is Not verifiable as of 2026-08-29. The available documentation instead describes a TEE + ZK architecture: off-chain computation runs in trusted execution environments, while on-chain zero-knowledge proofs verify results without exposing sensitive inputs. The whitepaper also says the network uses Hub nodes to organize and route Worker nodes in subnets, but it does not explain how private keys are generated, stored, rotated, or shared for vault control, signer duties, or admin access. The most that can be inferred is that sensitive computation is intended to occur inside TEEs, which reduces key exposure risk, but that is not the same as a documented key-management scheme.

ZEROBASE CeDeFi appears to be a small, multi‑chain yield protocol; however, most of the required smart‑contract/admin specifics are not verifiable as of 2026‑08‑29 because Dune/on‑chain tooling is unavailable and independent documentation is extremely thin. ## 1. Contract discovery & verification

• Public registries (DeFiLlama, explorers, general web search) surface ZEROBASE mainly as a CeDeFi yield / staking product but do not provide a clear, consistent set of core contract addresses across Arbitrum, BSC, Base, Ethereum, Optimism, Polygon.
• Several “ZeroBase” / “ZeroBase Finance” contracts exist on BSC and Ethereum, but mapping them confidently to ZEROBASE CeDeFi (slug zerobase-cedefi) is not verifiable as of 2026‑08‑29 due to name collisions and missing canonical address lists.
• As a result, status of verified vs unverified source code on each chain cannot be safely attributed to this specific protocol. ## 2. Upgradeability, proxies, and admin roles Because core contract set cannot be reliably established, all of the following are Not verifiable as of 2026‑08‑29:
• Use of proxy patterns (EIP‑1967 / Transparent / UUPS) and who controls ProxyAdmin.
• Specific owner/admin/emergency roles, including:
• pause / unpause
• upgrade implementation
• fee configuration
• oracle / strategy management
• withdrawal gates.
• Whether any roles have been renounced.
• Existence and on‑chain delay of timelocks for upgrades or parameter changes. Any protocol statements about “non‑custodial, immutable, trustless, permissionless” behavior must therefore be treated as unverified marketing claims as of 2026‑08‑29. ## 3. User exit conditions & worst‑case key compromise Given the missing contract‑level detail, the following cannot be established on-chain for ZEROBASE CeDeFi:
• Whether users can always exit solely via public functions without cooperative admin actions.
• Whether an admin can:
• freeze deposits/withdrawals,
• move funds to arbitrary addresses,
• change strategies/oracles in ways that expose users to loss.
• Presence/absence of circuit‑breaker mechanisms or forced‑exit paths. Therefore, from an institutional risk perspective, you must assume full spectrum CeDeFi key risk until proven otherwise:
• If privileged keys are compromised or misused, rug/freeze scenarios (forced migration of assets, disabling withdrawals, fee hikes, hostile upgrades) are plausible in the absence of verified constraints. ## 4. Architecture map (conceptual only) Because contract addresses/ABIs are not reliably known, a precise architecture diagram (core vaults → strategy contracts → admin/timelock → fee/oracle modules) is Not verifiable as of 2026‑08‑29. For any mandate, ZEROBASE CeDeFi should be treated as high, unquantified smart‑contract & admin risk until:
• canonical addresses per chain are independently confirmed, and
• explorer / audit / on‑chain role analysis can be completed.

ZEROBASE CeDeFi appears to be a CeDeFi product built on top of the broader ZEROBASE proving network, with limited, fragmented disclosure about legal entities and team structure. Founders are partially public, but the overall setup is closer to a lean, offshore crypto infrastructure company than a fully transparent regulated financial institution. ### Founders & Core Team

• Multiple independent sources state that ZEROBASE was founded by Mirror (Tang Ming) Tang, a cryptography professor at Shanghai Jiao Tong University, specializing in blockchain cryptographic engineering and security.
• Bitget and Binance Square profiles describe Mirror Tang as CEO and co‑founder, leading an ~8‑person core team with several years of ZK and cryptography experience.
• RootData lists a broader leadership group: Mirror Tang (Co‑founder & CEO), Koppany Smith (COO), Constantin Gao (Head of Governance), Jacky Cao (VP Ecosystem Strategy), Gink Chen (Head of Foresight).
• Yellow’s asset profile for ZEROBASE’s ZBT token refers to a Cayman Islands entity Vortex Tech Ltd. as the operating company and again names Xueyan “Mirror” Tang as CEO, plus Koppany Smith (COO) and Li Chen (CMO). ### Prior Track Record & Associations
• The team originates from the Salus Security Cryptography Security Group, which reportedly contributed cryptography solutions to the Ethereum Foundation’s PSE team. This is a positive signal of technical credibility but is not on‑chain verifiable here (*Not verifiable as of 2026‑08‑29*).
• Public materials and media coverage focus on ZK infrastructure, proof‑as‑a‑service and CeDeFi arbitrage; no prior major protocol hacks or catastrophic failures are mentioned in the aggregated profiles or risk analyses (*Not verifiable as of 2026‑08‑29*). ### Public vs Anon, Office, Jurisdiction
• Key leadership (Mirror Tang, Koppany Smith, Constantin Gao, others) are publicly named with academic and professional backgrounds, not pure pseuds.
• The listed operating entity Vortex Tech Ltd. in the Cayman Islands implies an offshore corporate structure, typical for crypto infrastructure and CeDeFi projects. Whether there is a physical office presence in mainland China, Hong Kong, or elsewhere is Not verifiable as of 2026‑08‑29.
• There is no clear evidence of a regulated, onshore financial‑services license attached specifically to ZEROBASE CeDeFi (*Not verifiable as of 2026‑08‑29*). ### Reality Check: Real Business vs Web Front
• Multiple independent sources (Bitget, Gate, Binance, RootData, risk‑rating sites) describe actual infrastructure (decentralized proving network) and CeDeFi basis‑trading yields on centralized exchanges, not just marketing copy.
• However, full corporate structure, board, audited financials, and detailed operational controls for ZEROBASE CeDeFi are not publicly documented in accessible third‑party records (*Not verifiable as of 2026‑08‑29*).
• For institutional risk purposes, this should be treated as a technically credible but governance‑opaque, offshore CeDeFi operation, with concentration of control around a small founding team and limited formal transparency.

ZEROBASE CeDeFi appears to have a generally *positive-to-mixed* reputation: public materials describe it as founded by Mirror Tang (also referenced as Xueyan Tang) and linked to Salus Security, with reported backers including Binance Labs/YZi Labs, Lightspeed Faction, dao5, Matrix Partners, IDG, and Symbolic Capital. Audit coverage is presented as relatively strong for a young protocol: Salus and PeckShield are cited for zkStaking/vault audits, and OpenZeppelin is cited for the ZBT token audit, with marketing claims that no critical issues remained after remediation. Independent sentiment is more cautious than promotional materials. A third-party risk write-up labeled ZEROBASE CeDeFi “Moderate Risk” and highlighted counterparty risk from exchange dependency and the novelty of the ZK verification design. DeFiLlama lists the protocol and shows audits, but that is an aggregator signal rather than proof of security. I did not find credible, independent evidence of fraud, a rug pull, insolvency, sanctions, or active regulatory enforcement specific to ZEROBASE CeDeFi in the retrieved material. However, several claims about investors, grants, and technical performance are sourced from the project itself or reposted secondary marketing coverage, so they remain *unverified marketing claims* unless independently corroborated. Unresolved concerns: centralized-counterparty exposure, the short operating history, and the fact that much of the public narrative is still company-led rather than fully independently documented.

ZeroBase CeDeFi appears to be a small, multi‑chain yield protocol, but available information is sparse and often marketing‑heavy. Most requested metrics are Not verifiable as of 2026‑08‑29 due to lack of reliable independent data. ### 1. Strategy & Assets

• Positioning: Markets itself as a CeDeFi yield platform combining centralized and DeFi yield strategies on Arbitrum, BSC, Base, Ethereum, Optimism, Polygon.
• Products: References staking and “vault”‑style yield products for stablecoins and major tokens, but specific contract architectures, strategies (e.g., lending, LP, delta‑neutral), and asset lists are not clearly documented in independent sources.
• Because underlying positions and on‑chain strategies are not disclosed in detail outside the project’s own docs, they are unverified marketing claims. ### 2. Yield Source & Risk Profile
• Yield drivers (lending interest, trading fees, farming rewards, centralized yield, etc.) are not broken out in independent analytics.
• No clear evidence of whether strategies are market‑neutral vs. directional, or whether they rely on leverage, looping, restaking, or external CeFi exposure. Not verifiable as of 2026‑08‑29. ### 3. Lock‑ups, Withdrawals, Fees
• Some products mention fixed‑term staking with early withdrawal penalties on marketing pages.
• Detailed withdrawal mechanics, gates, limits, and fee schedules (management, performance, exit fees) are only described by the protocol itself and thus count as unverified marketing claims. ### 4. Collateral & Risk Controls
• No independent breakdown of collateral types, LTVs, liquidation mechanisms, or counterparty exposure.
• No third‑party descriptions of risk controls (e.g., caps per vault, pause/kill switches). Not verifiable as of 2026‑08‑29. ### 5. TVL, APY, Revenue
• DeFiLlama lists a small TVL for “ZeroBase CeDeFi” across multiple chains, but contracts are only partially mapped, and methodology is unclear.
• Total TVL, TVL by product, and by chain, as well as trends, cannot be cross‑checked on‑chain here → Not verifiable as of 2026‑08‑29.
• No independent view of protocol revenue (fees actually accrued vs. distributed).
• APY figures shown in dashboards are marketing/aggregator estimates; no historical APY series or volatility analysis from independent sources. Not verifiable as of 2026‑08‑29. ### 6. Overall Economic Model Assessment
• Economic model is opaque: yield sources, risk profile, and revenue splits are not documented with independent, chain‑level data.
• Reliance on protocol‑provided dashboards and CeDeFi framing, without audits focused on economics, implies high information risk for institutional allocators.

ZEROBASE CeDeFi’s public treasury/reserve picture is only partially verifiable from the web. The strongest source says the protocol’s DAO treasury received a $1,000,000 USDT deposit and that the funds support operations, ecosystem growth, ZK development, incentives, partnerships, and events; the treasury address cited there is 0x37Fd0F16FA9c3Dcc802cab1E8819DBc00D626dB8. The protocol’s docs also claim a fixed 20% of network revenues goes to the ZEROBASE Foundation and the remainder to the ZEROBASE DAO treasury, with tokenholders able to vote on buybacks and burns. For reserve size, composition, custody, and control beyond that, Not verifiable as of 2026-08-29. I could not verify on-chain balances, chain-by-chain treasury holdings, or custody controls because the needed on-chain validation layer was unavailable in this run. The protocol repository does state a shared vault address across supported chains as 0x59f6E226a1055D05a9BD07f40AC2aa87e303CC33, and lists Ethereum, BSC, Polygon, Arbitrum, and OP among supported networks; however, this is still protocol-published material and should be treated as unverified until independently checked. No independent attestation of reserves was found in the gathered sources. A DeFi analytics page shows TVL by chain for ZEROBASE CeDeFi, with BSC the largest share, followed by Ethereum, Arbitrum, OP Mainnet, Polygon, and Base, but that is TVL exposure, not treasury assets.

ZEROBASE CeDeFi appears to be a very small or unlaunched project; there is no reliable evidence of an actively traded native token across Arbitrum, BSC, Base, Ethereum, Optimism, or Polygon as of 2026‑08‑30. Because Dune MCP is unavailable this run, all on-chain verification is skipped and any missing on-chain item is reported explicitly. ### Native token & contracts

• Native token: Not verifiable as of 2026‑08‑30.
• Ticker: Not verifiable as of 2026‑08‑30.
• Contract addresses on Arbitrum, BSC, Base, Ethereum, OP Mainnet, Polygon: Not verifiable as of 2026‑08‑30. Public search surfaces only generic references to “ZEROBASE CeDeFi” without matching contract addresses, explorers, Coingecko/CoinMarketCap listings, or established documentation that can be tied definitively to this protocol rather than a namesake or clone. ### Supply, market cap, FDV
• Total supply: Not verifiable as of 2026‑08‑30.
• Circulating supply: Not verifiable as of 2026‑08‑30.
• Market capitalization: Not verifiable as of 2026‑08‑30.
• Fully diluted valuation (FDV): Not verifiable as of 2026‑08‑30. No independent analytics platforms (e.g., DeFiLlama, Token Terminal) show a clear listing for “zerobase-cedefi” with token metrics. ### Token utility, governance, revenue share
• Token utility and governance role: Not verifiable as of 2026‑08‑30.
• Revenue share, buybacks, burns, staking rewards: Not verifiable as of 2026‑08‑30. Any claims that may exist on marketing pages would be unverified marketing claims and cannot be relied upon without on-chain or third‑party confirmation. ### Emissions, unlocks, allocations
• Emissions schedule: Not verifiable as of 2026‑08‑30.
• Unlock schedule and whether unlocks occurred on‑chain: Not verifiable as of 2026‑08‑30.
• Allocations (team/investors/treasury/community): Not verifiable as of 2026‑08‑30. ### Holder concentration & control functions
• Top‑holder concentration / insider wallets: Not verifiable as of 2026‑08‑30.
• Mint / blacklist / fee‑switch functions and their controllers: Not verifiable as of 2026‑08‑30. Without confirmed contracts, any discussion of admin powers or risk controls would be speculative and is therefore omitted. ### DEX liquidity & listings
• Main DEX listings and liquidity depth across Arbitrum, BSC, Base, Ethereum, OP, Polygon: Not verifiable as of 2026‑08‑30. Search across major DEX and token listing aggregators does not show a clearly identified ZEROBASE CeDeFi token pool. Given these gaps, an institutional risk assessment should treat ZEROBASE CeDeFi tokenomics as effectively unknown and high‑risk until verifiable contracts and on‑chain data are available.

ZEROBASE CeDeFi appears exposed to a high-stress BTC drawdown mainly through its basis-trading model: a BTC collapse below $10,000 would likely coincide with negative or highly volatile funding, higher liquidation risk, and weaker user demand for risk assets. A third-party risk review says user stablecoins are deployed to Binance for basis trading, so users bear centralized-exchange counterparty risk, and it explicitly notes that funding rates can turn negative in bear markets, causing capital losses rather than yield. For this stress case, the likely protocol-level effects are:

• Lower or negative yield if perpetual funding stays adverse for an extended period.
• Higher counterparty risk because exposure depends on Binance rather than purely on-chain collateral management.
• Potential TVL pressure / withdrawals as users de-risk from a strategy whose return profile weakens sharply in a crypto crash. What cannot be verified from the available sources is the protocol’s exact chain-by-chain exposure across Arbitrum, BSC, Base, Ethereum, OP Mainnet, and Polygon, or the amount of assets currently at risk on each chain. Not verifiable as of 2026-08-29. In practical terms, a BTC move below $10,000 would likely stress ZEROBASE CeDeFi through funding-rate deterioration, exchange counterparty dependence, and possible liquidity outflows; the on-chain magnitude of that impact is Not verifiable as of 2026-08-29.

A 20% depeg in the largest collateral would be a material stress event for ZEROBASE CeDeFi, because depeg risk is explicitly identified as the primary exposure for its stablecoin pool on Arbitrum, and stablecoin depegs can transmit directly into principal loss and liquidity stress. What I can verify from the available web results is limited: one third-party pool page says the ZEROBASE CeDeFi Arbitrum USDT pool has $7.64M TVL and that the main risk is a depeg of the underlying stablecoin, but I cannot verify chain-by-chain collateral composition or the true largest-collateral asset across Arbitrum, BSC, Base, Ethereum, OP Mainnet, and Polygon from the provided sources. So the stress answer is: if the largest collateral depegs by 20%, the protocol’s exposed asset value would fall by roughly 20% for that collateral sleeve, and the impact on the protocol overall would depend on that asset’s share of total collateral and whether any liquidation, redemption, or withdrawal gates exist; those protocol-specific mechanics are Not verifiable as of 2026-08-29. Because the requested multi-chain exposure is not verifiable from the supplied sources, the prudent institutional risk view is to treat this as a high-severity downside scenario with potential contagion to user withdrawals, LP/share pricing, and any leverage built on top of the affected pool, especially under thin liquidity conditions.

ZEROBASE CeDeFi looks like a small, multi‑chain yield / CeDeFi protocol, but there is no reliable technical documentation, audit set, or clear counterparty map available from independent sources as of 30 Aug 2026. All counterparty/contract mechanics below are therefore scenario templates, not on‑chain verified facts: Not verifiable as of 30 Aug 2026. I’ll assume a typical CeDeFi structure: user deposits into ZEROBASE smart contracts, which route funds to off‑chain/centralized venues or on‑chain yield strategies across Arbitrum, BSC, Base, Ethereum, Optimism, Polygon. ### 1. Centralized exchange / broker insolvency (top CeFi counterparty)

• Loss path:
• ZEROBASE contract → custodial wallet at CEX.
• CEX enters insolvency; assets frozen, haircut in bankruptcy.
• Smart contracts remain solvent technically but cannot pull funds back.
• Who absorbs loss: economic loss borne by depositors in that pool; protocol only if it has an explicit insurance / reserve pool that backstops CeFi risk (not verifiable as of 30 Aug 2026).
• Compensation: depends on legal recovery from CEX plus any discretionary treasury payout; otherwise depositor principal impaired.
• Smart‑contract impact path:
• Yield stream stops → accounting oracle marks assets as 0 or impaired.
• Withdrawal requests fail or pay only remaining on‑chain liquidity (if any buffer).
• Possible emergencyMode flag set in pool contract; strategy allocation updated to remove the insolvent venue. ### 2. DeFi lending / yield protocol insolvency (top DeFi counterparty)
• Loss path:
• ZEROBASE allocates to lending pool / structured product.
• Counterparty protocol suffers bad‑debt event (oracle failure, hack) and pool becomes under‑collateralized.
• Who absorbs loss:
• Depositors in that ZEROBASE strategy via NAV drop.
• Any protocol‑level safety module, insurance fund, or token‑holder backstop absorbs only if explicitly coded/committed (not verifiable as of 30 Aug 2026).
• Compensation:
• If integrated protocol has own insurance (e.g., bad‑debt auctions), recovery may be partial; otherwise users take full hit.
• Smart‑contract impact path:
• Strategy valuation feed into ZEROBASE pool falls.
• Rebalancing logic halts new deposits to the affected strategy, may auto‑withdraw residual funds.
• Per‑chain pool contracts on Arbitrum/BSC/Base/Ethereum/OP/Polygon mark losses independently; cross‑chain total TVL declines. ### 3. ZEROBASE‑level insolvency (treasury / governance)
• Loss path:
• Treasury or governance token value collapses (exploit, legal action).
• If treasury was the backstop for CeFi/DeFi losses, its failure removes compensation capacity.
• Who absorbs:
• End‑users; governance token holders may see dilution or slashing if any safety module exists.
• Smart‑contract impact path:
• Contracts continue to operate but with impaired risk buffers.
• If there is an on‑chain insurance vault, it may pay out once then be exhausted, after which future losses pass through directly to users. Given missing verified docs, every numeric loss estimate, backstop size, and chain‑level allocation for ZEROBASE is Not verifiable as of 30 Aug 2026.

For ZEROBASE CeDeFi, a committed-fraud-by-the-DAO-or-owners stress case is not verifiable as of 2026-08-29 from the available sources. The web results do support that ZEROBASE has had at least one phishing/front-end compromise and that its owner permissions may allow parameter changes and emergency withdrawals, but that is not the same as proving DAO/owner fraud on-chain or in litigation. What can be said with confidence is narrower: a third-party writeup claims users lost funds in a counterfeit-site incident, and another source says the system includes owner-controlled emergency functions. Those facts indicate centralization and operational risk, but they do not establish committed fraud by the DAO or owners. I cannot verify any of the following from the provided evidence: intentional misappropriation of treasury assets, malicious governance capture, fraudulent issuance, or a court/regulator finding of fraud against ZEROBASE’s DAO or owners. The most defensible classification is therefore unverified fraud allegation / operational-security risk, not proven fraud.

Under a stress scenario where the primary yield source is negative for 30 days, ZEROBASE CeDeFi’s yield profile would likely compress sharply and could turn from “yield” into capital loss or flat returns, because its basis-trading style returns depend on positive funding-rate spreads. In that scenario, the protocol would have to rely more heavily on any secondary sources such as ZK-proof-related fees or other non-funding revenue, but the supplied results do not verify how large or stable those secondary streams are. The main stress mechanism is straightforward: if perpetual funding turns negative for an extended period, the core arbitrage leg can lose money instead of earning carry. Hindenrank explicitly flags this as a key risk and notes that negative funding rates can persist during bear markets, while ZEROBASE’s own materials say returns come primarily from risk-neutral arbitrage plus real-world ZK fees. That means a 30-day negative primary source would likely reduce APY materially and could force the product to absorb losses unless offset by fees or hedging gains. For institutional risk analysis, the important point is that this is not just an APY shock; it is a strategy-risk shock tied to market structure and counterparty execution, especially because the yield depends on centralized-exchange-linked basis trading. As a result, a 30-day negative primary yield period would likely be viewed as a severe earnings stress event rather than a protocol solvency event, but the exact loss magnitude is Not verifiable as of 2026-08-29 from the available sources. If you want, I can also frame this as a short risk memo with: impact, likelihood, mitigants, and monitoring triggers.

Governance of ZEROBASE CeDeFi and the ZBT token is only partially disclosed off-chain and is not on‑chain verifiable as of 2026‑08‑29 (no direct access to contract owners, multisigs, or timelocks). Not verifiable as of 2026‑08‑29 for any on‑chain specific metric. 1. Governance token & formal rights

• The ZBT token is described as the key asset of the ZEROBASE Prover Network, used for governance, staking, and access to protocol services.
• Official docs state that ZBT holders may propose or vote on “network parameters” and protocol‑level processes, but that these rights are “procedural” and *do not* give shareholder rights, profit claims, or direct control of the legal entity operating the network.
• This implies a DAO‑style governance framework that is limited to parameter / treasury decisions, while operational control remains with an off‑chain entity. 2. DAO vs company control
• Docs emphasize that the token is not equity and governance is restricted to network settings and some treasury decisions. That strongly suggests DAO powers are symbolic/limited in comparison with corporate control.
• External explainers (e.g., Binance and other media) state that 80% of protocol revenue is routed to a DAO treasury and can be used for ZBT buybacks/burns, subject to DAO vote. This reinforces the view that governance is mainly around treasury policy and network economics, not core operational control.
• No independent source provides:
• legal entity name,
• jurisdiction or registration number,
• directors, or
• Terms of Service specific to ZEROBASE CeDeFi. Not verifiable as of 2026‑08‑29. 3. Control of dev, contracts, frontend, funds
• There is no independent public mapping of:
• who holds admin roles on ZEROBASE CeDeFi contracts,
• whether a timelock is used,
• whether multisigs (and which signers/threshold) control upgrades, pausing, or treasury. Not verifiable as of 2026‑08‑29.
• Given the CeDeFi basis‑trading design and off‑chain CEX integration described by third‑party risk reviews, core strategy execution and off‑chain funds are almost certainly company‑operated, not DAO‑controlled, but this is an inference, not directly documented. 4. Voting power, holder concentration, chain split
• There is no publicly sourced holder analysis or voting concentration data that can be tied specifically to DAO votes. Without on‑chain analytics, top holders and their share across Arbitrum, BSC, Base, Ethereum, OP, Polygon cannot be quantified. Not verifiable as of 2026‑08‑29. 5. Risk‑relevant takeaways
• Governance is hybrid CeDeFi: ZBT provides limited, procedural governance over parameters/treasury; operational and legal control appears to remain with an off‑chain entity.
• DAO powers likely subordinate to company control, especially for strategy execution and infrastructure.
• Lack of disclosed multisig/timelock details and unidentified legal entity leaves significant centralization and key‑man / governance‑process risk for institutional allocators.

ZEROBASE CeDeFi appears to be a small, multi-chain yield protocol; however, its legal, regulatory, and corporate footprint is thin and largely unverified. All on-chain facts are Not verifiable as of 2026-08-30. 1. Legal entity & jurisdiction Open-source and analytics sources do not provide a clearly documented legal entity (e.g., company name, registration number, jurisdiction) associated with ZEROBASE CeDeFi as of 2026-08-30. • No reliable corporate registry hits (Delaware, UK, EU, Singapore, Dubai) directly link to “ZER0BASE”/“ZEROBASE CeDeFi”. Not verifiable as of 2026-08-30. • In absence of confirmed entity, the protocol should be treated as effectively unincorporated / pseudonymous from a risk standpoint. 2. Terms of Service / user restrictions No independently archived ToS, user agreement, or formal risk disclosures are discoverable outside the project’s own site or socials. • Where ToS is only found on the protocol’s front-end, all coverage is unverified marketing claim by definition. • Absence of documented jurisdictional restrictions (e.g., US persons, sanctioned countries) in independent sources increases regulatory exposure, particularly for Arbitrum/Ethereum/Base/OP Mainnet users. 3. KYC / AML practices There is no evidence in third‑party sources of mandatory KYC onboarding, identity verification, or ongoing AML monitoring for ZEROBASE CeDeFi. • No references to KYB/Fiat on/off‑ramp partnerships with regulated VASPs or banks. • From a compliance lens, the protocol operates as a typical permissionless DeFi app, even though it brands itself “CeDeFi” (centralized–DeFi hybrid) – this branding is an unverified marketing claim. 4. Regulatory classification & guidance No official guidance, licenses, or registrations (e.g., VASP, EMI, broker-dealer, fund manager) are attributable to ZEROBASE CeDeFi in major jurisdictions. • There is no documented MiCA, FATF Travel Rule, or US SEC/CFTC position specifically naming the protocol. Not verifiable as of 2026-08-30. • Practically, regulators would likely classify it as a DeFi yield protocol or unregulated investment-like service, but this is analytic inference, not a legal fact. 5. Warnings, enforcement, court cases, sanctions • No public regulatory warnings, enforcement actions, or consumer alerts referencing ZEROBASE CeDeFi in major databases (SEC, CFTC, FCA, ESMA, MAS, etc.). Not verifiable as of 2026-08-30. • No known court cases or litigation related to the protocol. • No appearance in major sanctions lists (OFAC SDN, EU sanctions) under the protocol name or obvious team labels. Not verifiable as of 2026-08-30. 6. Data protection / privacy • There is no independently verifiable GDPR/CCPA-style privacy policy, data processing description, or DPA registrations tied to the protocol. • Any user tracking, analytics, or data sharing practices are opaque from an institutional risk perspective. 7. Legal structure vs actual risk (institutional view) Given the lack of a confirmed legal entity, licenses, KYC/AML framework, and credible ToS, institutional exposure to ZEROBASE CeDeFi should be treated as pure smart-contract / counterparty-risk with no enforceable legal recourse. This applies across all listed chains (Arbitrum, BSC, Base, Ethereum, OP Mainnet, Polygon); chain-specific legal posture is Not verifiable as of 2026-08-30.

Not verifiable as of 2026-08-29. The web results confirm ZEROBASE CeDeFi is a stablecoin staking/CeDeFi protocol, but they do not provide a trustworthy time series for the stablecoin’s peg, so the number of depeg events, the last depeg date, and the depeg magnitude cannot be verified from the gathered sources. The only source that explicitly mentions depeg risk is a third-party risk page, which describes risk but does not document any actual depeg event. If the stablecoin used is USDT or USDC, no actual depeg history was verified in the available sources.

The top 5 risks for ZEROBASE CeDeFi are: 1) Centralized counterparty risk: user stablecoins are deployed to Binance for basis trading, so returns depend on a centralized exchange rather than purely on smart contracts. 2) Basis-trading yield risk: the strategy depends on positive perpetual funding rates; if funding turns negative, yield can fall sharply or become losses. 3) Novel ZK mechanism risk: the proof-verification system is relatively new and has limited battle testing, so it may not fully prevent strategy, implementation, or operational losses. 4) Smart-contract / authorization risk: public reports describe contract and approval-related exposure, including a prior phishing-related loss incident and a replay-logic issue in multi-chain deployment. 5) Stablecoin and market stress risk: the pools use stablecoins, so depeg risk and broader DeFi stress dynamics can affect principal and returns.

ZEROBASE CeDeFi’s top strengths are: 1) Verifiable privacy — it combines TEEs with zero-knowledge proofs so strategy execution can stay private while results remain publicly verifiable; 2) Institutional fit — the design is explicitly aimed at compliant, privacy-preserving DeFi and RWA workflows; 3) Yield product clarity — it offers a stablecoin staking / basis-trading style product with proof-based position and reserve attestation; 4) Scalability of off-chain computation — the infrastructure is positioned as a real-time proof network that moves expensive work off-chain and only posts proofs on-chain; 5) Composable architecture — the whitepaper describes a modular “proof as interface” / Proof Mesh approach intended to support multiple applications beyond staking, including trading and authentication. External commentary also highlights this ZK+TEE stack as the protocol’s core differentiator, while noting elevated counterparty and mechanism risk.