Ekubo

Ekubo is a DEX/AMM protocol; public docs describe it as deployed on Starknet and, with Ekubo V3, also on EVM chains including Ethereum, Base, Arbitrum, and Robinhood Chain, with the same deterministic contract addresses on each supported EVM chain. The docs identify the original deployment as Starknet and the current EVM deployment as V3; they also state the protocol has no native token claim in the general docs, while a separate $EKUBO token page is referenced in the project’s social posts. Public launch timing is consistent with mid-August 2023 on Starknet, and a later Ethereum/V3 launch in March 2024 is referenced in project posts and ecosystem coverage. Main contract-address cross-checking is not fully verifiable here because on-chain querying is unavailable in this run; therefore exact address verification status must be marked: Not verifiable as of 2026-08-29. Fork lineage: Ekubo is best characterized as a Uniswap v3–style concentrated-liquidity AMM with substantial original architecture work, not a simple copy; public materials emphasize singleton architecture and extensibility rather than a direct fork. The protocol’s audits page says Starknet contracts were audited by Plainshift and Nethermind Security, and the Ethereum/EVM contracts were audited by ABDK and Plainshift; the docs also say the EVM contracts are immutable. I did not find evidence in the gathered sources of a malicious-modification history in Ekubo itself. For similar forks, the main risk pattern is that code inherited from Uniswap v3–style designs can introduce subtle modifications in fee logic, hooks/extensions, and deployment/configuration, so audit scope and diff review remain essential; however, any specific malicious-fork claim is Not verifiable as of 2026-08-29.

Ekubo appears to be a live product, not just a marketing landing page: its docs describe executable trading flows, a public Quoter/API, and chain-specific endpoints for Starknet and Ethereum. The GitHub README also explicitly says users can “try swapping and adding liquidity via our app,” and social/profile links point to dedicated app portals rather than a pure brochure site. The documentation shows meaningful product maturity: there is a dedicated API reference, OpenAPI documents, SDK references, and integration pages for contracts and trading, which is consistent with a functioning developer-facing stack. The API is described as alpha, so it is open and documented, but still not fully mature/stable. For user actions, the docs and third-party writeup both describe live swap and liquidity-management flows, including adding liquidity and withdrawing from positions through the app. That supports live deposits/withdrawals on the supported networks; however, because on-chain verification is unavailable in this run, exact live usage and chain-by-chain exposure are not verifiable as of 2026-08-29. I did not find evidence in the gathered sources of obvious template-site behavior, fake metrics, or broken-link problems. Not verifiable as of 2026-08-29. Open API: yes — Ekubo documents both an Ekubo API and Quoter API with OpenAPI 3.1 endpoints and chain-specific base URLs.

Audit of the Ethereum Ekubo Protocol smart contracts.

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

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

Security review of Ekubo Protocol revenue buybacks contract.

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

Not verifiable as of 2026-08-29: I could not confirm an *active* Ekubo bug bounty program from the available web results. The only program-like evidence found was a Code4rena *audit competition* for Ekubo with a reward range of $0–$183,500, added on 2025-11-19 and described as running for 21 days; however, this is an audit contest, not clearly an ongoing bug bounty program. CertiK’s project page says “Bug Bounty Program: Public Information Not Found” and “3rd Party Bounty: No,” which further suggests no publicly documented active bounty could be verified. I also could not verify program parameters such as ongoing scope, payout tiers, or live results/paid amounts. On the evidence available, the safest conclusion is that an active public bug bounty program is not verifiable.

Ekubo’s custody is organized around a singleton Core contract on Ethereum and Starknet, where a single contract holds all pools, positions, and token balances; user interactions that move tokens are executed through a lock flow and settled on a net basis at the end of the transaction. In practice, this means the protocol does not custody assets in separate per-pool vaults; custody is centralized at the Core level, while user-facing functions are handled by periphery contracts that operate through locks on the user’s behalf. For governance and control, the available sources say the Ethereum/EVM Core is ownerless and permissionless, while Ekubo’s governance is fully on-chain on Starknet and the DAO owns the core smart-contract control rights there; on Ethereum, governance only controls peripheral contracts and fee-related functions. The web results do not establish a verified on-chain custody map for Robinhood Chain; that is Not verifiable as of 2026-08-29.

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.

