-
Notifications
You must be signed in to change notification settings - Fork 0
Solver Integration
This page summarizes the public solver lifecycle. The OpenAPI 3.1 document, integration guide, and machine-readable artifacts remain canonical.
Trust boundary: Never use a Wiki page, an indexer projection, or an unsigned convenience view as execution authority. Verify the Signed Feed, then obtain a valid Execution Permit.
Begin with the canonical solver discovery document. It identifies the published API and solver-facing integration resources. External scanners may use the separate on-chain discovery fingerprint.
The public Discovery Facade exposes the discovery URI on-chain. The repository includes a read-only Facade example, the solver-facing ABI, and deployment evidence.
Fetch the public solver Feed. The authenticated signedPayload is the signature preimage; filtered top-level route collections are convenience views and do not replace it.
Verify the Feed before route selection using the published signer identity and the repository's Feed verification implementation. The exact cross-language signature behavior is pinned by the SDK contract and test vectors.
Use verified Feed terms for selection. The route-detail endpoint returns the exact canonical active Feed route; its path and typed response are defined in the OpenAPI document.
The repository's route-discovery example demonstrates the supported public flow without adding unsupported claims about how routes are produced.
The public flow is:
- request the deterministic Permit signing message;
- sign the exact message in the integrating bot or wallet;
- submit the proof to request the Permit; and
- retain the returned Permit and signature for resolution and execution.
The Permit-request endpoints and schemas are canonical in OpenAPI. See the Permit example and onboarding guide. Private keys remain with the integrating operator and are not part of the public package.
For direct Nexa execution, preview and build the Router transaction from the valid Permit. For the executable ERC-7683 surface, perform resolver-centric off-chain eth_call resolution; the result is one call to the canonical Router execution function. See the ERC-7683 example and standards manifest.
OIF is discovery/description-only and must not be treated as an executable path. See Standards.
The public integration preserves the documented execution invariant: one Bot source transaction plus one Nexa destination transaction, exactly two on-chain transactions.
Fill status is available through the typed public status endpoint documented by OpenAPI. Canonical public event signatures and topics are in events/events.json.
The public SSE Feed endpoint emits the documented feed, publication-closed, and error events. Event IDs are Feed dataVersion values. Clients should use HTTP Feed recovery and follow the Last-Event-ID behavior documented in the root README.
SSE is a delivery mechanism, not a different source of execution authority; each Feed still requires cryptographic verification.