Ekubo

Ekubo is a next‑generation automated market maker (AMM) / DEX protocol originally built for Starknet and now extended to selected EVM chains. Protocol identification

• Name: Ekubo Protocol
• Website / UI: ekubo.org (interface, not primary swap frontend; liquidity often accessed via aggregators like AVNU).
• Docs: docs.ekubo.org (Introduction, FAQ, contract addresses).
• Category: Decentralized exchange / AMM with super‑concentrated liquidity, singleton architecture, and extensions (v4‑style hooks).
• Launch date: Mainnet launch on Starknet around June 2023.
• Chains:
• Starknet: Original and primary deployment.
• EVM chains via Ekubo v3: Docs explicitly list Ethereum, Base, Arbitrum, Robinhood Chain and more, with *same contract addresses on every chain*.
• For Robinhood Chain specifically, Ekubo v3 is stated to be deployed there as part of the EVM set.
• Native token: EKUBO governance token; used for community governance.
• Contract addresses & verification:
• Docs state there is a dedicated “Contract addresses” page listing core contracts (AMM, factory/singleton, EKUBO token) and that the same addresses are reused across EVM chains.
• Explorer‑level verification (contract source verified) is not verifiable as of 2026‑09‑04 under current constraints; on‑chain cross‑check with Dune is also Not verifiable as of 2026‑09‑04. Design / fork lineage
• Ekubo is described as “Uniswap v3‑like” and similar to Uniswap v4 in design philosophy, featuring concentrated liquidity, extensions (hooks), and singleton architecture.
• Starknet and research articles emphasize Ekubo as the first v4‑style AMM design in production, deployed on Starknet ahead of Uniswap v4’s own release.
• Community and educational write‑ups note it uses a CLMM (concentrated liquidity market maker) mechanism aka Uniswap v3, but with much finer ticks (1/100th of a basis point) and advanced gas‑optimization patterns such as the Till pattern.
• This positions Ekubo as an independent implementation inspired by Uniswap v3/v4, not a simple fork: singleton instead of per‑pool contracts, custom extensions framework, and different licensing (Ekubo DAO Shared Revenue License). Audits and fork‑risk considerations
• Docs state contracts are open source and “heavily optimized,” but do not prominently list a formal audit report or auditor. Absence of clear audit links from independent auditor sites is Not verifiable as of 2026‑09‑04.
• No independent records of malicious modifications in Ekubo forks or derivative projects were identified in the retrieved material; this is Not verifiable as of 2026‑09‑04. Key risk‑relevant notes
• Singleton architecture concentrates protocol risk into a single core contract on each chain (higher blast radius for bugs, but lower surface area).
• Extensions/hooks introduce additional complexity and potential integrator risk compared with simpler AMMs.
• Multi‑chain deployment with identical addresses on EVM chains simplifies cross‑chain monitoring but means any shared‑code vulnerability could affect all EVM instances.

Ekubo appears to be a real, functional product rather than a pure landing page: the docs include a live API reference, separate integration docs, and explicit endpoints for Starknet and Ethereum mainnet/sepolia, which strongly indicates an operational developer-facing platform. The documentation also describes wallet-agent workflows and a public service for preparing unsigned actions, suggesting active product functionality beyond static marketing. For user-facing maturity, the public docs and app ecosystem look reasonably developed, but there is one caveat: the search results do not directly verify live deposits/withdrawals or whether all app paths are currently working end-to-end, so that remains Not verifiable as of 2026-09-04.

The docs themselves also show some stale or conflicting ecosystem signals: one FAQ snippet says the protocol is only deployed to Ethereum and Starknet, while other references mention Robinhood Chain support and cross-chain deployments, so the chain footprint should be treated carefully and chain-by-chain verification is still missing. Open API: yes. The docs explicitly state that Ekubo provides machine-readable OpenAPI documents and expose documented endpoints for both the Ekubo API and Quoter API, with alpha caveats and versioning risk.

That is a clear sign of an open developer API, not a closed/private one. Broken links, fake metrics, template signs: none were directly confirmed from the gathered sources, but they also were not exhaustively audited here, so those items are Not verifiable as of 2026-09-04.

Ekubo appears to have an active security bounty/audit-competition program hosted on Code4rena. The publicly indexed program page shows a reward range of $0-$183,500, a smart-contract scope, and an addition date of Nov. 19, 2025.

The competition page indicates the Ekubo audit competition started then and ran for 21 days, implying a start date of 2025-11-19. Publicly available results mention 4 unique vulnerabilities were found, with 4 classified as medium severity; no higher-severity findings were shown in the indexed result snippet. A separate later security incident in May 2026 is unrelated to the bounty program itself and concerns an EVM swap-router exploit, not a bounty outcome.

As of September 6, 2026: Contradiction / correction: The prior finding that Ethereum and Robinhood Chain were likely only branding is contradicted by current Ekubo documentation: Ekubo V3 is deployed on Ethereum and EVM networks including Robinhood Chain, while the original deployment is on Starknet. This is a protocol-sourced claim and should be treated as an unverified marketing claim pending on-chain verification. External protocol and infrastructure dependencies

