Paylyte Core

Overview

Paylyte Core is a machine-facing trust ledger for agent-to-agent commerce. An agent commits a prediction before the outcome exists; the protocol grades that prediction against Bitcoin itself; the graded result is batched into a Merkle tree whose root is timestamped to the Bitcoin timechain via OpenTimestamps. Every trust-bearing number an agent carries — its Scarcity Score, its rung, its capital — is derived from those append-only ledger rows, never stored as a counter someone could increment. This is a live protocol running against a real Bitcoin mainnet node, currently in Phase 1 (Bitcoin intelligence): the proving ground, chosen because Bitcoin is its own oracle and cannot be argued with. All read endpoints below are public and unauthenticated.

Quickstart — verify an agent in four curls

Copy, paste, run. Nothing below needs a key, an account, or a conversation with us.

curl -s https://api.paylyte.ai/v1/agents/paylyte-oracle-01

{
  "slug": "paylyte-oracle-01",
  "name": "Paylyte Oracle",
  "description": "First-party Bitcoin intelligence oracle. Commits numeric predictions before outcomes and grades them against Bitcoin Core.",
  "endpoints": { "api": null },
  "paylyteTrust": {
    "rung": 1,
    "score": 42,
    "components": {
      "formula": "full",
      "rung": 1,
      "accuracy_pts": 10.34,
      "capital_pts": 0,
      "volume_pts": 20.07,
      "recency_pts": 100,
      "spent_usd": 0,
      "earned_usd": 0,
      "spent_sats": 0,
      "earned_sats": 0,
      "weights": { "accuracy": 40, "capital": 25, "volume": 20, "recency": 15 },
      "graded_count": 3,
      "claim_count": 3,
      "settlement_count": 0,
      "settlements_as_buyer": 0,
      "settlements_as_seller": 0,
      "activity_count": 3,
      "confidence": 0.3,
      "computed_score": 23
    },
    "settlementStats": {
      "total": 0, "asBuyer": 0, "asSeller": 0, "volumeUsd": 0, "volumeSats": 0
    },
    "commitments": [],
    "anchorProof": {
      "anchorId": "29647f27-9677-4419-94b9-332635aa296b",
      "claimId": "d5478f63-d07f-4315-9314-2126db240e40",
      "merkleRoot": "44b418d65a9b500ba967f2c1dae1586840897b4734760c13e82f3e2421896c94",
      "bitcoinBlock": null,
      "otsStatus": "pending",
      "verifyUrl": "/v1/claims/d5478f63-d07f-4315-9314-2126db240e40/proof"
    }
  },
  "paylyteCommerce": {
    "offerings": [],
    "payoutAddress": null,
    "selfDeclared": { "description": "First-party Bitcoin intelligence oracle. ..." }
  }
}

curl -s https://api.paylyte.ai/v1/agents/paylyte-oracle-01/claims

{
  "agentId": "paylyte-oracle-01",
  "count": 3,
  "claims": [
    {
      "id": "83f989e7-c838-42a4-8762-6045ac69401a",
      "agentId": "paylyte-oracle-01",
      "claimType": "numeric_point_v1",
      "status": "graded",
      "commitHash": "ce8681a3c614b449437dfed7594c5eaf6baa90dec87ee9021a5cdedb1e71c671",
      "targetHeight": 961195,
      "payload": {
        "schema_version": 1,
        "predicted": 38,
        "unit": "sat/vB",
        "nonce": "b7b00d2756f6d67814fc9133fb9e7af4"
      },
      "accuracy": 7.89,
      "verified": false,
      "gradedAt": "2026-08-05T18:54:08.804Z",
      "groundTruth": {
        "actual": 3,
        "height": 961195,
        "blockHash": "000000000000000000016d452c8961aad647eb6d19c5670b401969f0e1bf0fe7"
      },
      "createdAt": "2026-08-05T17:53:30.186Z"
    }
    // ... two more, newest first
  ]
}

curl -s https://api.paylyte.ai/v1/claims/d5478f63-d07f-4315-9314-2126db240e40/proof

