Rerange Skill

Use this skill when a user or agent needs to discover Rerange deployments, construct liquid orders, monitor order state, run permissionless reranges, manage user vault delegation, compose bounded strategies, or perform safety preflight checks.

Rerange is a non-custodial liquidity execution protocol:

intent -> directional concentrated-liquidity order -> monitored execution

Use @rerange/wagmi as the SDK boundary for ABIs, generated contract actions, and canonical deployment metadata. Do not reconstruct hub or vault addresses manually when the SDK can provide them.

SDK Execution

This skill includes a Node helper at {baseDir}/index.js.

Run it with:

node {baseDir}/index.js <command> [args]

The helper imports @rerange/wagmi; in this repository it can also fall back to the local built SDK at ../sdk/dist/index.js for development.

Commands:

• deployments [chainId]: print all supported deployments or one deployment.
• abi hub|vault: print the selected ABI from @rerange/wagmi.
• encode hub|vault <functionName> <jsonArgs>: encode calldata without signing.
• read <chainId> hub|vault <address> <functionName> <jsonArgs> [rpcUrl]: perform a read-only contract call.

Examples:

node {baseDir}/index.js deployments
node {baseDir}/index.js deployments 8453
node {baseDir}/index.js abi hub
node {baseDir}/index.js encode hub getOrderState '["0x...orderKey"]'
node {baseDir}/index.js read 8453 hub 0x8880b95E1a056d537FA7469D1a26C3875e85f0e7 hubConfig '[]' https://mainnet.base.org

The helper never signs transactions and never asks for private keys. For writes, return unsigned transaction intent, wagmi action name, target contract, calldata, value, and safety status so a wallet-connected runtime can simulate and submit.

Shared Rules

• Use getOrderState(orderKey) as the canonical order state read.
• Use previewOpen, previewRerange, and previewClose before submitting transactions.
• Treat target price as fixed user intent. Reranging moves the live liquidity window, not the execution objective.
• Keep token prices in user units until the integration boundary, then convert to ticks.
• Use canonical pool token order for token0 and token1; isSell identifies which token is being sold.
• Respect hubConfig.paused, hubConfig.rerangeCooldown, adapter safety checks, and gas economics.
• Never grant an agent withdrawal authority. setAgent is for scoped order management, not custody.
• Never request, store, or handle private keys or seed phrases.

Recommended Agent Flow

1. Run protocol discovery to resolve deployment metadata, token metadata, adapter allowlist status, pool data, and vault or order identity.
2. Run safety and risk checks before any state-changing action.
3. For a new user intent, build order parameters, then submit open or open2 only after fresh preview, funding, and simulation checks.
4. Persist the returned or emitted orderKey, then monitor with live getOrderState.
5. Use resolver rerange only for maintenance actions that pass preview, cooldown, adapter safety, and gas policy.
6. Use vault management only for owner-authorized vault, delegation, close, and direct withdrawal workflows.

Protocol Discovery

Use discovery before any other Rerange action. It resolves the chain, deployment, adapters, tokens, pools, vaults, order keys, and live hub config.

Required inputs:

{
  "chain_id": "<chain-id-from-deployments>",
  "owner": "<owner-address>",
  "from_token": "WETH",
  "to_token": "USDC",
  "order_key": "<order-key>",
  "vault": "<vault-address>",
  "order_index": 0
}

Only chain_id is always required. Interpret optional identifiers in this priority order: order_key, (vault, order_index), vault, owner.

Required reads:

• Deployment metadata from @rerange/wagmi.
• RerangeHub.hubConfig()
• RerangeHub.adapters(adapter)
• RerangeHub.vaults(owner) as the next vault index upper bound.
• RerangeHub.predictVault(owner, vaultIndex)
• RerangeHub.vaultOrderCount(vault)
• RerangeHub.getOrderKey(vault, orderIndex)
• RerangeHub.getOrder(orderKey) when reconstructing existing order metadata.
• RerangeHub.getOrderState(orderKey)

Pool selection must prefer pools where token order is canonical, adapter is allowed, usable liquidity exists near current tick, fee tier fits the execution horizon, and tokens are supported. Rank valid pools by live liquidity, then historical volume, then fee tier suitability. For large orders, require live or indexed liquidity data.

For a new order with no explicit vault, read vaults(owner), call predictVault(owner, vaultIndex), use that predicted address in previewOpen, then let open create the vault or create it explicitly with createVault.

Return a blocking error when the chain is unsupported, the hub is paused, adapter is not allowed, token is unsupported or ambiguous, no valid pool exists, an order key cannot be resolved, or required reads fail through healthy RPC.

Intent Order Builder

Use this for sell_high, buy_low, passive_exit, and rebalance_step intents. DCA and grid strategies are composed by the strategy composer.