• Chain dependency: Separate risk domains exist on Starknet and each EVM chain. Starknet relies on its sequencer, prover, L1 settlement, and L1↔L2 messaging. EVM deployments depend on the host chain’s availability and finality. Starknet describes itself as an Ethereum-settled validity rollup.
• Bridges: Starknet liquidity may include assets issued through StarkGate or other bridges. StarkGate bridges ETH and ERC-20s between Ethereum and Starknet; bridge failure, message delays, token misconfiguration, or bridge-admin intervention could strand or impair collateral.
• Stablecoins: Public pool listings confirm Ekubo pools containing USDC/USDT and USDC/DAI on Starknet. These introduce issuer, freeze/blacklist, reserve, and depeg risk; concentrated-liquidity positions can suffer rapid adverse selection during a depeg.
• Oracle/manipulation: Ekubo is an AMM whose pool price is on-chain state; extensions can implement oracle logic, but no mandatory independent oracle dependency is established. Spot-price use by integrations is vulnerable to thin-liquidity manipulation, flash-liquidity distortion, and stale/TWAP assumptions.
• Governance/counterparty: Starknet contracts are upgradeable through governance; governance can control treasury and cross-chain owner proxies. This creates governance-key, proposal, and implementation risk.
• Custodians, CEX/MMs, RWA issuers/SPVs, LST/restaking: Not verifiable as of September 6, 2026. Failure scenarios: chain outage or censorship; bridge insolvency/lockup; stablecoin depeg or freeze; governance compromise/upgrade; oracle manipulation causing downstream liquidations; or liquidity collapse and impermanent loss. Dune/on-chain verification was unavailable; therefore chain-level exposure percentages and dependency concentration are Not verifiable as of September 6, 2026.

Ekubo is organized as a non-custodial smart-contract protocol rather than a protocol-held wallet or custodial intermediary. Its architecture is described as a singleton: one core contract holds pools, positions, and token balances, and token settlement is deferred until the end of an interaction, so users retain wallet control until they approve an on-chain action. On Ethereum, the core contracts are stated to be immutable and ownerless; on Starknet, governance owns/upgrades the core contracts; and the docs also note Ekubo V3 on EVM chains (including Robinhood Chain) uses the same contract addresses across supported EVM chains.

There is no verified evidence here of protocol-level withdrawal pauses affecting the whole protocol, and no verified evidence that user assets are segregated in a custodial sense. Not verifiable as of 2026-09-06.

In May 2024, a TWAMM/DCA mathematics bug caused some participants in Ekubo’s EKUBO distribution to overpay. Affected users were ETH, USDC and STRK DCA-order participants. Governance activated the DAO and upgraded the Starknet contracts on June 1, 2024.

Separate refund proposals executed on July 2, 2024 for ETH and USDC and July 3, 2024 for STRK; proceeds and DAO liquidity were withdrawn and identified users were refunded off-chain. The DAO estimated that correcting execution of the remaining 3 million EKUBO sale could be worth up to approximately $200,000, but realised user overpayment was not separately quantified. Recovered value is Not verifiable as of September 6, 2026.

Users were reimbursed; current status is resolved.

A second Ekubo-related incident report in the sources above repeats the same May 2026 EVM-router approval exploit narrative, with the same approximate loss magnitude and affected-user scope. Because it appears to be the same event described by multiple outlets rather than a distinct incident, it should not be counted separately without further evidence. Bug bounty: Not verifiable as of 2026-08-29. Key management/custody: Not verifiable as of 2026-08-29. Key-person risk: Not verifiable as of 2026-08-29.

Ekubo: Access Control via Token Approval Abuse on Ethereum; loss $1,400,000 (DeFiLlama hacks registry). Remediation status: remediation_in_progress (retained evidence).

Identified incident: a single major exploit on Ekubo’s EVM swap router contracts (v2 EVM extension), not on its core Starknet AMM.