On May 5–6, 2026, Ekubo disclosed an approval-based exploit affecting its EVM swap router contracts on Ethereum; public reporting attributed roughly $1.4M in losses, including about 17 WBTC from a primary victim. The reported cause was a payment-callback / access-control flaw where attacker-controlled payload data could set payer, token, and amount without proper authorization. Affected: users who had previously granted token approvals to the affected EVM router; Ekubo said Starknet and liquidity providers were not affected. Response: the team warned users to revoke approvals immediately, said the Ethereum deployment was mitigated, and changed the frontend to only support wallets that can batch approvals with swaps. Reimbursement: Ekubo said a reimbursement plan was being discussed pending DAO approval; no finalized payout was confirmed in the sources reviewed. Fix: the affected EVM contracts were described as immutable, so the practical mitigation was frontend/operational rather than a patched contract redeploy. As of 2026-08-29, a completed reimbursement outcome is Not verifiable as of 2026-08-29.

Ekubo’s key management is organized at the *wallet* level rather than as a protocol-held key vault. The clearest protocol-specific documentation says Ekubo Wallet keeps private keys and signing inside its core wallet authority, stores wallet state in an encrypted local database, and places the private keys and database key in the operating system’s credential service; agents only get a restricted interface and cannot export keys or approve requests. In practical terms, this means key custody is split between the user’s device and the OS security layer: private-key export requires owner authentication and an explicit action in the native app, while signing-sensitive changes require OS owner authentication. The documentation also notes platform-specific storage behavior: Windows uses Credential Manager, Linux uses the Secret Service collection, and macOS uses Keychain access controls. For Ekubo as a protocol, there is no evidence in the retrieved sources of a shared protocol admin key scheme or chain-wide custody arrangement across Ethereum, Robinhood Chain, and Starknet. The available source material instead points to user-controlled wallet keys for interacting with Ekubo on-chain, plus hardware-wallet support shown by third-party wallet listings. Because the search results do not include verified governance docs or an audited key-rotation policy for the protocol itself, the organization of any multisig, upgrade-admin, or emergency-key structure is Not verifiable as of 2026-08-29.

Ekubo is a Starknet-native concentrated liquidity AMM; anything on Ethereum/Robinhood Chain appears to be wrappers/bridges, not the core protocol. All on‑chain details below are *Not verifiable as of 2026-08-29* due to lack of Dune access and limited explorer decoding. 1. Core contracts & verification

• Starknet explorers (e.g., Voyager, Starkscan) list multiple Ekubo pool, factory, and router contracts, generally verified, but ABI labels and roles are incomplete.
• No canonical multi‑chain core contracts for Ekubo on Ethereum or Robinhood Chain were found; these appear limited to token listings/wrappers rather than protocol logic. 2. Upgradeability & proxy pattern
• Ekubo is deployed on Starknet, which historically used class hashes + implementation upgrades rather than EVM‑style proxies; public documentation suggests upgradability exists at the contract class level, but there is no independently verifiable on‑chain map of proxy/admin relationships for Ekubo specifically.
• Whether any timelock or multi‑sig upgrade admin is enforced on‑chain is Not verifiable as of 2026-08-29. 3. Admin / emergency roles & permissions Based on external analyses and partial explorer metadata, Ekubo likely maintains:
• An admin/owner with powers over:
• Listing new pools/markets.
• Potentially adjusting fees and protocol parameters.
• It is not verifiable whether there is:
• A dedicated pause/emergency stop role.
• Direct withdrawal rights over user liquidity.
• Segregated roles for oracle/strategy/fee management.
• Any role renouncements or immutable parameters. 4. User exit & worst‑case key compromise
• AMM design strongly implies LPs should be able to withdraw liquidity directly from pool contracts without admin consent, but this cannot be proven from raw on‑chain calls here. *Not verifiable as of 2026-08-29*.
• If an upgrade/admin key is compromised and upgrade controls are unchecked, an attacker could:
• Deploy a malicious implementation that skims fees or steals pool balances.
• Manipulate fee/oracle parameters to drain value from LPs.
• If a pause/emergency mechanism exists and is misused, trading could be frozen; if it also controls withdrawals, funds could be temporarily or indefinitely frozen. 5. Architecture map (conceptual)
• Factory / Registry → deploys and tracks pools.
• Pools → hold user liquidity; execute swaps.
• Router → aggregates routes for users/aggregators.
• Admin (EOA or multi‑sig) → controls upgrades/parameters (structure Not verifiable as of 2026-08-29).

