feat(dex): add Ekubo v3 trades on Robinhood Chain to dex.trades

[moodysalem]

Summary

Adds Ekubo v3 on Robinhood Chain to dex.trades.

Ekubo Core is deployed at the same deterministic address on Robinhood Chain as everywhere else — 0x00000000000014aA86C5d3c41765bb24e11bd701, created at block 33534 (2026-06-04). It is currently Ekubo's busiest deployment, and none of it reaches dex.trades today:

chain	Core swap records, last 14d
robinhood	272,833
ethereum	128,320
arbitrum	110
base	2

The chain hosts Ekubo's ve(3,3) deployment ("STONX") — tokenized equities (AAPL, NVDA, TSLA, GME, SPY, GOOGL, COST…) and ETH quoted against USDG. Those pools have done roughly $21.4M of volume across ~133k swaps in the first nine days since launch.

Approach

This is a straight mirror of the existing ekubo_v3_ethereum models and reuses the shared macros unchanged:

• ekubo_compatible_pools — pools from the decoded PoolInitialized event
• ekubo_compatible_liquidity_events — swaps from Core's topic-less (log0) swap records, exactly as on Ethereum

One thing worth calling out for reviewers, because it looks unusual at first glance: Ekubo Core has no Swapped event in its ABI. Swaps are written with a raw log0 to save gas, which is why the shared macro reads {{ source(blockchain, 'logs') }} with topic0 is null and slices the packed payload rather than joining a decoded event table. That is pre-existing behaviour on Ethereum, not something introduced here.

The swap record is 116 bytes:

extension(20) | poolId(32) | delta0(int128) | delta1(int128)
              | sqrtRatio(12) | tick(int32) | liquidity(uint128)

so poolId = substr(data, 21, 32), delta0 = substr(data, 53, 16) and delta1 = substr(data, 69, 16), sign-extended as int128 — which is what the macro already does.

Native ETH is mapped to WETH 0x0bd7d308f8e1639fab988df18a8011f41eacad73, matching the macro's convention on other chains.

Files

New:

• dbt_subprojects/dex/models/_projects/ekubo/robinhood/ekubo_v3_robinhood_pools.sql
• dbt_subprojects/dex/models/_projects/ekubo/robinhood/ekubo_v3_robinhood_base_liquidity_events.sql
• dbt_subprojects/dex/models/_projects/ekubo/robinhood/_schema.yml
• dbt_subprojects/dex/models/trades/robinhood/platforms/ekubo_v3_robinhood_base_trades.sql
• dbt_subprojects/dex/seeds/trades/ekubo_v3_robinhood_base_trades_seed.csv
• sources/_sector/dex/liquidity/robinhood/_sources.yml

Modified:

• dbt_subprojects/dex/models/trades/robinhood/dex_robinhood_base_trades.sql — register the platform model
• dbt_subprojects/dex/models/trades/robinhood/_schema.yml — model docs + check_dex_base_trades_seed
• dbt_subprojects/dex/seeds/trades/_schema.yml — seed column types
• dbt_subprojects/dex/models/_projects/ekubo/ekubo_pools.sql, ekubo_base_liquidity_events.sql — add robinhood to the aggregators

Dependency: contract decoding (submitted)

These models reference ekubo_v3_robinhood.core_evt_{poolinitialized,positionupdated,positionfeescollected,feesaccumulated}. Ekubo Core is already decoded on ethereum/arbitrum/base (ekubo_v3_multichain); Robinhood Chain has now been submitted for decoding under the same ekubo_v3 / Core project+contract naming, so it should join that multichain table.

⚠️ Until that decoding completes, CI will fail on the missing source — the models cannot build without it. Happy to leave this open until the tables appear, or re-run CI then; just let me know which you prefer. Nothing else in the PR is waiting on anything.

Note the swap side needs no decoding at all, but the poolId → token mapping comes from the decoded PoolInitialized event, which is why the dependency exists.

See the comments below for a registry problem on robinhood that may block that submission.

Testing

• dbt parse — passes
• dbt compile --select ekubo_v3_robinhood_pools ekubo_v3_robinhood_base_liquidity_events ekubo_v3_robinhood_base_trades — passes; compiled SQL reviewed
• Seed fixture: 40 real Robinhood trades from 2026-08-01, generated with the same sign-extension and buy/sell-side logic the model uses

I develop Ekubo Protocol, so happy to answer anything about the contracts or the log encoding.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[cursor]

PR Summary

Medium Risk
Adds a large new trade feed to dex.trades with swap parsing from raw liquidity events; correctness hinges on external contract decoding and chain-specific WETH mapping, but the pattern matches existing Ekubo v3 chains.

Overview
Adds Ekubo v3 on Robinhood Chain into dex.trades and the cross-chain Ekubo pool/liquidity unions, using the same ekubo_compatible_pools and ekubo_compatible_liquidity_events macros as Ethereum (Core at 0x00000000000014aA86C5d3c41765bb24e11bd701, start block 33534, Robinhood WETH).

New Robinhood models cover pools, liquidity events, and base trades (swaps derived from liquidity events with event_type = 'swap'). dex_robinhood_base_trades unions in ekubo_v3_robinhood_base_trades. Decoded sources are declared under ekubo_v3_robinhood (PoolInitialized, position/fee events). A 40-row seed and check_dex_base_trades_seed guard trade shape.

Note: builds depend on Robinhood Ekubo Core decoding being available; CI may fail until those source tables exist.

^{Reviewed by Cursor Bugbot for commit 5da9cbe. Configure here.}