• Date (attack window): Public reports place the exploit on 6 May 2026, with team confirmation around 5–6 May 2026.
• Cause: A missing access control / payer validation in the router’s payCallback logic. Attackers could cause the router to call transferFrom(payer, Core, amount) against *any* user who had previously given token approvals to that router, without verifying the payer was the lock initiator.
• Loss (size/composition): Roughly 17 WBTC, valued at about $1.36–1.4m at the time of attack; funds were then swapped into WETH/DAI and partially laundered via Tornado Cash.
• Affected chains: Only EVM deployments of Ekubo’s router (primarily Ethereum and Arbitrum); Starknet deployment and liquidity providers were not impacted, per Ekubo and Starknet team statements.
• Affected users/roles: Users who had granted unlimited / large ERC‑20 approvals (especially WBTC) to the vulnerable Ekubo v2 EVM router contracts. Liquidity provider positions and core Starknet AMM liquidity remained untouched.
• Protocol response:
• Issued an urgent security alert stating an active incident on EVM swap router only, and that LPs/Starknet were safe.
• Advised users to revoke all outstanding approvals to affected router contracts.
• Acknowledged that the EVM router contracts are immutable, implying a patched redeployment is required for restoration, not in-contract hotfix.
• Indicated intent to publish a post‑mortem; third‑party technical analyses (e.g., GitHub gist) already document exploit details.
• Recovered funds (recovered_usd): No credible reports of fund recovery or clawback; assets consolidated and moved through Tornado Cash. As of 2026‑09‑04, recovered_usd: 0 is the best supported reading.
• Reimbursement: As of 2026‑09‑04, there is no verified public information that Ekubo reimbursed affected users. Multiple incident reports discuss revoking approvals and future hardening, but do not mention compensation or refunds. → "Not verifiable as of 2026‑09‑04" whether users were reimbursed.
• Current status:
• Exploit vector clearly identified and documented; affected immutable contracts can only be mitigated via redeployment and by users revoking approvals.
• Router bug itself is therefore technically understood and containable, but whether full remediation (new router live + all risky approvals cleared) is complete is not verifiable as of 2026‑09‑04 from public sources. No other distinct security, financial, or governance incidents for Ekubo on Ethereum, Robinhood Chain, or Starknet are reported by independent sources as of 2026‑09‑04.

Ekubo’s key management appears to be organized around two layers: the Ekubo Wallet desktop app for users/agents, and optional hardware wallet support for signing. In the wallet, private keys and signing stay inside the wallet’s core authority; the agent interface gets a narrowed capability set and cannot approve requests, export keys, install policies, accept legal terms, or change security-sensitive settings. The wallet stores state in an encrypted local database.

According to the security docs, the private keys and the database key are placed in the operating system’s credential service rather than in an agent configuration file, and the local bridge carries fixed connection settings only, not wallet credentials. Exporting a private key requires owner authentication plus an explicit action in the native app. For delegated automation, the model is policy-limited control: agents can propose policy, but they cannot install it, and they never receive the private key.

This means operational control is separated from key custody. For users who prefer external custody, Ekubo’s KeepKey listing says EKUBO can be secured with a hardware wallet, where private keys are generated and stored offline and each transaction is verified on-device before signing. I could not verify any chain-specific key-management differences for Ethereum, Robinhood Chain, or Starknet from the available sources.

Not verifiable as of 2026-09-04.

As of September 6, 2026 — Smart-contract/admin risk Addresses / verification

• EVM V3 (Ethereum and Robinhood Chain): deterministic Core 0x00000000000014aA86C5d3c41765bb24e11bd701; Oracle extension 0x517E506700271AEa091b02f42756F5E174Af5230; TWAMM 0xd47f1B1eDCfEaBb08F6eBd8FC337c27E636C75BA; canonical Positions 0x02D9876A21AF7545f8632C3af76eC90b5ad4b66D. Same deployment addresses are documented for supported EVM chains, including Robinhood Chain.
• Starknet: Core 0x00000005dd3D2F4429AF886cD1a3b08289DBcEa99A294197E9eB43b0e0325b4b; Positions 0x02e0af29598b407c8716b17f6d2795eca1b471413fa03fb145a5e33722184067; Oracle extension 0x005e470ff654d834983a46b8f29dfa99963d5044b993cb7b9c92243a69dab38f; Governor 0x053499f7aa2706395060fe72d00388803fb2dcc111429891ad7b2d9dcea29acd. Architecture / privileges ``text EKUBO holders → Starknet Governor → ├─ upgrades Starknet Core/Positions/extensions in place ├─ controls treasury and periphery fee withdrawals └─ L1 Starknet proxy → owner proxies on Ethereum/Robinhood Chain EVM V3 Core → ownerless + immutable AMM/pool custody Periphery → Positions/Orders/Routers; protocol-fee collection `` EVM V3 Core is ownerless and immutable; however, Starknet Core, Positions and extensions are upgradeable and governance-controlled. Governance proposals can execute arbitrary calls, including cross-chain messages. The documented execution delay is 1 hour, but the effective timelock and proxy-admin/event history were not independently measured on-chain. Risk assessment
• admin_can_drain: true at system level: compromised governance could upgrade Starknet contracts or control owner-managed periphery/cross-chain contracts; EVM Core itself cannot be upgraded or seized through an owner.
• upgradeable: true (Starknet deployments; Governor can upgrade itself by proposal).
• audited_deployment: true — EVM V3 and Starknet deployments have listed independent reviews, including Code4rena, Plainshift and Nethermind.
• unresolved_critical: null; unresolved_high: null. Not verifiable as of September 6, 2026: Dune-decoded proxy-admin type, on-chain role renunciation, exact pause/emergency/withdrawal/upgrade/oracle/strategy permissions, measured timelock execution, and whether every user path permits exit during an admin action. Worst case is governance-key compromise causing malicious upgrades, fee diversion, cross-chain owner actions, or freezing Starknet functionality; EVM Core liquidity remains separately protected by immutability.

