Ekubo Interface

Showing 25 of 100 from the live probe.

• List Ekubo tokens

  First step for symbol-based swaps, including tokenized stocks and stablecoins: list the canonical Ekubo token list, ordered by descending visibility_priority so the preferred token wins ambiguous symbol matches. Pass search to match a symbol prefix or suffix, chain_id to stay on one chain, and min_visibility_priority to reach tokens the interface hides by default.

• Export Ekubo tokens for a wallet

  Hand a wallet the canonical token list without reading it. Returns only a token_list_reference envelope and the count it stands for: no entries, so nothing enters your context that you would only pass on. Use this to import token names into a wallet so it can label transactions, or to name the addresses for a bulk balance read; pass the envelope unchanged as the wallet tool's reference argument. The stored body carries exactly what a wallet acts on — chain ID, address, symbol, name, decimals — a

• Get an Ekubo token

  Fetch canonical token metadata for an exact chain and address.

• Get multiple Ekubo tokens

  Fetch canonical metadata for 1 to 1,000 exact token identifiers in one batch request. Tokens may span chains. Results preserve input order and duplicates; identifiers absent from the canonical token list are omitted.

• Get swap or bridge quotes with execution plans

  Beware jurisdiction restrictions: a quote or execution plan is not permission to trade. For a nonempty restricted_jurisdictions list, before requesting transaction signatures or submitting any approval or swap, the agent/wallet must evaluate the user's connection jurisdiction against restricted_jurisdictions. If it is restricted or unknown, obtain the user's explicit attestation that they are not legally domiciled in any listed jurisdiction; never infer domicile from an agent/server IP or attest

• Track a LayerZero or LI.FI cross-chain transfer

  Report where an executed LayerZero or LI.FI transfer has got to, from origin submission through delivery on the destination chain. A bridge is the one execution plan whose successful origin receipt does not mean the user has their funds, so this is how a cross-chain transfer is confirmed finished rather than merely sent. Pass source set to the executed quote's source. For layerzero, call it with that option's provider_quote_id and the origin transaction_hash, which some route types require rathe

• Prepare one ve(3,3) NFT vote change

  Compile one actively voted ve-token into multiple allocations. Unconditionally claims its current pool first, then splits and changes votes in one atomic batch of decodable VeToken steps. Nothing is burned, withdrawn, or transferred: the source keeps a stake and every additional allocation is a newly minted NFT with the same lock end. Prefer the portfolio reallocation workflow for complete state validation.

• Prepare a ve-token extension

  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.

• Prepare a new ve-token stake

  Create a new VeToken stake with an exact stake-token approval. Max duration is the safe default for new stakes; an explicit shorter duration is optional and no existing NFT, vote, fee balance, or ownership is changed.

• Prepare a ve-token split

  Split a source ve-token with an explicit salt and return the deterministic child token ID; the source vote is preserved with reduced weight and the child starts unvoted with the same lock end. Non-destructive: no stake leaves the wallet, no NFT is burned, no vote is cleared, and no fees are discarded.

• Prepare ve-token fee claims

  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.

• Prepare ve-token fee reinvestment

  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.

• Prepare all ve-token fee claims

  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.

• Prepare ve-token vote clearing

  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 a stake's pending voter fees when its weight goes to zero, and the required current_pool_key reverts the whole batch with PoolNotVoted if it is not that stake's active pool, so no vote is cleared against a stale key. Nothing is burned, withdrawn, split, merged, or transferred: stake amount, lock

• Show Ekubo STONX / ve(3,3) allocations

  Use for requests such as 'show all my Ekubo STONX allocations'. The production Ekubo ve(3,3) deployment is the STONX voting system, so pass only owner to select its production chain and canonical VeToken automatically. Returns every pool, selected swap fee, NFT, applied vote weight, totals, state_id, and an onchain_validation request explicitly marked not_executed until the client runs its eth_call. Pass chain_id and ve_token together only for another deployment.

• Get suggested STONX allocations

  Return a provider-neutral STONX allocation recommendation and an exactly 10,000-bps executable target list capped at 25 initialized canonical Ve33 pools. The upstream snapshot refreshes at most once a day: past a day old a refresh is attempted and awaited, but the existing snapshot still answers the request when that refresh does not land, and only a snapshot older than a week is refused. Read snapshot_age_seconds to see how old the answer actually is. The tool constructs no transaction; use com

• Prepare atomic ve(3,3) reallocation

  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.

• Get Ekubo positions by owner

  Enumerate an owner's indexed Ekubo position NFTs without relying on ERC721 enumeration. Returns pool keys, bounds, liquidity, current indexed pool state, rewards, and pagination. Optionally filter by chain and opened/closed state.

• Get an Ekubo pool

  Resolve an exact chain/core/pool ID to its PoolKey and decoded config, verify that the key hashes back to the requested ID, and return the latest indexed pool-state snapshot plus a current_state_query read bundle: pass its read_calls_reference unchanged as wallet_batch_eth_call's reference argument for fresh on-chain sqrtRatio, tick, and liquidity.

• Get Ekubo pool liquidity depth

  Return tick-level net liquidity deltas for one exact chain/core/pool ID. Accumulate the deltas in ascending tick order to reconstruct active liquidity depth.

• List Ekubo pool keys

  Discover initialized pools for one chain and Core deployment with keyset pagination: pools are ordered by ascending pool_id and after_pool_id fetches the next page. Filter by one token, an exact pair, or an extension (zero address means extensionless). Every returned pool_id is independently re-derived from its PoolKey, and each row carries the indexed state snapshot (null until the pool has indexed state).

• Derive an Ekubo pool ID

  Pack or accept an exact PoolKey config and derive pool_id = keccak256(abi.encode(PoolKey)). The uint64 Q64 fee is string-only so JavaScript cannot silently round it.

• Decode an Ekubo pool config

  Decode the packed bytes32 extension, exact uint64 Q64 fee, concentrated/stableswap discriminator, and tick spacing or stableswap parameters. The fee is never returned as a JSON number.

• Get complete Ekubo position details

  Hydrate one indexed owner position with the same inputs used by the interface: pool key, bounds, indexed liquidity and pool state, NFT metadata, event history, campaigns and earned rewards, token metadata and USD prices, plus an exact pending Multicall3 eth_call and nested decode plan for current principal, fees or Ve33 rewards, and owner.

• Find pools for an LP position

  List existing indexed pools for a token pair without browsing the data API or reading contract ABIs. Returns v2/v3 Core generation, independently verified exact PoolKeys and pool IDs, pool type and extension classification, token USD metadata, 24-hour TVL/volume/fee/depth statistics, and the correct Positions or Ve33Positions manager for each candidate. Defaults to min_tvl_usd=0 so initialized low-liquidity pools remain visible.