Nexa Mainnet V6 solver documentation¶

Integrate a solver with Nexa's public discovery surface, cryptographically verified route Feed, and permit-gated execution path across Base, BNB Smart Chain, and HyperEVM.

Start the integration Inspect the API

Know which layer is authoritative

The on-chain Registry and Router are authoritative for deployment identity and executable state. The signed Feed is authoritative for live published terms. An issued Execution Permit is authoritative for one fill. This site, search results, and external indexes are non-authoritative projections.

Discover

Start from the stable well-known manifest, confirm Mainnet V6 is active, and follow its canonical endpoints.

Discovery workflow
Verify

Verify the Feed hash, signature, expected signer, validity window, release, and route state before using any terms.

Verification boundary
Authorize

Build and sign the exact canonical permit-request message locally. Never treat route discovery as execution authorization.

Permit workflow
Execute

Submit one source-chain Router call. Nexa performs one destination-chain payout transaction after observing and confirming the source fill.

Exact 1+1 model

Reference entry points¶

Discovery → Signed Feed → Route → Permit → Resolution → Execution

Integration sequence¶

well-known discovery
  -> signed Feed (HTTP recovery or confirmed-set SSE)
  -> local Feed verification
  -> route and quote selection
  -> canonical permit-request signature
  -> issued Execution Permit
  -> optional off-chain preview / ERC-7683 resolution
  -> one Bot source transaction
  -> one Nexa destination transaction

Resolver and preview calls use eth_call. They do not add transactions. A successful fill retains the exact total of two transactions.