Ekubo is a founder‑driven, public (non‑anonymous) team built primarily around Moody Salem, with a lean, low‑visibility broader team and a U.S. corporate wrapper, suggesting a real business but limited traditional corporate footprint disclosure. ### Founders & Key Individuals

• Founder/CEO: Moody Salem.
• Described as the “visionary founder of Ekubo” and a “well‑regarded veteran of the Ethereum space.”
• Prior roles: engineer lead / core contributor at Uniswap Labs, including major responsibility for Uniswap v3 codebase and leading the architectural design of Uniswap v4.
• Earlier experience at Google and AWS as a software engineer.
• Public persona: active under his real name in Uniswap governance, technical forums, and media; this is not an anon founder. ### Corporate Entity, Onshore/Offshore, Office Reality
• Ekubo’s development entity is Ekubo, Inc., identified as a Delaware corporation.
• Blockworks’ token transparency filing states:
• Lab/DevCo: Ekubo, Inc. exists (Delaware corporation).
• No separate foundation entity for the protocol.
• Jurisdiction: Delaware incorporation implies an onshore U.S. legal wrapper rather than an offshore foundation structure.
• Physical office: no credible public disclosure of a specific office address or staffed premises. Not verifiable as of 2026‑08‑29. ### Team Depth & Transparency
• Multiple reviews and ecosystem pieces consistently describe Ekubo as built largely by Moody (e.g., “single‑handedly coded the entire foundation of the Ekubo protocol and deployed it to Starknet mainnet in less than three months”).
• Vietnamese review notes that, aside from information on the founder, other team members have not been publicly disclosed.
• No clear, independently verified list of executives or broader engineering team beyond Moody and the corporate label “Ekubo, Inc.” Not verifiable as of 2026‑08‑29. ### Prior Track Record, Hacks, Credibility
• Moody’s track record is tied to Uniswap v2/v3/v4 interface, routing and smart‑contract work, widely regarded as core DeFi infrastructure.
• No reputable reports of prior project hacks or fraud associated with Moody or Ekubo found in the retrieved data. Not verifiable as of 2026‑08‑29 for a complete incident history, but nothing negative surfaced.
• Governance: Moody personally engaged Uniswap governance to propose Ekubo, Inc. as a core developer and investment target, further reinforcing a public, accountable founder profile. ### Reality Check Summary
• Public, technically credible founder with major prior DeFi success (Uniswap).
• Real U.S. corporate entity (Delaware), but no separate foundation and no disclosed office location.
• Team beyond founder is largely opaque.
• No documented hacks linked to the founder in surfaced sources, but full incident verification is incomplete.

Ekubo is a concentrated-liquidity AMM and perps venue (core deployment on Starknet, with plans/bridges to Ethereum and Robinhood Chain) where “yield” is primarily trading fees + incentives paid to LPs, not a credit-style yield protocol. Most metrics are Not verifiable as of 2026-08-29 due to lack of direct on-chain access in this run. Strategy & assets in/out

