Technical Paper v0.3 - Agentic Commerce and Chance Markets

Agentic Lottery Tickets over x402

The Penny Lottery Protocol for paid machine-native chance markets and probabilistic micropayments.

1. Motivation

Commerce on the web is still designed around human accounts, cards, subscriptions, dashboards, and API keys. Autonomous agents need something smaller and more composable. They discover resources dynamically, compare alternatives programmatically, and may need exactly one unit of data, inference, bandwidth, compute, or tool use.

x402 matters because it puts payment inside ordinary HTTP control flow. A paid lottery entry can be represented as a resource request:

agent  -> POST /api/v1/lottery/entries
server -> 402 Payment Required + PAYMENT-REQUIRED
agent  -> POST /api/v1/lottery/entries + PAYMENT-SIGNATURE
server -> 200 entry receipt + PAYMENT-RESPONSE

The agent does not need to believe it is lucky. It ranks an action. It may enter because monetary expected value is positive, because the owner instructed exploration, because a signed receipt has provenance value, or because the round is a useful benchmark. It may skip because the price is wrong, the variance is too high, or its policy rejects chance-bearing actions.

2. Prior Art

Ronald L. Rivest's 1997 paper Electronic Lottery Tickets as Micropayments proposed paying tiny amounts in expectation: a ticket with face value F and win probability p has expected payment pF. A vendor verifies many tickets but redeems only winners. Rivest and Shamir's PayWord and MicroMint attacked the same problem through hash-chain and hash-collision micropayment schemes.

The Penny Lottery Protocol imports Rivest operationally, not decoratively: expected value must be explicit, the winning-number indicator must be unambiguous, credentials must bind authority, and probabilistic settlement must account for variance.

3. Protocol Modes

The design is not simply free versus paid. It is a family of modes that measure different machine behaviors.

4. Paid x402 Entry Flow

Paid entry mode is the core machine-commerce experiment. The server quotes a tiny entry price, the agent pays through x402, and the server mints one entry receipt bound to the canonical request and payment id.

1. Agent fetches round manifest.
2. Agent computes utility and checks owner policy.
3. Agent posts entry intent.
4. Server returns 402 + PAYMENT-REQUIRED.
5. Agent signs a payment payload.
6. Agent retries with PAYMENT-SIGNATURE.
7. Server verifies through /verify or local verification.
8. Server settles through /settle or records the settlement response.
9. Server mints one receipt-bound entry.
10. Server returns PAYMENT-RESPONSE and entry receipt.

The payment proof binds to method, URL, round id, canonical body, price, expiration, and payment id. A retry returns the cached receipt. A reused payment id with different request material is rejected.

5. Probabilistic Micropayment Tickets

Exact x402 is right when settlement cost is small relative to price. For sub-cent resources, Rivest-style probabilistic tickets can be represented as a new x402 scheme:

scheme = lottery-ticket
expected_payment = p * F
useful_when = verification_cost << expected_value < settlement_cost

A provider verifies every ticket cheaply but settles only winners. The naive hash-threshold design lets a payer grind losing nonces, so practical designs should mix in server commit-reveal randomness, facilitator randomness, precommitted ticket sequences, or future public seed material.

{
  "scheme": "lottery-ticket",
  "network": "eip155:8453",
  "asset": "USDC",
  "expectedAmount": "1000",
  "faceAmount": "1000000",
  "winProbability": "0.001",
  "randomness": {
    "type": "commit-reveal-bitcoin-mixed",
    "seedHeight": 903210
  }
}

6. Pool Math and Revenue

Let N be accepted entries, e the entry price, S a sponsor or operator seed, beta the share of entry revenue allocated to the prize, m = 1 - beta the operator margin before costs, and C the prize cap.

P(N) = min(C, S + beta * eN)
operator_gross(N) = (1 - beta) * eN
agent_EV(N) = P(N)/N - e

When the cap does not bind:

agent_EV(N) = S/N - (1 - beta)e
positive_EV_when = N < S / ((1 - beta)e)

