feat: extend Ekubo V3 signed swap executor and encoder#1167
Conversation
66186dc to
f54fc20
Compare
| ); | ||
|
|
||
| offset = sigEnd; | ||
| } else if (poolConfig.extension() == MEV_CAPTURE_ADDRESS) { |
There was a problem hiding this comment.
Is there any way to add a test for this? Like importing the Ekubo code locally and deploying it to the test fork? Would that be too difficult?
There was a problem hiding this comment.
Added it, lmk what you think
| out = 'out' | ||
| libs = ['lib'] | ||
| evm_version = 'cancun' | ||
| evm_version = 'osaka' |
There was a problem hiding this comment.
The Ekubo V3 SDK uses the clz opcode (count leading zeros) in its tick bitmap code. clz is only available in the Osaka EVM — it doesn't exist in cancun.
Previously this didn't matter because our tests only imported Ekubo types and interfaces, which don't touch the bitmap code. The new test imports SignedExclusiveSwap.sol, which transitively pulls in bitmap.sol containing clz. Without evm_version = 'osaka', the compiler rejects it.
louise-poole
left a comment
There was a problem hiding this comment.
Only some minor comments from me! Looks good!
Scaffold SignedExclusiveSwap (forward-only) support under the existing ekubo_v3 protocol. The encoder appends a self-describing signed hop tail when Swap.user_data is set; EkuboV3Executor walks hops length-aware and routes signed hops through CORE.forward. Stub bodies (todo!()/revert) remain for the signed tail encoding and the forward call. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This reverts commit 5dad7aa. Foundry's createSelectFork overrides the evm_version from foundry.toml with the hardfork that was active on-chain at the forked block. The hardfork is determined by a hardcoded block-number table inside revm. Our Foundry version (1.5.1, built 2025-12-22) predates the Fusaka (Fulu-Osaka) activation on mainnet (block 23,935,694, 2025-12-03), so its table does not map post-Fusaka blocks to Osaka. As a result, the fork at block 24,218,590 runs under a pre-Osaka EVM, and Ekubo V3 contracts that use Osaka-era opcodes revert with EvmError: NotActivated. The vm.setEvmVersion("osaka") call after createSelectFork forces the forked EVM to enable Osaka opcodes regardless of the hardfork table. This workaround can be removed after updating Foundry to a version that includes the Fusaka block mapping. See: foundry-rs/foundry#13040 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
153d53d to
0bbe0fc
Compare
## [0.334.0](0.333.1...0.334.0) (2026-07-13) ### Features * extend Ekubo V3 signed swap executor and encoder ([#1167](#1167)) ([3d6a94f](3d6a94f)) * implement signed exclusive swap in EkuboV3 executor and encoder ([09bf7c6](09bf7c6)) * scaffold Ekubo V3 signed swap executor and encoder ([33268b9](33268b9)) ### Bug Fixes * Add Polygon to dev CI ([31cee12](31cee12)) * address review on incremental transaction cleanup ([bc966a1](bc966a1)) * replace transaction cleanup with lock-safe incremental procedure ([e5664e9](e5664e9)) * replace transaction cleanup with lock-safe incremental procedure ([#1157](#1157)) ([c57f532](c57f532)) * unpin evm version ([5767323](5767323)) ### Reverts * Revert "fix: unpin evm version" ([cf66eaa](cf66eaa))
|
This PR is included in version 0.334.0 🎉 |
Task
Adds SignedExclusiveSwap (forward-only) support to the existing ekubo_v3 executor and encoder.
ekubo signed exclusive swap extension