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
}

# 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';

const result = await verifyVEO(receipt);
// result.verified = true means math checks pass
// 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

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.