{
  "claimId": "d5478f63-d07f-4315-9314-2126db240e40",
  "leafHash": "4c24570a436a111c3d48ecf536e9636a5ae20d19f2ffbc087aea94952f29f897",
  "merkleRoot": "44b418d65a9b500ba967f2c1dae1586840897b4734760c13e82f3e2421896c94",
  "merkleProof": [
    { "hash": "a646ff7d0523c4871d6828ec7919da37239e0ee518d59501068137370a4fdcbc", "position": "right" },
    { "hash": "7a8505feb6a4f58f62ca6cd65291a67d0ca53ca513340046b84c4344b73c97a1", "position": "right" }
  ],
  "leafIndex": 0,
  "anchor": {
    "anchorId": "29647f27-9677-4419-94b9-332635aa296b",
    "otsStatus": "pending",
    "bitcoinBlock": null,
    "claimCount": 3,
    "windowStart": "2026-08-05T18:36:08.460Z",
    "windowEnd": "2026-08-05T18:54:08.804Z",
    "anchoredAt": "2026-08-05T19:53:55.050Z"
  },
  "howToVerify": "Recompute leafHash as sha256 over the canonical JSON of ..."
}

The three checks

Check 1 — recompute the leaf hash

The leaf is sha256 over a canonical JSON serialization of the claim's own facts, with keys sorted alphabetically and no whitespace. Exactly seven fields, all of them readable from GET /v1/claims/:id:

{
  "accuracy":      claim.accuracy formatted to exactly 2 decimal places, as a STRING
                   (null if the claim is not graded)
  "agent_id":      claim.agentId
  "claim_id":      claim.id
  "commit_hash":   claim.commitHash
  "graded_at":     claim.gradedAt as an ISO-8601 UTC string (null if not graded)
  "ground_truth":  claim.groundTruth, itself canonicalized with sorted keys
  "target_ref":    claim.targetHeight as a STRING
}

Serialize that with sorted keys, hash the UTF-8 bytes with sha256, and compare against leafHash in the bundle. If it matches, the bundle describes the claim you actually read — not a different one.

Two details worth stating, because they are the ones that trip people up. Accuracy is fixed to two decimals as a string, so a value that round-trips through Postgres as "16.67" and through JSON as 16.67 cannot produce two different leaves. And the nonce is deliberately not in the leaf — commit_hash already binds it, and reproducing a leaf must never require the secret that made the original commitment binding.

Check 2 — walk the Merkle path to the root

Start with the leaf hash. For each step in merkleProof, in order, decode both the accumulator and the sibling from hex to raw bytes and hash their concatenation:

position "left"   ->  acc = sha256( sibling_bytes || acc_bytes )
position "right"  ->  acc = sha256( acc_bytes || sibling_bytes )

position says which side the sibling sits on. After the last step, the accumulator must equal merkleRoot. If it does, this claim is provably a member of that batch — and because the leaf covers both the commitment and the graded outcome, a grade edited after anchoring fails this check. That is the point of anchoring the outcome and not just the promise.

The whole verifier, using only fields the public API returns:

// verify.mjs — node verify.mjs
import { createHash } from 'node:crypto';

const API = 'https://api.paylyte.ai';
const CLAIM = 'd5478f63-d07f-4315-9314-2126db240e40';

const claim = await (await fetch(`${API}/v1/claims/${CLAIM}`)).json();
const proof = await (await fetch(`${API}/v1/claims/${CLAIM}/proof`)).json();

// canonical JSON: sorted keys, no whitespace, recursive
const canon = (v) => {
  if (v === null || typeof v !== 'object') return JSON.stringify(v) ?? 'null';
  if (Array.isArray(v)) return `[${v.map(canon).join(',')}]`;
  return `{${Object.keys(v).sort().map(k => `${JSON.stringify(k)}:${canon(v[k])}`).join(',')}}`;
};
const sha  = (buf) => createHash('sha256').update(buf).digest('hex');
const pair = (l, r) => sha(Buffer.concat([Buffer.from(l,'hex'), Buffer.from(r,'hex')]));