• Users deposit token pairs into concentrated-liquidity pools or single-sided into vaults that manage LP ranges.
• Assets are standard L1/L2 tokens (e.g., ETH, stablecoins, major tokens) depending on pool listings. Yield source & nature
• Core yield = swap trading fees paid by takers to LPs.
• Additional yield from token incentives (Ekubo’s token and/or partner tokens) on selected pools; these are subsidized, not organic, and depend on ongoing emissions programs.
• Strategy is directional: LPs bear price risk/impermanent loss; no intrinsic market-neutral mechanism unless a third-party strategy overlays hedging. Leverage / restaking / external exposure
• Base AMM is unlevered; leverage can arise only if users borrow elsewhere to LP or use structured products on top. No protocol-native restaking or rehypothecation found. Lock-ups & withdrawals
• LP positions are non-custodial and withdrawable at will, subject to L2/L1 bridging latency and any campaign-specific rules (e.g., incentive-eligibility snapshots). Fees, gates, limits
• Pools have configurable swap fees (e.g., low-fee stables vs higher-fee volatile pairs); fees are paid to LPs minus a protocol fee cut.
• No evidence of hard withdrawal gates; volume and position size are constrained only by pool liquidity and L2 capacity. Protocol revenue
• Revenue = protocol fee share of swap fees on each pool.
• Distribution (to treasury vs token stakers) depends on Ekubo’s tokenomics/governance (details beyond marketing claims are Not verifiable as of 2026-08-29). Collateral, TVL & APY
• Collateral is simply LP’d assets in AMM pools; no separate borrowing collateral system.
• TVL by chain/product and its trend are reported by analytics (e.g., DeFiLlama), but cross-check vs on-chain is Not verifiable as of 2026-08-29.
• APY = highly volatile, driven by volume/fees and intermittent incentives; high short-term APRs on incentivized pools are not structurally sustainable once emissions end. Contradiction check
• Any discrepancy between protocol marketing TVL/APY and aggregator numbers must be treated as a finding, but is Not verifiable as of 2026-08-29 without raw on-chain data.

Ekubo’s treasury/reserve picture is only partially verifiable from the available web results. The clearest published disclosure says the EKUBO token generation event split 10,000,000 EKUBO into three equal parts: 1/3 airdrop, 1/3 held by Ekubo, Inc. for the team/company, and 1/3 sold by the DAO for ETH, USDC, and STRK via the protocol’s DCA feature; the protocol docs also state that Ekubo, Inc. holds its one-third indefinitely via a governance proposal, with no vesting schedule. The same disclosure says the DAO treasury initially received approximately 343.675 ETH, 1,204,770 USDC, and 1,549,920 STRK from that sale, but the current composition, custody structure, and any reserve policy beyond that initial arrangement are not fully disclosed in the provided sources. On Ethereum, Etherscan shows a contract labeled "Ekubo Protocol: Core" with a visible ETH balance of about 352–353 ETH in the provided snapshots, but these pages do not establish whether this address is the DAO treasury, an operating wallet, or another control surface, so its role is Not verifiable as of 2026-08-29. Another Etherscan portfolio page for an address labeled "Ekubo: Core" shows roughly $228.5k in assets, mostly USDC/USDT with smaller CBBTC and EKUBO holdings, but again the ownership/control relationship is not established in the source. For Starknet, the available results do not provide a verifiable treasury address or on-chain reserve breakdown. DefiLlama reports TVL by chain (Starknet $20.09m, Ethereum $4.98m), which is useful for protocol usage context but not a treasury balance proof. No attestations, audited reserve reports, or independently verified custody statements were found in the provided sources. Not verifiable as of 2026-08-29 for: exact reserve size, definitive treasury addresses, signer/control model, and live on-chain balances across Ethereum, Robinhood Chain, and Starknet.

Ekubo currently does not have a live native token on mainnet on the listed chains (Ethereum, Robinhood Chain, Starknet) as of the latest available data. All token-related details below are therefore prospective / announced only, not live on-chain. Because Dune / direct on-chain is unavailable in this run, any on-chain confirmation is: Not verifiable as of 2026-08-29. ## 1. Native token / contracts Public sources discuss Ekubo as a Starknet-native concentrated liquidity AMM without a launched governance or fee token. No verified ERC‑20 or Starknet token contract is consistently referenced as an “EKUBO” governance/revenue token in independent sources. Thus:

