The label is not the delivery. Tare checks.

Spending policies decide whether an agent may pay. Tare checks what it got. An independent check of x402 data deliveries: it reads what a data seller promised, verifies what actually arrived, and keeps an evidence-backed record of every seller that over-promised.

Open the console How it works
  • Delivery verification for x402
  • Code checks, the model only reads
  • Kite testnet · pieUSD
The problem

Agents pay first. Nobody checks the goods.

With x402 an agent pays a data seller and receives the body in the same response. The seller describes its delivery, "1,240 unique records, no nulls", and the agent moves on. Nothing compares that description to the rows. Budgets and allowlists cannot help: they never look at what came back.

Pay per record? Then someone has to count the records.

Not a spending policy

Before the payment
vs after the delivery.

Spending limits answer "may I pay?" Tare answers "did I get it?" They are two halves of safe agent commerce. A spending cap limits what the agent can pay. Tare checks what that payment bought, whichever wallet signed it. The published run paid with a capped testnet-only key, because Kite Passport only pays sellers in Kite's catalog (see the FAQ).

Spending policy

Decides before paying

Looks at
Amount, merchant, budget, rate
Question
May this agent spend this much here?
Sees the delivery
Never
Catches
Overspending
Tare

Checks after delivery

Looks at
The seller's claims and the rows it sent
Question
Did we get what the seller promised?
Sees the delivery
Every row, counted in code
Catches
Short, duplicated, empty or stale deliveries
How it works

Four steps.
One of them is a model.

01

Pay

Tare pays the seller 0.001 pieUSD over x402 on Kite testnet, inside hard spending caps, and gets the body back with a settlement hash.

x402 · Kite testnet
02

Read the promise

SERV Reasoning reads only the seller's own words, both its 402 advertisement and its delivery note, and turns them into claims: count, unique, fields, no nulls and, if a time window is named, freshness.

SERV Reasoning
03

Verify

Plain code counts the rows, the distinct ids, the fields, the empty values and the age of each timestamp, and checks each claim. The rows never reach the model.

Tare code
04

Record

Every check becomes a receipt with evidence. A seller whose claims fail is held on its seller record, so the agent stops buying from it.

Tare code
Who decides

Three systems.
Strict lanes.

The model reads. The code verifies. The wallet pays. None of them can do another's job.

SERV Reasoning

Reads the promise

  • Extracts typed claims from the seller's words
  • Treats the prose as untrusted data
  • Never sees the rows
  • Never returns a verdict
  • Never pays
Tare code

Verifies and records

  • Counts rows, unique ids, fields, nulls, ages
  • Checks every claim against the rows
  • Keeps each seller's record
  • Never asks the model for a verdict
  • Never invents a hash
x402 on Kite

Pays, within limits

  • Caps: 0.05 per payment, 1 in total
  • Settled on Kite testnet, hash returned
  • Never called for a held seller
  • Signs testnet pieUSD only
The demo

Two sellers.
Three buys.

Seller A promises 1,240 unique records, no nulls. It delivers 1,240 rows with only 860 unique ids and 40 empty timestamps, and its 402 advertisement promised a score field that never arrives. Seller B promises 200 and delivers 200.

1
BuySeller A
Promised1240
Delivered860 unique
Failed checkscountuniqueno_nullsadvertised:fields
ResultDispute · seller held
2
BuySeller A again
Promised-
Delivered-
Paymentnot attempted
ResultStopped · not paid
3
BuySeller B
Promised200
Delivered200
Failed checksnone
ResultVerified · in good standing

Counts above come from the committed seller payloads. Transaction hashes appear only in the console, and only once a payment has returned them.

Guarantees

Built to fail closed.

Evidence on every receipt

Settlement hash, sha256 of the delivered body and sha256 of the prompt used to read the promise, so a check can be repeated.

No claim, no pass

A promise with no count is "unverifiable", not verified. Steering the model into empty claims gets a seller held, not trusted.

Rows never reach the model

SERV sees the prose inside <prose> tags and nothing else. Any tags the seller hides in its prose are stripped.

Held sellers are not paid

A held seller is stopped before any payment is attempted. The console's payment counter does not move.

Never invents a hash

Only a hash returned in PAYMENT-RESPONSE is stored or shown. Missing means "paid, no hash", never a made-up value.

One request, one payment

Buys carry a request id and run one at a time, so a double click replays the receipt instead of paying twice.

Run it

Your machine.
Your limits.

Payments are signed on the operator's machine, so the live console runs locally. This hosted site shows the published run: the same receipts, read-only. 

# clone, install, check
git clone https://github.com/Ritapossible/Tare && cd Tare
npm ci && npm test

# live console on http://127.0.0.1:4020
npm run app
FAQ

Questions,
answered plainly.

Is Tare a spending policy?

No. A spending policy decides before a payment, from the amount, the merchant and the budget. Tare works after the delivery: it checks the rows a seller sent against the seller's own claims. It sits next to a spending policy. A spending cap limits what the agent can pay; Tare verifies what that spend bought.

How are payments made?

Over x402 on Kite testnet, with testnet pieUSD. Tare supports Kite Passport (kpass) as its payment rail, but Passport currently only pays sellers listed in Kite's service catalog. Until Tare's sellers are listed, the published run signs standard x402 payments with a testnet-only key, capped by Tare at 0.05 per payment and 1 in total, and the Pieverse facilitator settles them on Kite testnet. Every hash shown is a real Kite testnet transaction.

Does SERV decide anything?

No. SERV Reasoning (gpt-5.4-mini-serv-multipath) only turns the seller's words into typed claims: four from one prompt, and a time window from a second prompt that runs only when the seller mentions time. Code drops a claim the text does not support. Counting, checking, recording and paying are all plain code. Any extra field the model returns, such as a "verdict", is dropped unread.

Which promise does Tare check?

Both of the seller's own. Before paying, Tare reads the description in the seller's 402 response, the promise made before any money moves. After paying, it reads the note that came with the delivery. Each is checked against the same rows, and both are shown word for word on the receipt. A broken advertised claim shows as advertised:count, advertised:unique and so on.

Why check after paying instead of before?

Because x402 only returns the body after payment. There is nothing to count before paying. What Tare guarantees is that a broken promise is caught, evidenced and acted on, so the agent does not buy from that seller again.

Can a seller talk the model into a pass?

The model has no pass to give. The worst a seller can do is skew the extracted claims, and a promise with no count claim fails closed as "unverifiable". Live injection results from scripts/serv_eval.mjs are published in the write-up.

What is a seller record?

Each seller origin has a record. It starts in good standing. A failed check (dispute) or a promise with nothing to check (unverifiable) puts the seller on hold, with the receipt that caused it. A human can release a hold after review. It does not refund the first payment.

Does real money move?

No. Tare runs on Kite testnet with pieUSD from the faucet. No USDC, no card.

Try it

Promises are cheap.
Rows are countable.

Open the console