Required inputs:

{
  "chain_id": "<chain-id-from-deployments>",
  "owner": "<owner-address>",
  "intent": "sell_high",
  "from_token": "WETH",
  "to_token": "USDC",
  "amount": "1.0",
  "target_price": 3500,
  "trigger_bps": 500,
  "pool": "<pool-address>",
  "risk_profile": "moderate",
  "referrer": "ZERO_ADDRESS",
  "keep_balances_in_vault": false,
  "unwrap_out": false
}

Construction rules:

1. Resolve deployment, tokens, adapters, and candidate pools.
2. Convert amount into raw token units using source token decimals.
3. Canonically sort the pool pair into token0 and token1.
4. Set isSell = true when source token is token0; otherwise false.
5. Convert target_price into targetTick using canonical pool token order.
6. Convert trigger_bps into triggerTicks, or default to the tick distance between current price and target.
7. Resolve risk_profile into concrete adapter policy values.
8. Encode adapter config with pool, fee tier, TWAP, tick drift, and slippage.
9. Call previewOpen(owner, params).
10. Return unsigned transaction parameters only after preview succeeds.

Risk profile defaults:

{
  "conservative": {"max_slippage_bps": 50, "max_twap_deviation_ticks": 50, "max_tick_deviation": 50},
  "moderate": {"max_slippage_bps": 100, "max_twap_deviation_ticks": 100, "max_tick_deviation": 100},
  "aggressive": {"max_slippage_bps": 150, "max_twap_deviation_ticks": 150, "max_tick_deviation": 150}
}

If no mapping is configured, ignore risk_profile and require concrete adapter policy fields.

Create order parameter shape:

{
  "vault": "ZERO_ADDRESS",
  "adapter": "<adapter-address-from-deployments>",
  "token0": "<canonical-token0-address>",
  "token1": "<canonical-token1-address>",
  "capital": "1000000000000000000",
  "isSell": true,
  "targetTick": -195000,
  "triggerTicks": 300,
  "adapterConfig": "<encoded-adapter-config>",
  "referrer": "ZERO_ADDRESS",
  "keepBalancesInVault": false,
  "unwrapOut": false
}

Use open(params) after approval or vault prefunding. Use open2(params, permit, signature) only when the owner provides Permit2. Always refresh previewOpen(owner, params) before submission.

Block order construction when target direction is wrong, capital is zero, hub is paused, adapter is not allowed, preview reverts, immediate flow has no activation plan, current tick drifted materially, funding cannot be proven, or the user asks to bypass slippage, TWAP, or liquidity checks.

Order Monitor

Use monitoring for open Rerange orders because they are persistent liquidity positions, not one-time swaps.

At least one of order_key, (vault, order_index), or owner is required.

Required reads:

• getOrderState(orderKey)
• isOrderClosed(orderKey)
• previewRerange(orderKey) for actionability
• hubConfig() for pause and cooldown state
• previewClose(orderKey) before user-requested close
• Events: OrderOpened, OrderReranged, OrderClosed, VaultCreated, OrderExecuted

Map live protocol state into agent states: OPEN, ACTIVE, IN_RANGE, OUT_OF_RANGE, RERANGEABLE, COMPLETED, CLOSED, and ACTION_BLOCKED. Never persist stale lifecycle state as truth; refresh from getOrderState.

Persist minimal memory: chain id, order key, owner, vault, order index, intent, tokens, target tick, trigger ticks, creation time, last seen status, last rerange time, and last progress bps. Reconstruct tokens from token0, token1, and isSell; do not invent symbols when metadata is missing.

Monitor active user-facing orders every 5 to 15 minutes, resolver candidates from every block to every 5 minutes, passive portfolio reports every 30 to 60 minutes, and event logs after restart or missed RPC intervals.

Do not infer final status from event logs alone. Do not trigger rerange purely because a range was exited; always preview and check cooldown.

Resolver Rerange

Use this for permissionless resolvers that advance or close orders by calling rerange or batchRerange. Resolvers do not need vault ownership. Resolver rewards are paid only from target-asset fees.

Build candidates from OrderOpened logs, local indexed open orders, watchlists, and OrderReranged events. Drop candidates when isOrderClosed(orderKey) is true.

Required reads per candidate:

1. getOrderState(orderKey)
2. hubConfig()
3. previewRerange(orderKey)
4. Current gas estimate and target-token value for expected reward.

For permissionless rerange(orderKey), enforce block.timestamp >= order.lastRerangeAt + hubConfig.rerangeCooldown.

A candidate is executable only when preview succeeds and will close, will activate, is economically justified while in range, price is inside the trigger band around target, or price crossed the target and the action will close.

Submit only when:

expected_target_asset_reward_value >= gas_cost * required_margin