Audit of the Ethereum Ekubo Protocol smart contracts.

Security audit of Ekubo Governance Starknet L1 Proxy.

Security review of the Ekubo protocol, including tests and core components on Starknet.

Automated scan; not equivalent to a manual independent audit. Deployed-code match not independently verified.

Competitive audit of the EVM Ekubo smart contract system; identified 4 medium-severity vulnerabilities and 20 low/informational QA issues.

Competitive audit of Ekubo EVM extension contracts (Solidity) used for cross‑chain and router logic.

Newly confirmed legacy EVM V2 report; superseded by V3. Current deployed-code bytecode match: Not verifiable as of 2026-09-06.

Newly confirmed separate report. Current deployed-code bytecode match: Not verifiable as of 2026-09-06.

Newly confirmed separate report; not merged with Nethermind’s other engagements. Current deployed-code bytecode match: Not verifiable as of 2026-09-06.

Corrected/newly confirmed published report. Current deployed-code bytecode match: Not verifiable as of 2026-09-06.

Newly confirmed legacy EVM V2 report; superseded by V3. Current deployed-code bytecode match: Not verifiable as of 2026-09-06.

Newly confirmed legacy EVM V2 report; superseded by V3. Current deployed-code bytecode match: Not verifiable as of 2026-09-06.

Corrected publication date versus prior record. Current deployed-code bytecode match: Not verifiable as of 2026-09-06.

Newly confirmed separate report. Current deployed-code bytecode match: Not verifiable as of 2026-09-06.

Current EVM V3 extension review; deployed-code match not independently verified.

Ve33 invariant-verification report; not a conventional auditor-issued audit. Deployed-code match not independently verified.

Audit of Ekubo core Starknet contracts and TWAMM extension (DCA / buyback mechanisms) referred to in docs and secondary sources.

As of 2026-09-03, there is no publicly available formal audit report by a named audit firm (e.g., Trail of Bits, Nethermind, Spearbit, etc.) specifically for the Ekubo core AMM protocol on Ethereum, Robinhood Chain, or Starknet. Not verifiable as of [2026-09-03]. Community and ecosystem security context:

• Ekubo is a Starknet-native concentrated liquidity AMM with permissionless pools; security discussions appear mainly in Starknet ecosystem channels and Twitter/Medium posts, not in formal PDF audit reports.
• Security-related mentions include generic statements about having "undergone reviews" or "collaborated with Starknet security researchers", but these are unverified marketing claims without downloadable reports, auditor names, or issue tables. Because there is no verifiable audit document:
• Auditor: Not verifiable as of [2026-09-03].
• Report date: Not verifiable as of [2026-09-03].
• Scope: Not verifiable as of [2026-09-03].
• Link: Not verifiable as of [2026-09-03].
• Critical/High/Medium findings: Not verifiable as of [2026-09-03].
• Fix status: Not verifiable as of [2026-09-03].
• Bytecode-match / covers deployed code: Not verifiable as of [2026-09-03]. Given the lack of firm-level reports, all concrete audit-related fields for Ekubo must be treated as "Not verifiable as of [2026-09-03]" for Ethereum, Robinhood Chain, and Starknet deployments. Contradiction callout:
• If Ekubo’s website or marketing materials claim that the protocol is "audited" or "security-reviewed" without naming the auditor, publishing a report, or specifying coverage, those claims are unverified marketing claims and cannot be relied on for institutional risk assessment. Risk analyst note:
• In the absence of formal, verifiable audits, institutional risk treatment should assume no independent audit assurance on protocol logic, upgradeability, and Starknet-specific risks (Cairo VM, sequencer, L2 messaging).

Audit concluding that all contracts were most recently audited by Plainshift.

Current EVM V3 core review; deployed-code match not independently verified.

Current EVM V3 update review; deployed-code match not independently verified.

Current EVM V3 Auctions review; deployed-code match not independently verified.

Ekubo is a founder-led, non-anon DeFi protocol built primarily for Starknet, with a Delaware C‑corp as the main development entity and no separate foundation. ### Founders & Key Individuals