[moodysalem]

⚠️ Ekubo Core is mis-registered as uniswap_v4 / PoolManager on Robinhood Chain

While filing the decoding submission this PR depends on, I hit a problem: Ekubo Core is already present in Dune's decoding registry on robinhood, but under the wrong project and ABI.

Evidence query: https://dune.com/queries/8262394

chain	address	namespace	name	abi_id
robinhood	0x00000000000014aA86C5d3c41765bb24e11bd701 (Ekubo Core)	uniswap_v4	PoolManager	2c87fbca…
robinhood	0x8366a39cc670b4001a1121b8f6a443a643e40951 (genuine PoolManager)	uniswap_v4	PoolManager	2c87fbca…
ethereum	0x00000000000014aA86C5d3c41765bb24e11bd701	ekubo_v3	Core	2dac1f79…
arbitrum	0x00000000000014aA86C5d3c41765bb24e11bd701	ekubo_v3	Core	2dac1f79…
base	0x00000000000014aA86C5d3c41765bb24e11bd701	ekubo_v3	Core	2dac1f79…

Ekubo Core is deployed at the same CREATE2 address on every chain, and is correctly registered as ekubo_v3 / Core on ethereum, arbitrum and base. Only the Robinhood entry is wrong, and it carries the exact same abi_id as the genuine Robinhood Uniswap v4 PoolManager.

Could someone explain how this happened? Ekubo Core and the Uniswap v4 PoolManager share no bytecode, no ABI and no deployer, so an automatic bytecode or ABI match shouldn't be possible. My guess is a multi-instance or bytecode-matching submission of the PoolManager that over-matched, but I'd rather understand it than assume.

Impact

Good news first: no data is corrupted. Ekubo Core's event topic0s don't match any Uniswap v4 event signature, so the mis-registration decodes to zero rows. uniswap_v4_robinhood.poolmanager_evt_{swap,initialize,modifyliquidity} contain only 0x8366a3…, so dex.trades Uniswap v4 numbers on Robinhood are unaffected.

The problem is that it blocks the correct decoding:

1. A submission of 0x0000…14aA under ekubo_v3 / Core for robinhood is liable to be auto-rejected as "already decoded", since the registry believes that address is covered.
2. Until that is resolved, ekubo_v3_robinhood.core_evt_poolinitialized can't exist — which is the one dependency of this PR.

Ask

Could the decoding team remove or correct the uniswap_v4/PoolManager entry for 0x00000000000014aA86C5d3c41765bb24e11bd701 on robinhood, so the pending ekubo_v3/Core submission can go through and join the existing ekubo_v3_multichain tables?

It's also worth checking whether the same over-match hit other addresses on robinhood — if one non-PoolManager address was swept in, others may have been too.

Happy to open this as a separate issue or take it to the #decoding Discord channel if that's a better venue than this PR — just say which.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{Bugbot Autofix is ON, but it could not run because the branch was deleted or merged before autofix could start.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 5da9cbe. Configure here.}

[moodysalem]

Follow-up: the over-match is not limited to Ekubo Core — it looks systemic on robinhood.

Evidence query: https://dune.com/queries/8262401

chain	addresses registered as uniswap_v4/PoolManager	addresses actually emitting Swap	over-matched
robinhood	2,704	1	2,703
ethereum	1	1	0
base	1	1	0
arbitrum	1	1	0

Every other chain has exactly one PoolManager registered, as expected. Robinhood has 2,704, of which only 0x8366a39cc670b4001a1121b8f6a443a643e40951 ever emits a Uniswap v4 Swap. Ekubo Core is simply one of the 2,703 unrelated addresses swept in.

A sample of the over-matched set:

0x00000000000000304861c3adfb80dd5ebec96325
0x00000000000001e541f0d090868fbe24b59fbe06
0x0000000000001aa7a7f7e29abe0be06c72fd42a1
0x0000000000006e2f9d80caec0da6500f005eb25a
0x000000000000b1c70df4dc2ccf86372714e14154
0x00000000000014aa86c5d3c41765bb24e11bd701   <- Ekubo Core

They're heavily weighted toward leading-zero vanity addresses, which makes me suspect an address-pattern or prefix-based match rather than a true bytecode match — but that's speculation, hence the ask for an explanation.

To restate the impact, since the number looks alarming: no query results are wrong today. The over-matched addresses emit no Uniswap v4-shaped events, so they contribute zero rows and dex.trades is unaffected. The harm is that these addresses are now claimed in the decoding registry, which blocks their correct decoding — exactly what this PR is waiting on for Ekubo Core.

So the ask broadens slightly: rather than just fixing the one Ekubo entry, it's probably worth purging the 2,703 non-emitting uniswap_v4/PoolManager registrations on robinhood and understanding what produced them, in case other chains onboarded the same way.

[moodysalem]

Pushed an update addressing the review and integration state:

• merged current upstream main at f2eca3f; the Robinhood registry conflicts were additive, so all newly merged upstream DEX models are preserved alongside Ekubo
• added not_null tests for every new incremental MERGE key in ed652ca
• verified a full dbt parse and targeted dbt compile for the pools, liquidity-events, and base-trades models

I also rechecked the Dune catalog: the Robinhood Ekubo decoded source is still absent, while the Core address is still associated with the incorrect uniswap_v4 / PoolManager decoding. That external decoding issue remains the dbt CI blocker described above.

@cursor review

[moodysalem]

I have read the CLA Document and I hereby sign the CLA