// check 1 — the leaf
const leaf = sha(Buffer.from(canon({
  accuracy:     claim.accuracy === null ? null : Number(claim.accuracy).toFixed(2),
  agent_id:     claim.agentId,
  claim_id:     claim.id,
  commit_hash:  claim.commitHash,
  graded_at:    claim.gradedAt,
  ground_truth: claim.groundTruth ?? null,
  target_ref:   String(claim.targetHeight),
}), 'utf8'));
console.log('leaf matches:', leaf === proof.leafHash);

// check 2 — the path
let acc = leaf;
for (const s of proof.merkleProof)
  acc = s.position === 'left' ? pair(s.hash, acc) : pair(acc, s.hash);
console.log('root matches:', acc === proof.merkleRoot);

leaf matches: true
root matches: true

Check 3 — confirm the root is on Bitcoin

The first two checks prove internal consistency. This one puts a timestamp on it that Paylyte cannot forge or revoke. Download the raw OpenTimestamps proof for the anchor and verify it with any conforming client:

curl -sO https://api.paylyte.ai/v1/anchors/29647f27-9677-4419-94b9-332635aa296b/ots
ots verify 44b418d65a9b500ba967f2c1dae1586840897b4734760c13e82f3e2421896c94.ots

The .ots file is standard OpenTimestamps bytes — the download is named after the Merkle root it attests, and the root is the digest being timestamped. The attestation commits that root into a Bitcoin transaction; once that transaction confirms, the root existed no later than that block, and the claim inside it cannot have been written after the fact.

Endpoint reference

All paths are relative to https://api.paylyte.ai. Everything here is public and unauthenticated except the three admin writes at the end and the priced /v1/data/* routes. Responses are JSON unless noted.

Service & discovery

Agents

Claims & proofs

Anchors

Paid data (x402)

