AI agents increasingly hand model-generated JSON directly to APIs, queues, databases, and other agents. Syntactically valid JSON is not enough: a missing field, an unexpected value, or a payload that violates a workflow rule can still trigger the wrong production action.
I built Schema Gate to put a deterministic acceptance boundary between candidate machine output and the system that consumes it.
What it does
A buyer submits:
- the candidate JSON
- a bounded target schema
- explicit acceptance criteria
- a buyer-generated order ID and idempotency key
- a commitment hash that binds the request to those rules
Schema Gate validates the request before asking for payment. A valid unpaid request returns a standard x402 v2 payment challenge. After settlement, the service returns a machine-readable ACCEPT or REJECT decision with a signed ES256 receipt.
The receipt binds the decision to the order, rules, input, output, price, and settlement. A downstream workflow can require that receipt before it proceeds.
This is not an LLM call and it does not silently rewrite failed output. It deterministically verifies and gates it. Accepted JSON is canonicalized; rejected JSON receives structured failure details.
Why not just run a local schema validator?
Local validation is useful, but it does not create an independently signed decision that another system can enforce.
Schema Gate is for teams that need a portable acceptance artifact across an agent handoff, automation boundary, or production workflow. The receipt can travel with the result and be verified using the published public key.
Billing
The launch price is 0.010 USDC per completed signed evaluation on Solana mainnet through x402 v2.
Both ACCEPT and REJECT are paid outcomes because the delivered product is the signed evaluation. Malformed requests and failures before settlement are free. An exact retry or recovery of the same order does not charge again.
There are no accounts, subscriptions, API keys, or credit-card forms.
Try the integration
The client SDK is public and keeps wallet signing local:
pip install "git+https://github.com/woodhouseog/x402-digital-vending-machine.git"
The repository includes the strict five-field acceptance policy, receipt verification, recovery handling, and examples:
- Live service: https://www.x402digitalvendingmachine.store
- Python SDK: https://github.com/woodhouseog/x402-digital-vending-machine
- OpenAPI: https://www.x402digitalvendingmachine.store/openapi.json
- Public receipt key: https://www.x402digitalvendingmachine.store/.well-known/receipt-key.json
- Health: https://www.x402digitalvendingmachine.store/health
Current status
The service is live in managed cloud infrastructure, and the unpaid challenge, validation, discovery, dashboard, recovery contract, and signed-receipt paths are covered by production and D1-backed acceptance checks.
I am looking for the first independent workflow team to run a funded production evaluation and tell me where the integration is useful or awkward. I am not claiming customer revenue or proven market demand yet.
If you build AI agents, tool-call automation, or machine-to-machine workflows and need to prevent unchecked JSON from crossing a production boundary, I would value a concrete integration review.
Top comments (0)