TxSentinelAgent transaction control
API checkingx402 checking

AGENT INTEGRATION

Preflight first. Purchase proof only when needed.

Use free readiness to avoid obvious failures, then request the formal x402 decision and receipt.

Open technical docs

ENDPOINT 01

Free readiness preflight

LIVE
POST /api/preflight

Returns only READY, REVIEW, or BLOCKED. No formal decision, rule evidence, digest, or receipt hash.

Inspect preflight contract

ENDPOINT 02

Formal x402 policy check

METERED
POST /api/check-paid

Returns ALLOW, HOLD, or DENY with detailed evidence, risk score, stable hashes, and settlement proof.

Inspect payment challenge

LIVE SETTLEMENT LAB

Complete a real x402 policy check

This lab uses a preflight-ready sample, then completes the formal check with the official OKX client SDK, X Layer Testnet, and an EIP-3009 wallet signature. TxSentinel never receives a private key.

  1. 01
    Payment termsLoad the live 402 challenge
  2. 02
    Buyer walletConnect on X Layer Testnet
  3. 03
    AuthorizeConfirm the exact amount
  4. 04
    ReceiptVerify the settlement proof

Seller terms: price and recipient come from the server. The buyer may choose an accepted asset and approve or reject the quote, but cannot rewrite it.

Payment asset
Load the live terms before connecting a buyer wallet.

VERIFIABLE TERMS

Awaiting challenge

PENDING
Network
—
Service token / price
—
Seller recipient
—
Buyer wallet
—
Buyer balance
—
Transaction
—

PAYMENT ROLES

One quote, three separate responsibilities

SELLER CONFIGURES

Service price, receiving address, accepted assets, and protected endpoint. These terms are server-controlled.

BUYER AUTHORIZES

One advertised asset, the exact quote, and the OKX Wallet signature. The buyer can always reject.

AGENT PROPOSES

The separate action destination, amount, policy, and evidence that TxSentinel evaluates before signing.

INTEGRATION RUNBOOK

Four gates in the agent loop

  1. 01
    Construct and preflight

    POST the proposed action, policy, and evidence to /api/preflight before any wallet request.

  2. 02
    Branch on readiness

    READY may request a formal check; REVIEW needs attention; BLOCKED should stop unless a detailed report is required.

  3. 03
    Purchase the formal decision

    Use /api/check-paid. Invalid schemas fail before payment; valid requests receive the x402 quote.

  4. 04
    Act on verifiable evidence

    ALLOW may continue, HOLD needs human review, and DENY stops. Persist or optionally anchor the paid receipt.

MINIMUM REQUEST

Copy a working request

curl -X POST https://txsentinel-okx.vercel.app/api/preflight \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "xlayer",
    "operation": "transfer",
    "to": "0x4a6aae28b27681856ae824af82fea87896ecc3ed",
    "amountUsd": 25,
    "policy": {
      "maxSpendUsd": 100,
      "denyUnlimitedApprovals": true,
      "requireSimulation": true
    },
    "simulation": {
      "status": "succeeded",
      "estimatedFeeUsd": 0.01
    }
  }'

INTEGRATION BOUNDARY

Keep authority where it belongs

YOUR AGENT OWNS

Transaction construction, RPC access, private configuration, and downstream execution.

TXSENTINEL OWNS

Schema validation, deterministic policy logic, reason codes, and stable receipt hashes.

TXSENTINEL NEVER GETS

Private keys, seed phrases, wallet sessions, signing authority, or broadcast permissions.