Facilitator-role engine for exact payments on Solana (solana:*).

The SVM counterpart of X402.Facilitator.Engine: it assembles the SDK's local SVM verification (X402.Verify.SVM), Solana JSON-RPC calls (X402.Solana.RPC), transaction primitives (X402.Solana.Transaction), and the signer behaviour (X402.Signer) into the engine behind the facilitator API's three operations, speaking the same wire shapes as the reference facilitators:

• verify/3 — the full exact-SVM static-path checklist, returning the POST /verify response.
• settle/3 — re-verifies independently, co-signs the fee-payer slot with the configured signer, broadcasts via sendTransaction, and polls getSignatureStatuses until the transaction is confirmed, returning the POST /settle response with the Base58 transaction signature.
• supported/1 — the GET /supported response derived from the configured networks.

Expose the engine over HTTP with X402.Plug.Facilitator (alone, or next to an EVM X402.Facilitator.Engine via the :engines option), or call it directly from your own transport.

Fee-payer safety

The facilitator's Ed25519 key co-signs client-built transactions, so what it signs is strictly constrained by verification: the requirements' extra.feePayer must be this engine's signer, account 0 must be that fee payer, the fee payer must not be referenced by any instruction (isolation — the sponsor's signature can never move the sponsor's funds), the instruction layout must match the static whitelist, and every other required signer's Ed25519 signature is verified locally over the message bytes. Smart-wallet (CPI-wrapped) payments and address-lookup-table transactions are rejected fail-closed.

Settlement pipeline

1. Compute the settlement key — SHA-256 of the transaction's message bytes — and atomically claim it in the :settlement_cache (duplicate_settlement when already claimed). The claim is released on verify failure, node-side broadcast rejection, and terminal on-chain failure, and kept on success. On settlement_pending the claim is kept only when the :pending_settlement_store recorded the broadcast (a retry then reconciles against the recorded signature); without a store it is released, so a retry re-verifies and re-broadcasts the identical wire bytes instead of dead-ending on duplicate_settlement.
2. Pending-settlement fast path: when a prior settle for this exact transaction broadcast but could not confirm, re-await the recorded signature instead of re-verifying and re-broadcasting (Solana transactions embed an expiring blockhash, so a resend can fail while the original is still perfectly valid).
3. Re-verify via X402.Verify.SVM at :full level, re-simulating by default exactly as the reference facilitators do (see :simulate_in_settle).
4. Sign the message bytes with the configured signer, splice the signature into the fee payer's slot 0 (X402.Solana.Transaction.attach_signature/3), and broadcast with skipPreflight: true.
5. Poll getSignatureStatuses until confirmed/finalized or :confirm_timeout_ms. A broadcast whose confirmation cannot be established returns the spec's non-terminal "settlement_pending" with the transaction signature and records it in the :pending_settlement_store for the fast path above.

Duplicate-settlement protection

children = [
  {X402.Extensions.PaymentIdentifier.ETSCache,
   name: MyApp.SettlementCache, ttl_ms: 120_000},
  {X402.Facilitator.PendingSettlementStore.ETS,
   name: MyApp.PendingSettlements}
]

settlement_cache:
  {X402.Extensions.PaymentIdentifier.ETSCache, MyApp.SettlementCache},
pending_settlement_store:
  {X402.Facilitator.PendingSettlementStore.ETS, MyApp.PendingSettlements}

Example

{:ok, rpc} = X402.RPC.new(rpc_url: "https://api.devnet.solana.com", finch: MyApp.Finch)
{:ok, signer} = X402.Signer.SolanaKey.new(System.fetch_env!("SOLANA_FEE_PAYER_KEY"))

{:ok, engine} =
  X402.Facilitator.SVMEngine.new(
    rpc: rpc,
    signer: signer,
    networks: ["solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1"]
  )

{:ok, %{"isValid" => true, "payer" => payer}} =
  X402.Facilitator.SVMEngine.verify(engine, payment_payload, requirements)

{:ok, %{"success" => true, "transaction" => signature}} =
  X402.Facilitator.SVMEngine.settle(engine, payment_payload, requirements)

Hooks and telemetry

X402.Hooks callbacks wrap both operations exactly as on X402.Facilitator.Engine, and the same [:x402, :facilitator_engine, :verify] / [:x402, :facilitator_engine, :settle] telemetry events are emitted with :status metadata.