Hackathon
VendTON
A marketplace and payment gateway for paid APIs on TON: deploy an endpoint, price it per call, and let an autonomous agent discover and pay for it in USDT without an account.
VendTON turns an HTTP status code into a market. x402 defines how a server demands payment for a request; VendTON is everything around it: a gateway that enforces the payment, a directory so the endpoint can be found, and an agent that discovers and pays for one on its own.
- Event
- BSA EPFL Hackathon 2026 · AlphaTON Capital + ENS track
- Payments
- x402 over TON, settled in USDT
- Naming
- ENS, one subdomain per endpoint
- Role
- Team member
- Repository
- VincenzoImp/vendton
The problem
x402 revives HTTP 402 Payment Required as a real mechanism: a server answers 402 with the terms,
the client pays, and retries with proof of payment in a header. It is a clean protocol, and it is
only a protocol: it says nothing about how a caller finds a paid endpoint, how a developer
publishes one, or how any of it gets a stable name.
The repository’s own framing of the gap is the accurate one: everyone had ported x402 to TON, and what was missing was what goes on top.
What I built
Four services around the payment step.
A gateway proxying calls to a priced endpoint. A request without an x-payment header gets a
402 carrying the terms; a request with one has its transaction verified on TON before the call
is forwarded upstream, and the payment settles in USDT.
A directory, so an endpoint can be discovered rather than known in advance: over the gateway API, or on-chain, because each deployed endpoint is assigned an ENS subdomain under a single parent name. The identity lives on Ethereum while the money moves on TON, which is deliberate: a name that resolves anywhere is worth more than one that resolves inside a single ecosystem.
A Telegram bot and mini app, which is where a TON user already is: deploy an endpoint, set its price, watch it earn, without leaving the client they use for everything else.
An agent that reads the directory, decides which endpoints it needs, pays from its own wallet, and chains several calls together without a human approving each one.
Hard parts
Verifying a payment without trusting the caller. The header is a claim. The gateway has to confirm on TON that the transaction exists, is for the right amount, and has not already been spent on an earlier request, before any upstream work happens. Wrong in the permissive direction gives the API away; wrong in the strict direction charges people for calls they never received. The gateway has not received a security audit and is demonstrated on test infrastructure, so it is evidence of the payment flow rather than a safe place to route real API revenue.
Two chains doing two different jobs. Payments on TON, names on ENS. That is two wallets, two notions of ownership and two failure modes to reconcile behind what a user experiences as one action.