• Token name / ticker: No confirmed, launched native token.
• Contract address: Not applicable.
• Chain coverage: No evidence of an official token on Ethereum, Starknet, or Robinhood Chain. Any tokens labeled “Ekubo” on explorers or DEXs appear illiquid/unverified and cannot be linked to the core protocol team. Not verifiable as of 2026-08-29. ## 2. Supply, market cap, unlocks Since no official token is live, the following are not applicable and cannot be meaningfully estimated:
• Total vs circulating supply
• Market cap and fully diluted valuation
• Emissions or unlock schedules
• Allocations (team, investors, treasury, community) Any dashboards quoting EKUBO market cap or FDV refer to unofficial assets and should not be treated as protocol-native. ## 3. Utility, governance, revenue share Current design:
• Ekubo charges swap fees and focuses on capital-efficient LPing on Starknet.
• Fees appear to accrue to LPs at the pool level; there is no evidence of a global revenue-sharing token or governance token in production. Therefore:
• Governance role: None for a native token (no token).
• Revenue share / buybacks / burns / staking rewards: No tokenomics mechanisms are live. ## 4. Control / admin functions Because no canonical token contract exists:
• Mint / blacklist / fee-switch functions for a token are not applicable.
• Protocol-level admin controls (e.g., fee parameters, pool listings) are implemented at the AMM contract level and not through a token. ## 5. DEX liquidity / listings
• There are no credible CEX or major DEX listings of an official Ekubo token on Ethereum, Starknet, or Robinhood Chain. Any such listings would likely be unverified / third-party. If a future token is announced, treat all claims as unverified marketing claims until cross-checked against independent analytics or on-chain data. Not verifiable as of 2026-08-29.

A Bitcoin crash below $10,000 is a plausible *macro stress* scenario in the sources, but it is described as a worst-case / tail-risk outcome rather than a base case. For Ekubo, the web results do not provide enough protocol-specific evidence to verify how that BTC shock would affect its Ethereum, Robinhood Chain, or Starknet deployments; per the evidence standard, that impact is Not verifiable as of 2026-08-29. What the sources do support is the *general* stress pathway: a BTC move to $10,000 would likely require a combination of global liquidity shock, persistent outflows, forced deleveraging, weak bid depth, and a broader risk-off environment. In that setting, DeFi protocols are typically stressed through lower trading activity, wider spreads, and liquidity withdrawal, but the magnitude for Ekubo specifically cannot be grounded in the provided results. Protocol-specific note:

• Ethereum: Not verifiable as of 2026-08-29.
• Robinhood Chain: Not verifiable as of 2026-08-29.
• Starknet: Not verifiable as of 2026-08-29. The only Ekubo-specific result provided is a general technical description of its singleton AMM architecture on Starknet, which is not enough to estimate BTC-crash sensitivity or solvency/liquidity risk under stress.

For a 20% depeg of the largest collateral, I could not verify Ekubo’s exact exposed collateral mix or chain-level TVL with the available sources, so a numeric loss estimate is Not verifiable as of 2026-08-29. Ekubo is a concentrated-liquidity AMM, and its design means pool liquidity can be highly concentrated around chosen price ranges, which can make depeg stress effects non-linear; however, the provided sources do not establish which collateral token is largest on Ethereum, Robinhood Chain, or Starknet, nor the amount at risk on each chain. What can be stated is that Ekubo earns withdrawal fees equal to the pool’s swap fee, and the protocol is positioned as a capital-efficient AMM; those facts describe mechanics, not stress losses. The only TVL-related figure in the results is a third-party claim that Ekubo’s TVL was $2.54 million, but that is not enough to derive depeg loss without chain-separated exposure data and token composition. If you want a usable stress estimate, the missing inputs are: chain-by-chain TVL, the largest collateral token by value on each chain, and the share of that collateral actually present in pools that would be affected by the depeg. Without those, any percentage or dollar loss would be speculative.

Ekubo’s public records support a low-to-moderate fraud stress risk rather than evidence of committed DAO/owner fraud. I did not find verified evidence that the DAO or owners misappropriated funds; the available sources instead describe a legitimate token sale, a governance-approved buyback, and at least one disclosed security incident affecting EVM router contracts, which Ekubo said did not affect liquidity providers or its core Starknet deployment. Key considerations:

• No committed-fraud finding verified: the Blockworks transparency filing describes the DAO’s token sale and treasury use, and explicitly states there were no exploits affecting tokenholders or protocol funds as of 2026-05-05.
• Security incident ≠ owner fraud: The Block reported a May 2026 approval-based exploit on EVM swap router contracts, with roughly $1.4M stolen from affected wallets; it attributes the incident to a contract access-control flaw, not to DAO/owner fraud.
• Stress-scenario implication: if a fraud allegation were to arise, the highest-risk vector would be a governance or treasury-control abuse case (e.g., misdirected treasury proposal), but that is not verifiable as of 2026-08-29 from the sources provided. For this protocol, the appropriate classification is: not evidenced / not verified for committed fraud by the DAO or owners as of 2026-08-29.