• Founder / CEO: Moody Salem.
• Public identity, long‑standing Ethereum/DeFi presence.
• Former Uniswap Labs engineering leader: co‑author/core contributor to Uniswap v3 and led the v4 architecture.
• Prior software engineering roles at Google and AWS, per Blockworks token transparency filings.
• Corporate entity: Ekubo, Inc.
• Identified as a Delaware corporation and the “Labs/DevCo” that created and maintains Ekubo protocol.
• Directly responsible for issuing the EKUBO token at launch; no separate foundation entity exists. Other executive/team names are not clearly enumerated in independent sources; Blockworks filings hint at additional personnel but do not provide a full org chart. Not verifiable as of 2026‑09‑04. ### Track Record, Prior Projects, Hacks
• Moody Salem’s track record is tightly linked to Uniswap’s core AMM design (v3 and v4), widely regarded as blue‑chip DeFi infrastructure.
• No credible reports of protocol hacks or major security incidents involving Ekubo or Moody Salem prior roles surfaced in independent coverage. Not verifiable as of 2026‑09‑04. ### Public vs Anon, Office, Jurisdiction
• Team is public, not anonymous: governance posts and interviews use real name and cross‑link to Twitter/GitHub.
• Onshore jurisdiction: Ekubo, Inc. is a US Delaware corporation. This implies US legal exposure and typical C‑corp governance, but physical office location (city, staffed office vs remote) is Not verifiable as of 2026‑09‑04.
• No separate offshore foundation or Cayman/VBZ structure; filings explicitly state “no foundation entity exists.” ### Governance / Reality Check
• Ekubo sought and obtained Uniswap DAO investment via governance proposals, exposing Moody and Ekubo to extensive public scrutiny around valuation, token economics, and alignment. This is atypical transparency for an early‑stage DeFi AMM.
• Protocol narrative and founder bio are corroborated across Starknet Foundation materials, Uniswap governance, Blockworks filings, and independent reviews—reducing reliance on protocol self‑marketing and supporting the view that Ekubo is a real operating business rather than a thin web front.

Ekubo has a generally strong reputation in DeFi circles: it is led by Moody Salem, who previously worked at Uniswap Labs and is repeatedly described as a major contributor to AMM design, and the protocol says it has no traditional VC backers, relying instead on a large Starknet Foundation Catalyst grant. Independent/security-facing sources report multiple audits across the EVM and Starknet codebases, including Nethermind, Plainshift, Riley Holterhus, Code4rena, and Cairo Security Clan, which supports a relatively mature security posture. There is no clear public record in the gathered sources of fraud, rug-pull, insolvency, or sanctions allegations against Ekubo itself.

The main unresolved concerns are structural rather than scandal-based: Ekubo, Inc. remains the operating company, holds a meaningful token position, and the governance/legal structure is still somewhat centralized around the company and DAO mechanics rather than a traditional foundation. That means the key diligence questions are control, token concentration, and governance dependence, not known misconduct. Sentiment is broadly positive, especially on Starknet, where Ekubo has been characterized as an important or flagship AMM project.

The strongest criticism in the available material is implicit rather than accusatory: some third-party writeups emphasize that the protocol’s “fair launch” and on-chain governance narrative coexist with significant influence from Ekubo, Inc. and its founder, so the decentralization story is not equivalent to fully permissionless, founder-detached governance. For legal/regulatory issues, the gathered sources show a token-transparency filing and governance discussion, but not enforcement actions, litigation, or sanctions specific to Ekubo. Not verifiable as of 2026-09-04: any on-chain exposure by chain, because on-chain verification was unavailable in this run.

As of September 6, 2026. Ekubo is an AMM/liquidity-infrastructure protocol, not a lending, staking, or vault strategy. Users supply token pairs to concentrated-liquidity, full-range, or stableswap pools; LP returns come primarily from trader-paid swap fees, while incentive campaigns add subsidized reward-token yield. LPs retain directional/impermanent-loss exposure: Ekubo explicitly states that liquidity provision is not a yield product and that returns depend on captured volume versus divergence loss. Assets in/out and mechanics: deposits and withdrawals are token-pair liquidity positions represented by NFTs.

The canonical Positions deployment has no principal withdrawal fee; liquidity is not described as time-locked. Pool fees are selected at pool creation. Protocol fee share is 10% of LP swap fees on EVM and 20% on Starknet, directed to DAO revenue buybacks; Core itself charges no fee.

Third-party licensees may use different fee settings. Exposure: no verified core leverage, looping, restaking, or external lending exposure. Position NFTs may be used as collateral elsewhere, which creates integration risk but is not Ekubo-native leverage. DCA/TWAMM and MEV-capture extensions alter execution or fee sources, not the base collateral model. TVL and trend: DeFiLlama reports approximately $28.13m TVL, up 15% over 30 days; Starknet represents 71.5% (approximately $20.1m), with the Ethereum/Robinhood Chain split not exposed in the retrieved page.

Exact TVL by product, full chain breakdown, and Dune-versus-DeFiLlama reconciliation: Not verifiable as of September 6, 2026 because Dune MCP is unavailable. DeFiLlama reports $176,801 30-day fees and $13,282 protocol revenue. APY sustainability: no reliable historical APY/volatility series was found. Fee yield is organic but volume- and range-dependent; incentive yield is subsidized and campaign-dependent.

Exact organic share: Not verifiable as of September 6, 2026. The prior finding that EVM deployment was only planned is outdated: current docs state deployment on Ethereum, Base, Arbitrum, Robinhood Chain, and others.

