Aggregator and Solver Integration

The registered-issuer market can receive external flow, but it should not ask aggregator teams to understand Steer hook data, M1 credentials, signed quote payloads, broker payload encoding, or shared sequence risk.

The integration product should make the market look like a normal liquidity source:

Aggregator sees:
  quote, output amount, gas estimate, calldata, expiry

Steer operates:
  route sizing, manager risk checks, M1 API calls, signed hook data, sequence locking, and submission policy

M1 Sequence Findings

The registered-issuer path currently executes through RegisteredIssuerBrokerAdapter, which calls the AtomicBroker as the adapter. For mint, that means AtomicBroker.deposit(address(this), address(this), ...); for redeem, the adapter is likewise the permit source and payout recipient. Inside the AtomicBroker, the price attestation consumer and the deposit/redeem permit source collapse to the broker adapter instead of the end trader.

That creates a shared execution lane:

USDM1 price attestation lane:
  feedId = USDM1 feed
  consumer = RegisteredIssuerBrokerAdapter

Deposit/redeem permit lane:
  source = RegisteredIssuerBrokerAdapter

The v2.1 vendor broker emits a USDM1 price-attestation identifier for lineage, but no longer enforces price-attestation sequence ordering on-chain. It still rejects a deposit or redeem permit if its nonce has already been consumed for the same source.

Live probing through the quote server showed that repeated M1-backed quote requests returned fresh USDM1 price identifiers while the deposit permit sequence could remain unchanged:

request 1: usdmPriceQuoteId=0x..., depositPermitSeq=2
request 2: usdmPriceQuoteId=0x..., depositPermitSeq=2

The deposit permit sequence did not advance just from querying in that probe; it remained the next expected on-chain permit sequence for the adapter source. The same public-quote risk applies to redeem permit material:

• Multiple outstanding payloads can share the same permit sequence, and only the first successful execution can consume it.
• Aggregator quote refreshes can create abandoned executable payloads that still participate in the shared ordering risk.

Execution Failure Example

Trader A quote/build:
  usdmPriceQuoteId = 0x...
  depositPermitSeq = 2

Trader B quote/build:
  usdmPriceQuoteId = 0x...
  depositPermitSeq = 2

Trader B submits first:
  AtomicBroker marks deposit permit nonce 2 used for adapter

Trader A submits second:
  deposit permit nonce 2 is already used, so DepositPermitReplay

The failure is not that two traders necessarily receive the same USDM1 price identifier. The failure is that all traders share the adapter's permit execution lane, and a shared permit nonce can only be consumed once.

Integration Principle

Separate quote discovery from executable finalization.

/quote
  preview only
  no M1 attestation
  no M1 deposit/redeem permit
  cacheable enough for aggregator refresh traffic

/build or /finalize
  recompute route
  request M1 USDM1 attestation just-in-time
  request deposit/redeem permit just-in-time
  sign hookData
  return calldata with very short TTL

If Steer runs the transaction as a solver or filler, finalization can be even tighter:

observe order
price from cached preview state
decide to fill
request M1 material
submit transaction immediately

That model keeps M1 sequence allocation out of public quote discovery.

Classic Aggregator Feasibility

Classic aggregators route through liquidity sources and usually separate at least two phases:

route / price discovery
  compare venues and refresh outputs

transaction build
  produce calldata for the selected route

user execution
  user signs or submits the transaction

The exact naming differs by provider, but the integration target is the same: make discovery non-consuming and make transaction build the only place where executable M1 material can be created.

For every classic aggregator, avoid returning executable M1 material from the quote/price/route endpoint. Aggregators refresh, race, and discard quotes by design.

Solver and Filler Feasibility

Solver and filler systems let Steer absorb the execution complexity instead of asking aggregator teams to integrate the SDK.

The basic model is:

intent/order feed
  -> Steer filler watches orders
  -> Steer previews fillability without M1 sequence allocation
  -> Steer requests M1 material only after deciding to fill
  -> Steer submits execution through an executor/settlement contract

LI.FI Intents

LI.FI Intents is the current first solver-style implementation path in this repo. It lets Steer publish bounded quote inventory, watch LI.FI orders, build signed hook material just in time, and submit fills through LifiHookExecutor without asking integrators to understand Uniswap v4 hook data or M1 permit material.

The implemented command surface is:

lifi:register-solver
lifi:readiness
lifi:serve
lifi:run
lifi:open-escrow-order
lifi:submit-trust-components

Use lifi:serve as the primary loop: it can refresh quotes, poll orders, dedupe order ids, derive build requests, generate hook material, submit fills, and plan or submit finalise calls when the live status payload is ready.

LifiHookExecutor is the v1 solver identity and callback boundary. The operator EOA submits transactions, while the executor receives escrowed inputs, calls SignedCollateralSwapRouter, and delivers hook-generated output tokens to LI.FI's output settler.

See Aggregator Market Access Plan and LI.FI Intents Testing for the current runtime details.

UniswapX

UniswapX remains a plausible later solver-style path because a filler can participate without asking every upstream aggregator to route through the hook.

