Standards compatibility¶

The canonical standards manifest is available at /.well-known/nexa-standards.json. The build-generated summary below comes from the same repository artifact.

Canonical standards projection¶

Supported chain IDs: 8453, 56, 999. Router source transaction count: 1.

ERC-7683¶

Nexa exposes an executable compatibility resolver. Given the canonical ABI encoding of an issued Execution Permit and its signature, a solver can call the resolver off-chain to obtain the single Router execution step.

issued permit payload
  -> resolver eth_call
  -> Router target + value + fillDirect calldata
  -> one source transaction

Resolution itself has transactionCount: 0. It does not poll, mutate state, or submit a transaction. The returned call must match the issued permit and canonical Router binding before submission.

The repository includes deterministic successful and failure vectors for resolution, selector identities, ERC-165 interfaces, payload encoding, and expected calldata.

OIF¶

OIF is deliberately DISCOVERY_DESCRIPTION_ONLY. Its module can report the compatibility level and deterministically describe a mandate via an off-chain call. It cannot resolve an executable transaction.

Payload and authority¶

Both modules describe the public standards projection around Nexa's issued permit format. Neither module creates authority. The Execution Permit remains the fill-specific authorization, the Router remains the source execution target, and on-chain Registry/Router state remains authoritative.

Verify compatibility locally¶

npm ci
npm test
npm run sdk:conformance
npm run package:verify

Inspect the canonical material directly:

• Standards manifest
• Standard IDs
• Deterministic vectors
• ERC-7683 example
• OIF example

No standards discovery or resolution step changes the exact one-Bot-source plus one-Nexa-destination execution invariant.