Assessment — as of September 6, 2026 Ekubo’s relevant reserve pool is the Ekubo DAO treasury, not a separately documented protocol-reserve fund. The treasury dashboard is referenced publicly, but its current portfolio value, token balances, and asset-level breakdown were not retrievable in this review. Not verifiable as of September 6, 2026. Dune/on-chain balance verification was unavailable, so no current multi-chain exposure or USD valuation is asserted. Historical composition: the DAO’s 2024 public sale of approximately one-third of the fixed 10,000,000 EKUBO supply raised 343.675 ETH, 1,204,770 USDC, and 1,549,920 STRK. The current Blockworks filing records the sale as 3,333,333 EKUBO, while the Starknet article states 3,269,920 EKUBO—a disclosed source contradiction; the precise sold amount is therefore Not verifiable as of September 6, 2026. Custody and control: DAO assets are disbursed through public governance proposals.

The documented Starknet Governor address is 0x053499f7aa2706395060fe72d00388803fb2dcc111429891ad7b2d9dcea29acd; governance controls the treasury and cross-chain owner proxies, including Robinhood Chain. Ekubo, Inc. reports no protocol ownership role, although it holds approximately one-third of EKUBO supply as a company asset. Reserve policy / attestations: no formal minimum-reserve, liquidity, diversification, or redemption policy was located. Protocol revenue flows to the DAO and is programmatically routed through revenue-buyback mechanics; treasury spending remains governance-directed.

The Blockworks filing expressly states that its disclosures are not independently verified. No independent reserve attestation was located. Not verifiable as of September 6, 2026. Liabilities: no DAO liability schedule or debt disclosure was located. Not verifiable as of September 6, 2026.

Ekubo currently has no publicly launched native fungible token on Ethereum, Starknet, or Robinhood Chain. As of 2026‑09‑04, all detailed tokenomics items you requested are therefore Not verifiable as of [2026‑09‑04] in the strict sense defined in your instructions. ### 1. Native token existence

• Ekubo is known as a Starknet-native concentrated liquidity AMM and “Ekubo Protocol” from the founder’s announcement and ecosystem materials, but there is no confirmed, live ERC‑20 style governance/utility token documented by independent analytics platforms or explorers.
• Common DeFi data sources (DeFiLlama, CoinGecko, CoinMarketCap, mainstream token-analytics sites) do not list an Ekubo token with consistent contract addresses or markets.
• Any mentions of an “Ekubo token” in community channels or speculative posts are unverified marketing claims unless backed by contracts and distribution on-chain. Not verifiable as of [2026‑09‑04]. ### 2. Tokenomics dimensions (all non‑applicable today) Given the absence of a confirmed native token:
• Name/ticker/contract address – Not verifiable as of [2026‑09‑04].
• Total vs circulating supply; market cap; FDV – Not verifiable as of [2026‑09‑04].
• Utility & governance role – The protocol’s governance and control appear smart‑contract / team‑controlled, not token‑holder‑controlled. A token-based governance model is not independently documented.
• Revenue share, buybacks, burns, staking rewards – Ekubo revenues (fees) accrue to LPs via AMM mechanics; there is no evidence of a token capturing protocol revenue. Token-based revenue share/buybacks/burns/staking: Not verifiable as of [2026‑09‑04].
• Emissions / unlock schedule; whether unlocks occurred on‑chain – Not verifiable as of [2026‑09‑04].
• Allocations (team/investors/treasury/community) – Not verifiable as of [2026‑09‑04].
• Top-holder concentration & insider wallets – Not verifiable as of [2026‑09‑04].
• Special token controls (mint, blacklist, fee‑switch) – Not verifiable as of [2026‑09‑04]. ### 3. DEX listings & liquidity
• No credible, consistent listings of an “Ekubo” fungible token on major DEXs or CEXs are visible in independent data sources.
• Liquidity depth for any purported Ekubo token: Not verifiable as of [2026‑09‑04]. ### 4. Risk‑analysis implication For current institutional risk work, treat Ekubo as a tokenless AMM protocol whose risk profile is dominated by:
• Smart‑contract risk on Starknet (and any other deployed chain).
• Operator/governance key risk over protocol parameters.
• LP and trader exposure without an additional layer of tokenomic risk such as emissions or unlock overhangs. If a token is announced later, its contract, distribution, and governance hooks must be reassessed from scratch against this framework.

Ekubo’s stress case under a Bitcoin drop below $10,000 is a liquidity and user-confidence shock, not a protocol-specific price mechanism: Ekubo is an AMM deployed on Starknet and also on EVM chains including Ethereum and Robinhood Chain via Ekubo V3. A BTC collapse of the magnitude described in market commentary would likely reduce DeFi trading activity, shrink LP incentives, and increase withdrawal/redemption pressure across BTC-linked pools and wider risk assets, but the exact impact on Ekubo’s TVL, volumes, and solvency is Not verifiable as of 2026-09-04 from the available sources. The main chain-specific risk distinction is architectural: Ekubo’s docs say the protocol is deployed on Starknet and on EVM chains at the same contract addresses on every chain, so any stress analysis should be split by chain exposure rather than treated as one unified pool set.