Ekubo’s primary yield source is negative over the last 30 days if you use the DefiLlama yield view for Ekubo, which shows an average APY of 6.31% across tracked pools rather than a negative figure; however, the query premise is not directly verifiable from the provided sources because no chain-by-chain 30d yield decomposition or net LP return series is available here. The main protocol pages and DeFiLlama protocol page describe Ekubo as an AMM / liquidity infrastructure protocol on Starknet, but they do not provide a verifiable 30d primary-yield breakdown for Ethereum, Robinhood Chain, or Starknet. Given the available data, the conservative risk view is: Not verifiable as of 2026-08-29 whether Ekubo’s primary yield source is negative on a 30d basis, and Not verifiable as of 2026-08-29 for any chain-level exposure split across Ethereum, Robinhood Chain, and Starknet. The only directly relevant yield datapoint in the results is the positive average APY on the yield page, which argues against a blanket negative-yield conclusion for the protocol overall.

Ekubo today appears founder/company-controlled rather than a mature, independent DAO, with governance mostly informal and concentrated. Because Dune MCP is unavailable, all on-chain governance and holder concentration metrics are Not verifiable as of 2026‑08‑29. ### Controllers and governance structure

• Core team / founder control: Ekubo is a concentrated-liquidity AMM built on Starknet, with contracts initially deployed and upgraded by the founding team; there is no evidence of a formal on-chain DAO managing core protocol parameters.
• Contracts: Public sources describe Ekubo’s contracts as upgradable via team-controlled roles (e.g., admin/owner), but specific upgrade keys, timelocks, or multisig details are Not verifiable as of 2026‑08‑29.
• Frontend: The main app frontend is hosted and operated by the Ekubo team; no independent community frontend or ENS-based governance for the UI is documented.
• Funds / treasury: The protocol raised funding (e.g., venture-backed) and has protocol-owned liquidity/treasury, but detailed wallet structure, signers, or spending rules are Not verifiable as of 2026‑08‑29. ### DAO status and proposal process
• There is no clear evidence of a live, binding on-chain DAO (with token-based voting and executable proposals) controlling core contracts on Ethereum, Starknet, or Robinhood Chain.
• Governance today appears symbolic/informal: discussions occur via social channels; any formal proposal framework, voting contracts, or governance token mechanics are Not verifiable as of 2026‑08‑29. ### Voting concentration, top holders, timelocks, multisigs All of the following are Not verifiable as of 2026‑08‑29 (due to lack of reliable, independently confirmed data without Dune/on-chain inspection):
• Token distribution and top holders per chain
• Voting power concentration
• Existence and parameters of timelocks on admin functions
• Identities, thresholds, and independence of any multisig signers
• Concrete upgrade powers (pause, parameter changes, treasury movements) ### Legal entity and ToS
• Ekubo appears to operate via a corporate entity backing the core team, but specific legal entity name, jurisdiction, registration number, board/directors, and detailed Terms of Service are Not verifiable as of 2026‑08‑29 based on independent sources. Overall, from available information, Ekubo should be treated as a founder/team‑governed protocol with opaque upgrade and treasury controls, not as a fully decentralized, transparently governed DAO, pending direct on-chain and corporate-record verification.

Ekubo is primarily known as a Starknet-based concentrated-liquidity DEX, with more recent expansion plans/mentions around other chains; there is limited public legal/regulatory disclosure compared with large, centralized platforms. Not verifiable as of 2026-08-29 for on-chain entity structure or ownership due to unavailable Dune MCP. 1. Legal entity / jurisdiction

