I built a chat where every word costs money — on TON, solo, no legal entity

Hi! I am a mobile developer, specializing in Kotlin, and recently embarked on a side project with an audacious idea - a chat where sending a message costs money, while the recipient gets paid. The concept revolved around the phrase "what if attention literally had a price". This story chronicles how this notion transformed into a functioning Telegram Mini App with genuine on-chain transactions, while detailing the hurdles I faced along the way - from app store rules to TON gas dynamics.

The central idea: a market of pricey attention. Free messages are, in both senses of the word, worthless - whether they are spammy "hi" messages from strangers or overwhelming group chats with 10,000 unread messages. Inverting this, every character costs money. A message with embedded money always garners attention, turning the public chat into an auction of wit.

The message that commands the highest price becomes the 'Crown' of the week and remains pinned at the top. Spam is naturally eradicated; spamming at $0.05 per character is a swift path to financial ruin.

Two significant obstacles stood in the way of turning the idea into a product. The first was the challenge posed by app stores. Any payment for digital content on iOS and Android must be handled through in-app purchases, replete with a 30% commission and stringent rules that consider P2P money transfers as a lethal minefield, with crypto adding to the confusion.

The second hurdle was the legal entity requirement. Accepting users' money into one's account, even temporarily, transforms the entity into a money operator. This status necessitates licenses, KYC/AML compliance, and the formation of a legal entity - elements that would have toppled the project at its inception. Thus, the guiding principle was that the platform would never touch user funds. No app balance, deposits, withdrawals, escrow, refunds, or private key management within the server.

The architecture was simple yet robust: transactions were matched with messages via a unique identifier (uuid) embedded in the transaction, while funds were transferred directly from the sender's wallet to the recipient's wallet using TON Connect. My 10% platform fee was a separate output of the same transaction, deposited into my personal wallet.

If the server were ever compromised, the attacker would find no money to steal. The legal bonus was that, as no money operator, no licenses and no legal entity were required, allowing for straightforward personal income tax treatment.

The technical challenge lay in matching a transaction to a specific message, given the on-chain nature of the transaction. To solve this, the client sends the text to the server, which calculates the price, stores the transaction details, and waits for a client-side signed transaction. An indexer on the server then monitors for incoming transfers to the platform wallet, using the uuid as a comment to validate the transaction.

The pricing formula was shared between the client and server, ensuring consistency and preventing divergence between the two.

In terms of technology, the chosen stack was straightforward and relied heavily on TypeScript for consistency and reliability. The server utilized Bun + Fastify + bun:sqlite, while the client employed React + Vite + TON Connect UI. SQLite on a volume and 7-second polling provided the necessary functionality for an MVP with ample room for scaling. The result was a clean, bug-free, non-custodial design that focused on delivering a seamless user experience, devoid of unnecessary complexities.