Use 1.2 for private routing and 1.5 for public mempool unless policy says otherwise. Include L1 data fee on L2 networks. Ignore non-target-asset fees for resolver reward estimation. For sell orders target token is token1; for buy orders target token is token0.

Use rerange(orderKey) for a single candidate, manager overloads only with explicit authority, and batchRerange(orderKeys) for permissionless scanning. Do not submit during hub pause, without a fresh preview, inside cooldown, or when gas exceeds expected reward.

Vault Manager

Use this for owner-authorized vault workflows: create vaults, assign time-limited agents, choose balance policy, close orders, and report balances.

Owner actions:

• RerangeHub.createVault()
• RerangeVault.setAgent(agent, accessExpiresAt)
• RerangeHub.close(orderKey) when owner-authorized
• RerangeVault.withdraw(token, to, amount)
• RerangeVault.call(target, value, data) for exact owner-approved calls
• RerangeVault.multicall(targets, values, data) for exact owner-approved batches

A configured vault agent can manage supported orders but must not receive withdrawal authority. Use setAgent(agent, accessExpiresAt) for scoped, session-key-like delegation.

Balance policy:

• keepBalancesInVault = false: close returns attributable balances to owner.
• keepBalancesInVault = true: final balances remain in vault.
• unwrapOut = true: unwrap WETH output to native ETH where supported.

Before closing, read getOrderState, call previewClose, explain expected returned tokens, fees, and reward settlement, submit close(orderKey) only from owner or authorized agent context, then confirm via event and final balances.

Do not ask users to delegate unlimited wallet authority. Do not call arbitrary vault call unless the owner explicitly requested target, value, calldata, purpose, and risk.

Strategy Composer

Use this to turn portfolio or treasury objectives into bounded Rerange orders. Supported modules: productive_limit_order, passive_exit, buy_low_accumulation, dca, grid, rebalance, and treasury_runway.

Do not present leverage, liquidation protection, derivatives, or cross-chain execution as Rerange v1 features.

Planning rules:

1. Check portfolio balances and existing open Rerange orders.
2. Enforce user exposure, concentration, and order-count limits.
3. Split capital only when multiple orders materially improve execution control.
4. Use the intent order builder for each proposed order.
5. Use safety and risk checks for each order and aggregate strategy.
6. Return explicit order parameters and monitoring policy.

For DCA, create one order for the current step and wait for completion, close, or timeout before the next step, unless simultaneous deployment is approved. For grid, place buys below current price and sells above current price, cap per-band capital, cap active orders, and monitor aggregate exposure after every fill.

Do not reinvest proceeds, replace completed bands, or hide the difference between an order target and a guaranteed execution price without explicit user policy.

Safety And Risk

Use this as mandatory preflight for all Rerange actions.

Global checks:

• supported chain,
• correct hub address,
• hubConfig.paused == false for opens and reranges,
• adapter is allowed,
• token addresses and decimals are known,
• pool token order is canonical,
• user amount is nonzero,
• target direction matches user intent,
• preview succeeds,
• simulation succeeds where wallet tooling supports it,
• gas cost is acceptable.

Close is the pause exception: close(orderKey) is an owner or manager recovery path and may be used while paused after preview and authorization checks.

Open checks require successful previewOpen, non-empty activation when the flow expects immediate activation, bounded tick drift since preview, correct target direction, sufficient allowance, Permit2, vault prefunding, or native wrap, sufficient pool liquidity, and enabled slippage and TWAP policy.

Rerange checks require open order, elapsed cooldown, successful previewRerange, close or activation signal, adapter safety, profitable gas for permissionless execution, and fresh submission.

Close checks require owner or authorized agent caller, successful previewClose, and clear explanation of balance destination, fees, and rewards.

Recommended autonomous limits:

{
  "max_single_order_portfolio_pct": 20,
  "max_asset_exposure_pct": 40,
  "max_active_orders_per_pair": 8,
  "min_rerange_interval_sec": 300,
  "max_slippage_bps": 100,
  "max_twap_deviation_ticks": 100,
  "min_profit_to_gas_ratio": 1.2
}

Fee settlement is asset-aware: resolver reward is paid only from target-asset fees; referrer share is paid only from non-target-asset fees; treasury receives remaining non-target-asset fees; target-asset fees are not routed to referrer or treasury; non-target-asset fees are not routed to resolver.

Stop opening new orders and switch to read-only monitoring when hub is paused, RPC responses disagree, pool tick diverges from TWAP, indexed liquidity is stale, gas spikes above policy, token metadata is inconsistent, or preview and simulation disagree.

Never bypass preview, promise exact fill price, execute with unknown token metadata, treat fee APR as guaranteed yield, or use owner withdrawal functions from an autonomous resolver.