DEV Community

Cover image for I built a marketplace for digital goods on TON — pay in TON/USDT, no cards, no KYC
dearjohndoe
dearjohndoe

Posted on

I built a marketplace for digital goods on TON — pay in TON/USDT, no cards, no KYC

Buying digital stuff online is weirdly broken if you don't fit the "card + identity" mold. A service wants a passport scan just to top up. A reseller marketplace takes a fat cut and freezes payouts. Card processors reject whole categories — VPNs, game top-ups — as "high-risk." If you already hold crypto, none of that should be necessary: you have the money, you want a product, and the product is just bytes.

So I built ctlx.cc — a marketplace for digital goods and services where everything is paid in TON or USDT, no cards, no KYC, and delivery is automated. It runs as a website and as a Telegram app, so you can buy without leaving the chat.

What you can buy and sell

Anything deliverable digitally: subscriptions, account top-ups, game currency, keys, VPN access, Telegram Stars/Premium, AI tools. It's multi-vendor, so the catalog grows as sellers plug in.

The interesting part

Under the hood it's not a normal web app. There's no central backend that owns the marketplace — it runs off the TON blockchain, and the code is open-source: github.com/dearjohndoe/ton-agents-marketplace.

The core idea is a sidecar. A developer wraps any script into a dead-simple contract — JSON in, result out — and the sidecar handles the rest: registering the product on-chain (a heartbeat tx every 7 days), taking payment over the HTTP 402 protocol, refunds, routing, files. No custom contracts, no middlemen. The frontend (the Telegram Mini App) has no backend of its own — it reads the product list straight from the blockchain and pays via TON Connect.

Client                          Sidecar
  │  POST /invoke {body}           │
  │───────────────────────────────►│
  │  402 {address, amount, nonce}  │
  │◄───────────────────────────────│
  │  TON TX (amount + nonce)       │   (on-chain)
  │───────────────────────────────►│
  │  POST /invoke {tx, nonce, body}│
  │───────────────────────────────►│
  │  200 {result}                  │
  │◄───────────────────────────────│
Enter fullscreen mode Exit fullscreen mode

Because every product is just "schema in → result out," delivery is fully programmable: generate a fresh VPN config per order, hand out a code or file, or run any fulfillment script on purchase — priced in TON and/or USDT per item.

There's also an MCP server, so an LLM (Claude, GPT) can discover, call, and even deploy agents on its own — humans and agents both buy and sell. The whole thing actually started as a hackathon project and ended up winning the Agent Infrastructure track at TON's AI Hackathon.

Where the site fits

The on-chain protocol is the engine; ctlx.cc is the convenience layer on top — search, categories, filters, moderation, a human-friendly UX over an otherwise raw on-chain registry. The protocol keeps running on its own; the site just makes it pleasant to use.

Try it / tell me what's missing

It's built on TON and still early — I'm actively shaping it, so I'd genuinely value feedback from this crowd. If you sell digital goods and have ever fought card processors, chargebacks, or payout freezes, I'd love to hear what would make rails like this actually useful for you. And what would you want from the delivery-scripting side?

Top comments (1)

Collapse
 
bartosz_bilicki_a337185dd profile image
Bartosz Bilicki

The sidecar + HTTP 402 payment flow is a clean separation: protocol does settlement, Mini App is just UX over on-chain state. That is the right default for Telegram-native commerce.

One practical gap we keep hitting after ship is discovery: bots and Mini Apps are easy to build, hard to find without a catalog layer. We maintain tg.app for that browse/search surface, and Apps Father when teams want a no-code shell before custom code.

Curious: are most of your sellers coming from Telegram chats, or from the website first?