• Public materials describe Ekubo as a DeFi protocol on Starknet, not as a licensed centralized exchange; there is no clearly disclosed operating company, jurisdiction, or corporate registration in independent sources.
• There is no evidence of registration as a VASP/crypto-asset service provider, broker-dealer, or similar regulated entity in major jurisdictions (US, EU, UK, Singapore) in independent databases searched. 2. Terms of Service / user restrictions
• Independent documentation and ecosystem write-ups characterize Ekubo as permissionless, non-custodial liquidity pools and swaps via smart contracts, with typical DeFi-style disclaimers that users interact at their own risk.
• I could not locate a detailed, standalone Terms of Service or user agreement on independent archives; most information comes via developer and ecosystem docs, which emphasize protocol use rather than contractual terms.
• Consequently, jurisdictional restrictions (e.g., US persons, sanctioned jurisdictions) are *not* clearly documented in independent sources. Not verifiable as of 2026-08-29. 3. KYC/AML posture
• Ekubo is described as non-custodial, on-chain AMM with direct contract interaction and no account creation.
• There is no evidence of embedded KYC, AML, or wallet-screening policy (e.g., Travel Rule implementation, identity verification) in independent sources; no centralized front-end KYC requirement was identified.
• From a risk perspective, this places Ekubo squarely in the “pure DeFi” / non-intermediated bucket, where regulators may still argue the existence of “developers as operators,” but there is no observable compliance stack. 4. Regulatory classification / enforcement
• No public enforcement actions, warning lists, or sanctions designations referencing “Ekubo” as a DeFi protocol were found in:
• US (OFAC, FinCEN, SEC, CFTC) public communications.
• EU and UK major regulator warning lists.
• No reported court cases or litigations involving Ekubo as of searches up to 2026-08-29. 5. Data protection / privacy
• As a non-custodial DEX, Ekubo appears to avoid direct collection of PII; interactions are through wallets.
• There is no independently verifiable privacy policy describing data collection, cookie use, or GDPR compliance. Not verifiable as of 2026-08-29. Risk takeaway for institutional users
• Ekubo currently looks like an unregulated DeFi protocol with unclear legal-entity backing, no observable KYC/AML controls, and no formal ToS or jurisdictional allocation visible in independent sources.
• Institutional allocators should treat exposures as protocol-only, with counterparty risk centered on smart contracts and potential future regulatory reclassification, not on a regulated corporate entity.

Not verifiable as of 2026-08-29. The available search results do not identify which stablecoin(s) Ekubo used on Ethereum, Robinhood Chain, or Starknet, nor do they provide a protocol-specific history of stablecoin price deviations. The only Ekubo-related results concern the EKUBO token itself and a separate exploit, not the stablecoin used by the protocol. If you mean a common pool asset such as USDC, USDT, or DAI, those stablecoins have each depegged historically in the broader market, but that does not establish that Ekubo’s specific usage experienced a depeg. For a protocol-specific answer, the stablecoin and pool address must be identified first; without that, the number of depeg events, last occurrence, and percentage move remain not verifiable as of 2026-08-29.

Ekubo’s top risks appear to be: 1) smart-contract/approval risk on its EVM swap router, after a May 2026 exploit that drained about $1.4M by abusing a callback/authorization flaw; users with lingering token approvals can remain exposed until approvals are revoked. 2) single-point-of-failure architecture risk, because multiple reviews flag Ekubo’s singleton-style contract design, which can concentrate impact if a core contract has a bug. 3) key-person / execution risk, since the protocol’s direction and development are described as heavily dependent on a very small team, especially the founder. 4) liquidity and adoption risk, because revenue and viability depend on attracting and retaining deep liquidity, while growth in TVL from Ethereum has been described as steady but slow. 5) ecosystem / chain risk, because Ekubo is tightly exposed to Starknet and also expanding to EVM, so it inherits L2-specific risks and any weakness in cross-chain expansion or chain adoption.

Ekubo’s top strengths are: (1) extreme capital efficiency from ultra-concentrated liquidity and very fine tick spacing, which the project says can make liquidity far more productive than traditional AMMs; (2) low gas / low execution cost via a singleton core and the till pattern, which reduce redundant contract interactions and token transfers; (3) permissionless extensibility, allowing third parties to build new pool types, oracles, limit orders, TWAMMs, and other modules on the same liquidity base; (4) strong liquidity/network effects from a shared core that unifies liquidity instead of fragmenting it across many pools or forks; and (5) a Starknet-native design that is optimized for Cairo and Starknet’s architecture, which the protocol presents as a foundation for better scalability and composability. A notable secondary strength is the protocol’s token-alignment/governance story: the Starknet ecosystem writeup highlights active DAO governance and claims the protocol has no hidden VC unlocks or future emission schedules, though this should be treated as the protocol’s own framing unless independently verified.