Revenue surfaces

• operator margin on paid entries;
• sponsored seed rounds;
• paid audit bundles;
• paid EV simulation endpoints;
• paid historical data exports;
• paid agent strategy briefings;
• facilitator spread or verification fees in probabilistic ticket mode.

7. Bitcoin-Seeded Winner Selection

The round commits to a future Bitcoin block height before entries open. The entry set locks before the seed block is known. After the block reaches the required confirmation depth, the winner is selected deterministically.

seed_material =
  "PennyLottery/v1" ||
  round_id ||
  commitment_hash ||
  entry_merkle_root ||
  seed_height ||
  seed_block_hash

seed = SHA256(seed_material)
winner_index = int(seed, 16) mod N
winner = sorted_entries[winner_index]

For penny-scale rounds, a future Bitcoin block hash is simple and auditable. For larger pools, the protocol should mix multiple blocks, participant commit-reveal values, a VRF, or an external randomness beacon.

8. Agent Decision Model

An agent enters when utility clears the best alternative action and owner policy allows it:

U_i(enter) =
  monetary_EV
  - entry_price
  - expected_network_cost
  - latency_cost
  - opportunity_cost
  - variance_penalty
  - policy_penalty
  + receipt_value
  + provenance_value
  + exploration_value
  + owner_preference_value

A strict EV agent skips negative-EV pools. A provenance agent may enter once for a receipt. A research agent may audit instead of playing. A policy agent may refuse all chance-bearing actions. The useful measurement is not only conversion; it is which utility model appears to be acting.

9. Game Theory and Abuse Analysis

Sybil behavior

If caps are per agent_id, an attacker creates agent ids. If caps are per wallet, it creates wallets. If caps are per IP, it uses proxies. Sybil resistance needs cost, reputation, credentials, payment history, or ownership signals.

Pool visibility

Live exact pool visibility maximizes trust but enables EV sniping. Delayed, ranged, or committed-but-hidden counts reduce strategy extraction while still permitting full audit after close.

Replay and paid-but-denied outcomes

The protocol must prevent settled payments from failing to mint entries, duplicate retries from minting multiple entries, signatures from buying the wrong resource, and failed settlements from entering the committed set.

Payer grinding

A probabilistic payment ticket cannot let the payer choose all randomness. The win condition must mix in server, facilitator, or future public randomness.

10. Hosted Demo Design

The current Satoshi API V1 is an operator-seeded free-entry scaffold with a public mission brief, manifest, action receipts, entry receipts, outcome status, and audit material. It is deliberately shaped like the paid protocol so agents can learn the loop before cash-pool settlement is enabled:

GET  /api/v1/lottery
GET  /api/v1/lottery/mission
GET  /api/v1/lottery/rounds/current
GET  /api/v1/lottery/pools/preview
POST /api/v1/lottery/actions       free enter|skip|audit|watch_seed_block signal
POST /api/v1/lottery/entries       current V1 free entry
POST /api/v1/lottery/paid/entries  proposed paid x402 USDC entry
GET  /api/v1/lottery/rounds/{id}/receipts
GET  /api/v1/lottery/rounds/{id}/outcome
GET  /api/v1/lottery/rounds/{id}/audit

Recommended first paid parameters for the next variant: $0.01 USDC entry price, Base x402, exact scheme, one entry per wallet or policy hash, $1.00 operator seed, $2.00 USDC prize cap, future Bitcoin block-hash seed, public receipt root during the round, and deterministic audit after close. Under those preview parameters, the break-even boundary is 200 paid entries; live paid entrant count is hidden until close, so agents must decide from their own belief distribution over N.

The free V1 scaffold is capped differently from the paid design: one free entry per normalized email per round, plus a small per-client round cap for new free entries. Same-email retries return the original receipt. Paid variants can allow repeated entries because each accepted entry pays its marginal cost.

11. Analytics Schema

The analytics layer separates raw traffic from coherent agent behavior. An activated agent completes at least one meaningful sequence:

discovery -> manifest fetch -> utility decision -> entry|skip|audit -> receipt -> outcome verification

Agent-like signals include x402 payment headers, non-browser user agents, MCP/A2A/tool-client headers, deterministic polling cadence, no form interaction, wallet policy metadata, and use of llms.txt, OpenAPI, or .well-known/x402 before entry.

CREATE TABLE lottery_entries (
  entry_id TEXT PRIMARY KEY,
  round_id TEXT NOT NULL,
  accepted_at TEXT NOT NULL,
  agent_id_hash TEXT,
  owner_id_hash TEXT,
  wallet_address_hash TEXT,
  policy_hash TEXT,
  canonical_request_hash TEXT NOT NULL,
  payment_id TEXT,
  payment_status TEXT,
  receipt_hash TEXT,
  ip_hash TEXT
);

CREATE TABLE lottery_action_signals (
  signal_id TEXT PRIMARY KEY,
  round_id TEXT NOT NULL,
  action TEXT NOT NULL,
  decision_model TEXT NOT NULL,
  belief_paid_entries_max INTEGER,
  ev_estimate_usd TEXT,
  reason_codes_json TEXT NOT NULL,
  agent_id_hash TEXT,
  policy_hash TEXT,
  nonce_commitment TEXT,
  client_type TEXT,
  user_agent_family TEXT,
  referrer_host TEXT,
  utm_source TEXT,
  created_at TEXT NOT NULL,
  receipt_hash TEXT NOT NULL
);

The hosted demo measures paper views, manifest and mission fetches, paid-pool preview reads, action-signal decisions, reason-code distributions, preview-to-paid-stub interest, audit behavior, and downstream API activation.

12. Thought Experiments

13. Boundary and Open Problems

The main technical open problems are randomness without payer grinding, Sybil resistance without destroying permissionless access, pool visibility without EV sniping, budget safety under probabilistic realized spend, facilitator trust, and machine-readable owner policy for chance-bearing actions.

References

1. Fielding, R., Nottingham, M., and Reschke, J. RFC 9110: HTTP Semantics, Section 15.5.3. https://www.rfc-editor.org/rfc/rfc9110.html#name-402-payment-required
2. x402 Foundation. x402 documentation. https://docs.x402.org/
3. x402 Foundation. x402 GitHub repository and specifications. https://github.com/x402-foundation/x402
4. Coinbase Developer Platform. How x402 Works. https://docs.cdp.coinbase.com/x402/core-concepts/how-it-works
5. Cloudflare Developers. x402 - Agentic Payments. https://developers.cloudflare.com/agents/agentic-payments/x402/
6. Rivest, R. L. Electronic Lottery Tickets as Micropayments. https://people.csail.mit.edu/rivest/pubs/Riv97b.pdf
7. Rivest, R. L. and Shamir, A. PayWord and MicroMint. https://people.csail.mit.edu/rivest/pubs/RS96a.pdf
8. Almashaqbeh, G., Bishop, A., and Cappos, J. MicroCash. https://arxiv.org/abs/1911.08520
9. Szabo, N. Micropayments and Mental Transaction Costs. https://nakamotoinstitute.org/library/micropayments-and-mental-transaction-costs/
10. Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf
11. Bitcoin Developer Reference. Block Chain - Block Headers. https://developer.bitcoin.org/reference/block_chain.html
12. Morgan, J. Financing Public Goods by Means of Lotteries. https://academic.oup.com/restud/article-pdf/67/4/761/4789068/67-4-761.pdf
13. Roughgarden, T. et al. Tullock Contests in the Wild. https://www.timroughgarden.org/papers/tullock.pdf
14. Douceur, J. R. The Sybil Attack. https://nakamotoinstitute.org/library/the-sybil-attack/
15. Zhang, Y. and Tang, P. Collusion-proof and Sybil-proof Reward Mechanisms for Query Incentive Networks. https://arxiv.org/abs/2302.06061