Ekubo Protocol

Pack the exact interface auction config and prepare mint plus sellAmountByAuction, including approval or native value and deterministic token ID.

Prepare collection of creator proceeds for an auction NFT with pending owner validation.

Run the interface-equivalent phased fix-price workflow: provide exact pending pool-price read calldata, then exact router quote calldata, then approvals and target-price execution calldata. The wallet never constructs a route or transaction.

Prepare the canonical Lido submit call with exact native ETH value and an explicit or zero referral. The agent must read current staking pause and limit state directly; the wallet then simulates the exact transaction.

Prepare a direct wstETH unwrap call for an exact share amount, returning rebasing stETH to the sender.

Prepare claimWithdrawal for one finalized, unclaimed unstETH request ID owned by the sender. The agent must verify ownership and finalization directly through the user's wallet/RPC before preparation.

Prepare one or more bounded stETH withdrawal requests with an exact queue approval and cleanup. This irreversible asynchronous action mints unstETH NFTs, stops rewards while queued, and can settle below 1:1 after extraordinary losses; wallet simulation and clear user review are required.

Prepare an exact stETH approval, wstETH wrap call, and allowance cleanup in one atomic wallet plan.

Prepare a v3 position mint or add_liquidity, initializing a new pool at initial_tick when requested, with every approval, refund and cleanup step. Ekubo ticks use base 1.000001, so tick = ln(price in base units) x 10^6 and a Uniswap-style 1.0001 calculation is 100x too small. The token ratio follows the range and current price: do every swap first, re-read the tick with the pool's current_state_query, then mint once. If the wallet lacks one side, execute that swap separately and size the deposit from the measured balance after its receipt, never a quoted output. See ekubo://docs/lp-position-workflow.

Prepare collection of all accrued fees from an owned standard position or rewards from an owned Ve33 position, keeping its liquidity and NFT. Run its current_state_query first: require every inner call to succeed and the decoded owner to equal expected_owner, and pass the decoded fees or rewards to the wallet with the plan.

Prepare the exact safeTransferFrom transaction for an owned LP position and include pending ownership validation. The position, liquidity, and unclaimed earnings move together.

Prepare partial or full withdrawals from one or more owned positions in one plan, collecting fees or Ve33 rewards and keeping the NFTs. Read each position's current_state_query first and request no more liquidity than it decodes; require every inner call to succeed and owner to equal expected_owner. Hand the wallet every principal and earnings estimate and recipient.

Compute the exact Q32 boost rates and prepare all token approvals, native value, and boost calldata used by the interface.

Prepare one Distributor claim for every Merkl reward token the sender holds on a chain, from amounts and proofs fetched from https://api.merkl.xyz/v4/users/{address}/rewards/summary. The proofs are folded into their Merkle root here, and the read bundle checks it against the root the chain enforces, so Merkl's API need not be trusted. Distinct from prepare_rewards_claim, which claims Ekubo's own incentive drops.

Prepare an exact-approval Morpho Vault V2 deposit through the official SDK's VaultBundlesV1 route. The caller supplies a fresh RAY-scaled max share price, which is enforced onchain against ERC-4626 share-price inflation; shares are minted to the sender and the server performs no data fetch.

Prepare a direct Morpho Vault V2 redemption for an exact share amount. Prefer redeem for full exits so the user's complete fresh share balance can be bound without asset/share rounding dust.

Prepare a direct Morpho Vault V2 withdrawal for an exact underlying-asset amount from a fixed vault. Current shares, liquidity, permissions, and vault state are established by direct agent discovery and exact wallet simulation.

Prepare the interface's permissionless Oracle expandCapacity call for one ERC-20 token.

Prepare one permissionless maybeInitializePool transaction for a v3 PoolKey and initial tick; prepare_lp_position_deposit with pool_initialized=false does the same atomically with the mint.

Prepare the exact selected ended-order collections, protocol-fee withdrawals, and token rolls in interface order within one atomic batch of decodable steps.

Prepare one Incentives claim or the interface's allow-failure Multicall3 aggregate for multiple claims.

Prepare an exact USDS approval, ERC-4626 sUSDS deposit, and allowance cleanup as one atomic wallet plan. The direct vault interface has no minimum-shares or deadline field, so a fresh preview and exact wallet simulation are mandatory.

Prepare a direct sUSDS ERC-4626 redemption for an exact share amount. Use a fresh wallet/RPC balance and preview, then require exact wallet simulation before authorization.

Prepare a direct sUSDS ERC-4626 withdrawal for an exact USDS amount. The server does not query current exchange rate, capacity, balance, allowance, or preview state.

Prepare one atomic-capable plan of 1 to 4,096 ordered native, ERC-20, ERC-721 and ERC-1155 transfers on one EVM chain, mixed freely. Returns a compact summary and the execution_plan_reference.

Prepare one or more TWAMM order splits with approvals and native value as one atomic batch. details.token_id is the order's id before anything is sent: keep it, because prepare_twamm_order_collection and prepare_twamm_order_stop are keyed by it and orders are not enumerable by owner. Start and end times must be multiples of 256 seconds near the present, widening in powers of 16 further out.

Prepare collection of every selected order key through the exact current or legacy Orders manager, as one atomic batch of decodable steps, with pending owner validation.

Prepare the interface's complete stop flow: collect every selected order and decrease every still-active sale rate in one atomic batch of decodable steps.