I could not verify on-chain balances, pool composition, or chain-by-chain TVL in this run, so the distribution of exposure across Ethereum, Robinhood Chain, and Starknet is Not verifiable as of 2026-09-04. One material non-market consideration is incident risk on EVM deployments: a May 2026 report said attackers drained about $1.4M in WBTC from Ekubo’s EVM swap router exploit, while stating the Starknet core deployment and broader liquidity base were untouched. That means a BTC crash scenario could be amplified on EVM if users already perceive router risk, but I cannot confirm whether that incident changed current exposure or user behavior beyond the report itself.

For risk framing, the most defensible conclusion is: BTC below $10,000 would likely stress Ekubo through lower activity and higher withdrawals, with the largest unresolved uncertainty being how much TVL and flow sits on each chain.

Not verifiable as of 2026-09-04. The provided sources do not include on-chain balances, pool-level collateral composition, or chain-by-chain exposure for Ekubo on Ethereum, Robinhood Chain, or Starknet, so the impact of a 20% depeg of the largest collateral asset cannot be quantified reliably. The only Ekubo-specific material in the results is a media/profile piece and a docs snippet indicating EKUBO/STRK can be used as collateral in some Vesu pools, but that does not establish Ekubo’s own collateral stack, TVL, or risk exposure.

In a stress framework, a 20% depeg would reduce the stressed value of that collateral by 20% before any protocol-specific haircuts, but the resulting loss transmission, if any, depends on the exact margining, liquidation, and cross-collateral rules, which are not verifiable from the available evidence. Because Dune/on-chain verification is unavailable in this run, chain-level shares of exposure are also Not verifiable as of 2026-09-04.

Ekubo does not appear to have a protocol-level mechanism that socializes losses from a “top counterparty insolvent” event; the loss path is primarily contained to the specific pool/position, and any shortfall would be borne by the affected LPs unless a separate insurance/compensation arrangement exists. The available evidence is enough to characterize the architecture and audits, but not enough to verify chain-specific loss waterfalls for this stress case; for this scenario, the exact compensation path is Not verifiable as of 2026-09-04.

• Ethereum: Ekubo’s EVM contracts are described as immutable, and the documented owner role can only withdraw protocol fees, which implies no discretionary rescue or clawback path in-contract; if a counterparty becomes insolvent, the impact would flow through the AMM’s settlement logic and LP accounting, not a protocol bailout layer. Compensation is Not verifiable as of 2026-09-04.
• Robinhood Chain: Ekubo states it is deployed on EVM chains including Robinhood Chain, but the available source does not provide Robinhood-specific contract risk controls or insolvency handling. The expected loss path and compensation are Not verifiable as of 2026-09-04.
• Starknet: Ekubo’s Starknet core and related contracts have been audited, and the protocol uses a singleton-style AMM architecture on Starknet; however, the cited material does not document any insolvency backstop, clearinghouse, or protocol-level mutualization of losses. The impact would therefore be mediated by pool state and LP exposure, but the exact contract-by-contract path is Not verifiable as of 2026-09-04. Impact path through the smart contracts: the only clearly supported conclusion is that the protocol’s contracts are designed to execute swaps and fee logic, while fee withdrawal rights are tightly constrained on Ethereum; nothing in the available sources shows an insolvency-rescue module, guarantee fund, or automatic compensation contract.

Ekubo does not have verified evidence of committed fraud by the DAO or owners in the sources available here. The strongest available evidence points to a May 2026 approval-based exploit in Ekubo’s EVM swap router on Ethereum, where attackers abused an access-control / callback flaw to drain user WBTC approvals; Ekubo’s Starknet deployment and core liquidity providers were reported as unaffected. For this stress scenario, the correct risk classification is not verifiable as committed DAO/owner fraud as of 2026-09-04.

The incident described by multiple independent sources is a security exploit / authorization drain, not a governance-led misappropriation, insider theft, or treasury fraud by Ekubo’s DAO or owners. What is supportable from the sources is:

• Scope: affected the EVM router environment on Ethereum, not the core Starknet deployment.
• Loss type: around $1.4M / 17 WBTC drained from users with existing approvals.
• Attribution: public writeups frame the loss as an exploit of permissions or approvals, with the economic loss borne by approved users rather than the DAO treasury or protocol-owned liquidity. One source also states that Ekubo is “fully owned and operated by the DAO,” but that is a governance-structure claim, not evidence of fraud. Because the question is specifically about fraud by the DAO or owners, and the available sources do not show that, the answer is: Not verifiable as of 2026-09-04.

Ekubo does not have a verifiable “primary yield source” that can be shown to be negative over the last 30 days from the provided results. The protocol’s documented revenue/yield mechanism is withdrawal fees charged when LPs remove liquidity, with swap fees also referenced in the fee model. However, none of the available sources provide a 30-day negative yield series for Ekubo, and the user’s requested metric is Not verifiable as of 2026-09-04.

