FairSeal API

{
  "bet_type": "big",     // big|small|odd|even|total|single|double|triple|anyTriple|combo
  "bet_amount": 1,
  "player_seed": "optional-player-seed"
}

{
  "pool_id": "standard",  // standard|premium
  "amount": 1
}

{
  "amount": 1
}

{
  "status": "resolved",
  "game_id": "64-char hex",
  "result": {
    "outcome": { ... },         // game-specific result
    "won": true|false,
    "payout": "2.00",
    "proof": {
      "vdfEpoch": 442593,
      "rngValue": "hex",
      "clientSeed": "hex",
      "derivation": "HMAC-SHA256(...)",
      "verifyUrl": "https://verify.fairseal.io/{game_id}"
    }
  },
  "replay": [ ... ]            // step-by-step replay for verification
}

// npm install @x402/fetch @x402/evm viem   (Node 20+)
// Wallet needs a little USDC on Base. This call costs $0.01.
import { createWalletClient, createPublicClient, http } from "viem";
import { base } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";
import { x402Client, wrapFetchWithPayment } from "@x402/fetch";
import { ExactEvmScheme } from "@x402/evm/exact/client";
import { toClientEvmSigner } from "@x402/evm";

const account = privateKeyToAccount(process.env.PRIVATE_KEY);
const pub = createPublicClient({ chain: base, transport: http() });
const wal = createWalletClient({ account, chain: base, transport: http() });
const signer = toClientEvmSigner({
  address: account.address,
  signTypedData: wal.signTypedData.bind(wal),
  readContract: pub.readContract.bind(pub),
});
const payFetch = wrapFetchWithPayment(
  fetch,
  new x402Client().register("eip155:8453", new ExactEvmScheme(signer))
);

const res = await payFetch("https://x402.fairseal.io/v1/rng/latest");
console.log("status:", res.status);
console.log(JSON.stringify(await res.json(), null, 2));

# Using @fairseal/verify and @x402/fetch
import { withPayment } from '@x402/fetch';
import { createWalletClient } from 'viem';

const res = await withPayment(fetch, wallet)(
  'https://x402.fairseal.io/v1/rng/latest',
  { method: 'GET' }
);
const receipt = await res.json(); // receipt with VDF proof

npm install @fairseal/verify  # Independent receipt verifier
npm install @fairseal/commit  # Committed selection receipts (drand beacon)

import { verifyVEO } from '@fairseal/verify';

// v0.5.0+: pass trustedKeys - without it, signed objects
// return valid:false (fail-closed, reason: "no_trusted_keys")
const result = await verifyVEO(receipt, { trustedKeys: ['<provider-pubkey-hex>'] });
// result.valid = true means every applicable check passed
// result.anchored = true means on-chain anchor confirmed

npm install @fairseal/game    # Game API for RGS studios (v0.1 ALPHA)
npm install @fairseal/commit  # Committed selection receipts (drand beacon)
npm install @fairseal/verify  # Independent receipt verification

Verifiable Pack Rips & Card Breaks (Tokenized Collectibles)

Digital pack openings backed by physical cards — tokenized, vaulted collectibles where a mystery-pack rip decides which card you receive — are going mainstream. The rip itself is a randomized allocation controlled entirely by the operator: published odds are asserted, not proven.

FairBreak closes that gap for break and pack-rip operators: the full assignment rule (rule_hash) is committed on the record before the entropy that decides the outcome exists, and every participant gets an offline-verifiable receipt proving the result was not steered after the fact. It works for live card breaks, spot assignment, mystery packs, repacks, giveaways, and raffle draws — $0.02 per break via x402, no account, settled in USDC on Base. Receipts verify offline; nobody has to trust FairSeal after issuance.

If you operate a tokenized-collectibles platform and want “provably fair” to mean something checkable rather than a marketing claim: live demo · machine-readable API terms · hello@fairseal.io.

Where FairSeal Sits Among Agentic-Commerce Protocols