Use the custom executor pattern rather than trying to make users or aggregators carry hook data:

1. Watch open UniswapX orders.
2. Decode input/output token, amount, chain, auction state, and deadline.
3. Price the order against cached Steer market state.
4. If profitable with enough time buffer, request M1 material just-in-time.
5. Submit through the Reactor with callback data for the Steer executor.
6. Executor performs the Steer swap and delivers required output to the Reactor.

This is an operator strategy, not passive listing. Existing fillers will not automatically route through the hook; Steer either runs a filler or convinces major fillers to use a Steer route.

UniswapX RFQ/quoter status is a later step. Quoter requirements include fast response and low fade tolerance. Live M1 issuance in the quote path is too slow for that; quote responses would need to come from preview state while final M1 material is created only during fill.

1inch Fusion

Fusion uses resolver competition around gasless Dutch-auction style orders. A Steer resolver can watch active orders, wait until the auction price is fillable, request M1 material just-in-time, and execute through a resolver contract.

The technical model is viable, but resolver onboarding is more formal than a simple bot:

• resolver identity and contract registration,
• business/compliance process,
• operational reliability expectations,
• gas and inventory management.

Fusion is a good second wave after Steer proves a filler loop and execution reliability.

CoW Protocol

CoW solvers compete in batch auctions. A solver proposes complete settlements and only the winning settlement executes.

The fit is conceptually strong because CoW already expects solvers to hide route complexity from users. The operational burden is high:

• auction deadlines,
• solver registration and bonding,
• simulation and scoring,
• penalties or exclusion for repeated bad behavior,
• need to encode Steer execution as settlement interactions.

M1 finalization must happen late enough to avoid quote spam but early enough to simulate and submit before the auction deadline. This likely requires a dedicated solver stack rather than a thin integration.

Recommended Go-To-Market Order

1. Operate the LI.FI Intents vertical slice. This is the current implementation path: register the solver identity, publish bounded quote routes, poll orders, fill through LifiHookExecutor, and reconcile/finalise from live status.

2. Expose a provider-facing preview/build API. This is the API that 0x, Kyber, ParaSwap, OKX, LI.FI, and 1inch Classic can evaluate.

3. Start 0x custom source / custom v4 hook onboarding. 0x has the clearest passive aggregator-flow path for a hook market.

4. Pursue Kyber and ParaSwap/Velora source integrations. Their route/build and price/transaction shapes match the required preview/finalize split.

5. Prototype a Steer-operated UniswapX filler. This can expand intent flow after the LI.FI path proves just-in-time M1 finalization and executor delivery.

6. Add Fusion and CoW after solver operations are proven. These can produce meaningful flow, but the operational bar is higher.

Required Steer Infrastructure

Before exposing aggregator or solver integrations, build the following:

• Preview pricer: uses cached M1 index/price, AMM state, and manager capacity without allocating M1 sequence.
• Finalizer: requests M1 USDM1 attestation, requests deposit/redeem permit, encodes broker payload, signs hookData.
• Adapter-level lock: serializes finalization/execution for the shared broker adapter lane.
• Order idempotency: one fill attempt per order hash or preview identifier unless explicitly retried.
• Pre-submit simulation: simulate after final hookData generation, not only during preview.
• Private submission path: use private RPC or builder routes when mempool delay increases stale-sequence risk.
• Metrics: M1 latency, attestation identifier, deposit/redeem permit seq, finalize success, fill success, revert reason, stale payload rate, and quote-to-fill elapsed time.
• Circuit breakers: pause finalization on M1 latency spikes, sequence conflicts, or unexpected replay failures.

API Contract

Aggregator-facing APIs should be small and ordinary.

POST /aggregator/quote

{
  "chainId": 11155111,
  "sellToken": "0x...",
  "buyToken": "0x...",
  "sellAmount": "10000000",
  "taker": "0x..."
}

Returns preview-only data:

{
  "previewId": "q_...",
  "buyAmount": "9850000",
  "gas": "210000",
  "expiresAt": 1779300000,
  "source": "SteerRegisteredIssuer",
  "finalizeRequired": true
}

POST /aggregator/build

{
  "previewId": "q_...",
  "taker": "0x...",
  "slippageBps": 50,
  "deadline": 1779300030
}

Returns final executable calldata:

{
  "to": "0x...",
  "data": "0x...",
  "value": "0",
  "expiresAt": 1779300030,
  "m1": {
    "usdmPriceQuoteId": "0x00000000000000000000000000000064",
    "permitSeq": "2",
    "action": "mint"
  }
}

For solver/filler operation, keep this API internal and submit the transaction immediately after finalization.

Provider Documentation References

• 0x liquidity integrations
• 0x Swap API
• UniswapX filler overview
• UniswapX mainnet filling
• UniswapX quoter requirements
• CoW order flow
• CoW driver architecture
• CoW competition rules
• 1inch Fusion introduction
• 1inch resolver onboarding
• KyberSwap Aggregator
• OKX market maker integration
• LI.FI concepts