On the protocol model, Ekubo is a concentrated-liquidity AMM on Ethereum and Starknet, and its protocol revenue is tied to swap and withdrawal activity rather than a separate lending or emissions yield stream. The source set also indicates Ekubo is only deployed to Ethereum and Starknet, so there is no verifiable Robinhood Chain deployment in the supplied materials. For a stress-scenario reading, the relevant risk is not “negative yield” in the sense of an external yield-bearing asset, but fee compression / lower protocol revenue if trading volume and LP churn fall.

That would reduce EKUBO buyback capacity or LP economics if fees are the primary economic source, but the magnitude cannot be quantified from the provided sources. Chain-level exposure cannot be split reliably from these sources, so the chain breakdown is Not verifiable as of 2026-09-04 for Ethereum, Robinhood Chain, and Starknet.

As of September 13, 2026, governance is technically real, but operational control remains concentrated. EKUBO holders stake/delegate on Starknet; Governor proposals require 100,000 EKUBO to submit, 3,250,000 EKUBO quorum, simple majority, a 1-hour start delay, 4-day vote, 1-hour execution delay, and 30-day execution window. The Governor can execute arbitrary approved calls, upgrade itself, control the Starknet Core/Positions/extensions, disburse DAO treasury assets, and direct owner proxies on Ethereum and Robinhood Chain.

EVM V3 Core is ownerless and immutable; Starknet Core is governance-upgradeable. Control split: Ekubo, Inc. built and continues to maintain the core contracts, interface, indexer, API, and governance tooling under a DAO-approved services arrangement. The frontend and off-chain services are therefore company-dependent, while on-chain upgrade and treasury authority is Governor-controlled. Ekubo, Inc. reportedly holds one-third of total EKUBO supply and has pledged not to sell it. Contradiction: protocol documentation describes binding, fully on-chain governance; Blockworks describes token-holder votes as “non-binding” and says Ekubo, Inc. may decline additional off-chain duties.

The stronger conclusion is: DAO control is real for on-chain parameters, upgrades, cross-chain proxies, and treasury; company control remains material for development, frontend, API, and service execution. Concentration / multisig: Top holders, voting concentration, multisig signers, threshold, and signer independence: Not verifiable as of September 13, 2026. Dune was unavailable for this run. No governance multisig is identified in the reviewed governance materials; execution is by the Governor contract.

Company legal entity: Ekubo, Inc., Delaware C corporation; Delaware entity ID 7523261. Directors were not identified. Terms use Delaware law and mandatory arbitration, with Ekubo, Inc. as the contracting company.

Ekubo appears to be a U.S.-based project structure: the available filing states Ekubo, Inc. is a Delaware C corporation, while the protocol’s governance materials say the Ekubo DAO holds ownership of the core smart contracts and Ekubo, Inc. acts as a service provider with no administrative powers over the protocol itself. The protocol documentation says Ekubo is deployed on Ethereum and Starknet; I found no reliable evidence of a Robinhood Chain deployment in the material reviewed. I did not find a published ToS in the sources reviewed that clearly imposes KYC/AML on end users; the public docs instead describe the protocol as AMM infrastructure and the governance/token structure, not as a regulated financial intermediary.

I also found no court cases, sanctions designations, or regulator enforcement actions against Ekubo, Inc. or the protocol itself in the reviewed sources, and no data-protection-specific legal filing surfaced in the search results. The main legal-risk point is structural: although the DAO controls the core smart contracts, the development company still provides substantial services and hosts an interface, so any regulatory exposure would likely focus on the interface/operator layer and the U.S. entity rather than on-chain control alone.

No exact GLEIF LEI record for 'Ekubo Inc'. OFAC SDN screening of 'Ekubo Inc': no match. SEC litigation and administrative release feeds: no mention.

Ekubo does not appear to issue its own stablecoin; the project is described as an AMM/DEX on Starknet and EVM chains, and its governance token is EKUBO, not a stablecoin. No protocol-specific stablecoin depeg event could be verified from the available sources, so the depeg count, last depeg date, and maximum depeg percentage are not verifiable as of 2026-09-06. Because no Ekubo-issued stablecoin is evidenced, stable is null and own_stablecoin is false.

Ekubo’s principal risks are governance-controlled upgradeability on Starknet and cross-chain control, extension-induced composability failures, concentrated-liquidity market risk, and implementation complexity in a highly optimized singleton AMM. Multiple audits and an open-source codebase reduce—but do not eliminate—loss risk; live chain-by-chain exposure and TVL are Not verifiable as of September 5, 2026 because Dune was unavailable.

Ekubo’s top strengths are: (1) extreme capital efficiency from concentrated, very fine-grained liquidity; (2) low gas / execution cost from its singleton + till architecture; (3) permissionless extensibility that lets developers build new pool types and features on top of the core; (4) shared canonical liquidity and integrations through one Core contract, which reduces fragmentation and improves composability; and (5) strong Starknet-native optimization from Cairo-based contracts and design choices tuned for Starknet’s execution model.