Prepare the permissionless lockAndExecuteVirtualOrders maintenance call for a current or legacy TWAMM pool.

Return exact wallet read bundles for pool state, reserves, positions and ownership. V3 supports bounded owner-index enumeration. V4 requires known token IDs. Verify returned tokens, fee, factory/pool key, tick spacing and owner before preparing liquidity operations.

Add liquidity or create a V2 pair with exact token approvals and cleanup. Amounts are raw units; sorted token0/token1 and explicit minimum outputs are required. use_native pays ETH for the wrapped-native side. Execute atomically through the wallet.

Burn an exact LP amount through the canonical V2 router; realize accrued fees with principal. Raw minima protect withdrawal proceeds. LP token address is derived from the factory. Optional native unwrapping. V2 has no separate fee claim. Requires atomic LP approval and cleanup.

Mint a ranged NFT or increase token_id with raw desired amounts and minima. First verify factory fee tick spacing and position tokens/range. Optional initialize_sqrt_price_x96 creates the pool; use_native pays ETH and refunds excess. Exact approvals and cleanup require an atomic wallet.

Collect all owed fees without removing liquidity, optionally unwrapping WETH. Verify NFT ownership and currencies first. V3 collect has no onchain deadline; regenerate and simulate before execution.

Decrease exact uint128 liquidity, collect principal and all accrued fees, and optionally burn a fully emptied NFT. Raw minima protect withdrawal proceeds. Optional unwrap_native requires verified position currencies.

Mint or increase an exact liquidity amount using raw uint128 token maxima. Zero token0 means native ETH. Uses exact ERC20 and Permit2 approvals with cleanup, settles both signs of accrued-fee deltas on increase, and refunds native surplus. Verify NFT pool key/range and hook behavior; hook_data is forwarded unchanged. Optional pool initialization.

Poke a V4 position with zero liquidity decrease then take both currencies to the sender. Principal remains invested. Verify ownership, pool key and hook behavior first.

Remove liquidity and take principal plus fees to the sender. Optional burn:true requires liquidity:0 and withdraws the entire NFT with minima applied to the full position. Requires exact pool currencies and hook data; uint128 minima bound principal outputs.

Discover every active vote on VeTokens owned by the sender and generate one atomic batch of decodable VeToken steps claiming all indexed pool fees, with ownerOf and voteState validation calldata. Fees only: votes, stake amounts, lock ends, and NFT ownership are all unchanged.

Generate one call, or an atomic batch of decodable VeToken steps, claiming voter fees from one or more ve-tokens. Fees only: votes, stake amounts, lock ends, and NFT ownership are all unchanged, so this is always safe to run before any other ve(3,3) action.

Remove the active vote from one or more ve-tokens, claiming each stake's current pool fees immediately before its clearVote in one atomic batch. Use this instead of raw clearVote calldata: Ve33 discards pending voter fees when a stake's weight goes to zero, and a current_pool_key that is not the stake's active pool reverts the whole batch. Stake amount, lock end and NFT ownership are untouched; the stake stops directing emissions and earning that pool's voter fees. Prefer prepare_ve33_reallocation when votes move to other pools. See ekubo://docs/ve33-workflow.

Prepare a direct extension for an unvoted VeToken or an atomic claim-and-extend call when current_pool_key identifies an active vote, so pending voter fees are preserved. Extending moves the stake to a later end time and clears its vote — that is why the claim is compounded into the same call. A stake's end time only ever moves later, here and everywhere else in Ve33. No NFT is burned and no stake leaves the wallet; re-vote afterwards with prepare_ve33_vote. max_duration=true must be the user's explicit choice.

Prepare the exact approval/native value and increaseStakeAmount call while preserving the existing vote and fee accounting. Non-destructive: the vote is resized rather than cleared, no fees are discarded, and no NFT is burned. The added stake takes the NFT's existing lock end, so it cannot be withdrawn before that time.

Prepare fee-safe merging of one or more source NFTs into a destination, including required claims and the selected resulting vote in one atomic batch of decodable steps. Destructive to the sources: each source's stake moves to the destination, its vote is cleared, and the source NFT is burned, so its fees are claimed first and its ID is reported in the plan. The destination keeps its own lock end, which is why no source may end later than it.

Compile a reviewed current allocation into at most 25 target pool-weight shares as one atomic batch of decodable VeToken steps. The default path only claims, splits, and votes: nothing is burned, no lock is extended, and nothing is withdrawn. The optional compact_max_lock strategy fee-safely consolidates active NFTs, extends the survivor to four years, then creates exactly one voting NFT per target; it burns every merged source NFT and lengthens the lock, and explicitly discloses both. Show the get_ve33_allocations result first and pass its exact state_id; hand the wallet the survivor, every burned source, the extension, and the decoded calls. See ekubo://docs/ve33-workflow.

Build the safe phased workflow for 'reinvest my fees': automatically claim all active voter fees, prepare one exact-input swap per claimed non-stake token, then increase one VeToken or every existing active allocation without changing ownership or replacing votes. phase=swap returns jurisdiction metadata inline on the result and on every child swap; it is not permission to trade. For a nonempty restricted_jurisdictions list, follow its execution_notice before requesting any signature. Phases run in order after each confirms: claim (omit claims to discover every active allocation; keep the pre-claim balance snapshots), swap with only the exact claimed deltas, never a pre-existing balance, then stake_all with the refreshed state_id and the measured STONX output.