Agent payment standards are converging: Coinbase's x402 (HTTP 402 micropayments), Google & Mastercard's AP2 (Agent Payments Protocol), Visa's TAP (Trusted Agent Protocol), and OpenAI & Stripe's ACP (Agentic Commerce Protocol). FairSeal settles payments over x402 only — it does not implement AP2, TAP, or ACP. The mapping below is conceptual, for developers arriving from those ecosystems.

AP2 “mandates” vs FairSeal receipts

An AP2 mandate is a signed, non-repudiable record of user intent that authorizes a future purchase. The nearest FairSeal concept is the notarize receipt (nr_…): a signed, hash-anchored record of a completed agent decision or result. Mandates authorize what may happen; FairSeal receipts prove what did happen.

TAP / verifiable credentials vs FairSeal anchoring

TAP and AP2 verifiable credentials prove agent identity and authorization — who the agent is and that it may act. FairSeal proves result integrity — that a specific decision or outcome was committed before an independently verifiable time (a Base block) and has not been altered since. Identity rails and result notarization are complementary layers, not competitors.

ACP payment tokens vs x402 settlement

ACP's Shared Payment Token is a scoped payment instrument for agent checkout inside the OpenAI/Stripe ecosystem. FairSeal's receipt layer is payment-rail-agnostic; settlement today happens over x402 (USDC on Base), with the on-chain tx hash returned in the X-PAYMENT-RESPONSE header.

Activity receipts vs result notarization

Platform “activity receipts” are operator-trusted logs of what an agent did — you trust whoever wrote the log. FairSeal receipts are result notarization: they verify offline against an external Base anchor, so no party (including FairSeal) has to be trusted after issuance.

In one line: AP2 / TAP / ACP answer “may this agent pay, and is it who it claims to be?” — FairSeal answers “did this result actually happen as claimed, provably before a given time?”

FAQ

Is FairSeal a trust-scoring service?

No. Trust-scoring services (such as t54's x402-secure on Amazon Bedrock AgentCore) evaluate whether an endpoint is safe to pay, using live signals like on-chain history and API health. FairSeal operates one layer below: we issue cryptographic receipts for decisions — including scoring decisions. A score answers "should I pay this endpoint right now?"; a receipt answers "what exactly was decided, from what inputs, and provably before when?" Scorers can notarize their own verdicts to make them auditable; scored endpoints can build anchored track records. The two layers compose.

How is notarize different from execution attestation (TEE/ZK)?

Attestation proves that specific code ran in a specific environment. FairSeal notarize does not prove execution — we say this explicitly. A notarize receipt proves provenance: that a specific decision record (input hash + decision hash) existed before an externally verifiable point in time (a Base block) and hasn't been modified since. That is a different, cheaper guarantee that works for any agent on any stack today, with no enclave or circuit required. When attestation matters, the two combine: attest the execution, notarize the decision.

I already keep audit logs. Why do I need receipts?

An audit log is a file its owner can edit. It proves nothing to an outside party in a dispute. A FairSeal receipt is signed by an independent issuer, batch-anchored on a public chain, and verifiable offline by anyone — including your counterparty or an auditor — without access to your systems and without trusting FairSeal's servers. Keep your logs; notarize the entries that will matter when someone disagrees with you.

How does FairSeal relate to agent-state protocols like Tamga?

They solve adjacent but different problems. Tamga packages an agent's identity, memory, and hash-chained work ledger into an encrypted, portable snapshot, so the agent's state survives host failure and its own receipt chain can be verified locally. Its receipts are first-party: signed within the agent's runtime and co-signed by the executing node.

FairSeal is an independent verification service. Our receipts are issued by a third party with no stake in what the receipt says, and each one is anchored in a Merkle batch on Base mainnet — proving a commitment existed before an externally verifiable point in time, without trusting either the agent or FairSeal (verification is offline via @fairseal/verify). FairSeal also provides verifiable randomness (Wesolowski RSA-2048 VDF / drand), which is out of scope for state-portability protocols.

The two compose rather than compete: a first-party ledger tells you the chain is internally consistent; an external anchor tells you when its head existed. As always: receipts prove provenance, not correctness — that boundary applies to both systems.