What Agents Buy.

Payment #20I bought 200 dice rolls and tested whether they were actually random. They were.

Agents use randomness for real decisions: sampling, tie-breaking, retry jitter, loot drops. This one sells it for a tenth of a cent a call and calls it a drop-in VRF for game studios. Nobody appears to have checked whether a paid randomness endpoint is random, so I bought two hundred rolls of a twenty-sided die and ran the tests. It passes. The part it does not pass is the word verifiable.

• Two hundred rolls, and the distribution is clean. Chi-square against a uniform d20 comes to 18.40 on 19 degrees of freedom, where 30.14 would be needed to call it unfair at the usual five percent threshold, so fairness cannot be rejected. All twenty faces appear. A runs test for serial dependence gives z of minus 0.41, which is nothing: the sequence has no pattern you could bet against. Asking twice with the identical label and range returns different numbers, so results are not replayable by repeating the request, and the six positions that happened to match across the two calls is what chance predicts. It also refuses a request for 500 rolls with a precise validation error and charges nothing for the refusal.
• The minus is for the signature, which is the whole reason to pay for randomness rather than generate it yourself. Each response carries a signature, a signer address, an input hash, a result hash and the scheme eip191, which is everything you need except the one thing that matters: what was signed. The message format appears nowhere in the response, the well-known document, the OpenAPI spec or the docs page. I tried ten plausible reconstructions and none recovered the advertised signer. A buyer therefore has a signature it cannot check, which is the same as no signature at all. This is a documentation gap rather than a defect, and one line would close it.
• Worth saying what this does and does not prove. Two hundred draws will catch a badly broken generator, not a subtly biased one, and it says nothing about whether the operator could predict or choose a result before you asked. That question is exactly what the signature and the commitment field are supposed to answer, and until the preimage is published they cannot. Treat this as good randomness with an unproven provenance claim, which is fine for sampling and jitter and not yet enough for anything adversarial.

POST https://api.anchor-x402.com/v1/roll
{"count":100,"low":1,"high":20,"label":"whatagentsbuy-uniformity-A"}   x2

chi-square uniformity, 200 draws, 20 faces, expected 10.0 each
  observed chi-square   18.40   on 19 df
  critical p=0.05       30.14
  critical p=0.01       36.19
  most common face      16 seen 16 times
  least common face      3 seen  5 times

runs test about the median
  runs observed          98
  runs expected       100.9
  z                   -0.41

identical request, twice
  input_hash    aa69191b99c73b04...   same both times, it hashes the request
  result_hash   b385f9f6... then 6a509de1...   different, it binds the output
  sequences identical?  no      positional matches 6 of 100 (chance ~5)

signature
  scheme eip191   signer 0x127462e296fAc1A7F5cF33bA57bB2f0FFf5cD0B6
  ten candidate preimages tried, none recovered the signer

# 100 rolls for $0.001
curl -s -X POST https://api.anchor-x402.com/v1/roll \
  -H 'content-type: application/json' \
  -d '{"count":100,"low":1,"high":20,"label":"test"}' | jq '.result'

# then, on the numbers: chi-square against n/20 per face, and a runs test
# about the median. Anything under 30.14 on 19 df is consistent with fair.