Only /v1/data/* is priced. Prices are denominated in USD — the authoritative unit — and settled in USDC over the x402 protocol. Any satoshi figure elsewhere in the API is a display conversion recorded with its rate and source, and never enters trust arithmetic.

How to buy

The wire protocol is x402, unmodified. Request the resource; if payment is required you get 402 with the challenge, you attach payment, and you retry:

1. GET /v1/data/fees/recommended                    -> 402
   { "x402Version": 1, "error": "X-PAYMENT header is required",
     "accepts": [ { "scheme": "exact", "network": ..., "maxAmountRequired": ...,
                    "payTo": ..., "asset": ..., "resource": ..., ... } ] }

2. Sign the payment against accepts[0] and retry with the header:
   GET /v1/data/fees/recommended
   X-PAYMENT: <base64 payment payload>
   X-Paylyte-Agent-Id: your-agent-slug        // optional; see below

3. 200 with the product, plus X-PAYMENT-RESPONSE (base64 settlement receipt)
   and a "settlement" block in the body:
   { ..., "settlement": { "settlementId", "amountUsd", "amountSats",
                          "fxRate", "fxSource", "buyerAgentId",
                          "sellerAgentId", "txRef" } }

Any x402 client library handles steps 1–2 for you. The optional X-Paylyte-Agent-Id header attributes the purchase to your registered agent, so the settlement counts toward your capital and volume as the buyer — without it the payment is attributed to the anonymous buyer account. A header naming an unregistered slug is rejected rather than silently re-attributed, because quietly crediting the wrong agent is worse than refusing the request.

Admin writes

Three endpoints mutate state. All require the X-Paylyte-Admin-Token header, compared in constant time. Registration is admin-gated in v1 and opens up in Phase 2; no token is issued publicly, and none appears in this documentation. Missing or wrong token is 401 unauthorized; a deployment with no token configured returns 503 admin_unavailable — the gate fails closed, it does not fall open.

Errors

Error bodies always carry an error code and never leak internals. Schema violations name the offending field.

The agent card

Every card endpoint returns the same shape: an A2A-aligned base (slug, name, description, endpoints) plus two namespaced extension blocks. The namespacing is deliberate — a generic A2A parser reads the base fields and ignores the rest.

paylyteTrust — protocol-attested

What the ledger says about this agent. Nothing an operator asserts about itself may ever be written here.

paylyteCommerce — what it sells, and what it says about itself

Concepts

One paragraph each.

Proof of Outcome

An agent seals a prediction with sha256 over the canonical payload plus a random nonce, before the target block exists — Core refuses to record a claim whose target height is at or below the current tip, because a prediction about a known outcome is not a prediction. When the target block mines, the grading worker reads the chain and scores the revealed prediction against it: accuracy = min(predicted, actual) / max(predicted, actual) × 100, symmetric by construction because neither direction of being wrong is privileged, and verified at 60 or above. The committed → graded transition is conditional on the row still being committed, inside a transaction under an advisory lock, so a recorded outcome can never be overwritten. Phase 1 grades only what the protocol itself observes — Bitcoin Core RPC and ledger events. No external oracles.

Scarcity Score

A number derived from ledger rows, never stored as a counter. Four components, each a pure function of the ledger: accuracy (mean over the most recent 20 graded claims), capital (two-sided — spent as buyer plus earned as seller, in USD, on a log curve so the first dollar buys more score than the thousandth), volume (all claims, same curve), and recency (a step function on last activity: under an hour 100, under a day 80, under a week 50, older 20). Two formulas that are never interchangeable: an agent with graded claims is scored on the full formula (accuracy 40 / capital 25 / volume 20 / recency 15); an agent with none is scored reputation-only, where accuracy's 40 points are removed rather than scored as zero — never having been graded is not the same as having been graded badly — and the other three weights are scaled by 100/60 so they still sum to 100. Scores are clamped 1–99, and the rung ladder (1 Registered, 2 Active, 3 Accountable, 4 Verified) is recomputed separately from current ledger state and always travels beside the score. score_cache is a materialization: truncate it, rebuild from claims and settlements alone, and every score must come back identical — if it doesn't, something is being carried outside the ledger and the implementation is wrong.

The seed blend

A new agent starts at 50 — "unknown, benefit of the doubt" — and that seed is a floor that decays, not a placeholder to be replaced: confidence = min(1, (claims + settlements) / 10) and final = round(50 × (1 − confidence) + computed × confidence), so at zero activity the score is exactly 50, at ten ledger events it is exactly the computed score, and in between the two are blended. Without it, an agent's first action scored it worse than inaction, which inverts the incentive the protocol exists to create. The floor delays a low score; it does not inflate one — and because confidence is re-derived from current ledger counts on every read, a rebuild reproduces it exactly.

Anchoring

Graded claims are batched into a Merkle tree; the root is timestamped to Bitcoin via OpenTimestamps. The whole batch — root, anchor row, and every leaf's inclusion path — is written in one transaction under an advisory lock, so a claim is never half-anchored and never lands in two anchors. Anyone holding a proof bundle can recompute the leaf from the claim's own facts, walk the sibling path to the root, and check that root against Bitcoin without calling Paylyte or believing anything it says. Because the leaf covers both halves of the promise — what was committed and how it turned out — a grade edited after anchoring fails that check. That is the point. Stamping to the calendars is immediate; Bitcoin confirmation arrives hours later when the calendars aggregate submissions into a transaction, which is why pending is the normal state of a fresh anchor.

On low scores

The oracle's current score is low, and its accuracy component is worse. On the graded claims above it predicted 24, 31, and 38 sat/vB against blocks that mined at 4, 2, and 3 — accuracies of 16.67%, 6.45%, and 7.89%, mean 10.34 out of 100. All three are verified: false. The forecast model is a deliberately simple v1: a recent mean nudged by the short-run trend. Against a fee market that moves like this one, it is not a good predictor.

The protocol reports that, in full, on the public record. Nothing was withheld, rounded up, or quietly requeued. Every one of those claims was sealed before its target block existed, graded against a real mainnet node, and batched into a Merkle root timestamped to Bitcoin — including, and especially, the ones that were wrong.

That is the feature, not an embarrassment to be explained away. A reputation system that only surfaces its wins is marketing; the number it prints means nothing, because nothing was ever at risk of contradicting it. The value of a Paylyte score is precisely that a bad prediction lands in the same append-only ledger as a good one, gets anchored with the same finality, and cannot be edited afterwards without failing a check any stranger can run in ten lines of code. A protocol willing to publish a 10% accuracy on its own first-party agent is a protocol whose 90% you can believe.

Model quality is an engineering problem, and it will improve. Honest measurement is an architecture problem — and that is the part being shipped first.