A solo developer publishing under the handle Fkylol has released solpay-bot, a Telegram bot whose question-answering function is gated behind a Solana payment rather than an account signup. The author describes the project as a first launch, built with what they characterise as heavy AI assistance while learning TypeScript, and released under an MIT Lite licence with source on GitHub. The claim is the author's own; the supplied evidence is the author's write-up, not an independent audit of the code or the payment flow.
The stated motivation is payment infrastructure rather than novelty. The author writes that they wanted a crypto question-and-answer bot that actually earns, and that Stripe was impractical for their situation, citing micropayments and France as the reason. The design principle they describe is paying with a transaction instead of an account: the user's wallet signature substitutes for registration, and the bot links a Telegram ID to a verified payment so subsequent questions do not require a new proof.
The documented flow is specific. A user messages the bot, which replies with the author's Solana address and a price of 0.1 SOL. The user sends SOL and then pastes a command in the form !verify followed by the transaction signature and their own address. The bot fetches the transaction and checks four conditions the author lists: that it is confirmed, that it carries no error, that it is a SystemProgram transfer of the correct amount, and that it moves funds from the stated sender to the author's wallet.
On a valid match, the bot returns an answer generated by an LLM and links the user's Telegram ID so later questions skip the proof step. Every signature is written to SQLite, and the author states that reuse triggers an instant rejection as an anti-replay measure. That is a meaningful design detail for anyone building paid access on public blockchains, where a transaction signature is a public, replayable artefact unless the application tracks consumption.
The stack the author lists is deliberately low-cost: the ElizaOS runtime, Groq for the language model on its free tier, CoinGecko for prices, Solana Devnet for testing, and PGlite plus SQLite locally. The author frames the whole stack as free. For freelancers evaluating whether to build something similar, the relevant point is not the specific vendors but the shape of the architecture: a hosted runtime, a third-party inference API, a price oracle, and a local database, with the blockchain used only as the payment rail.
Two operational problems are described candidly. The author says Groq sometimes returns empty replies and that a single automatic retry resolved it. Separately, they report a UX trap in which a 60-second anti-spam cooldown fired on new users' second message; the fix was to throttle only paid users. Both are the kind of failure that only appears once real users arrive, and both are reported as the author's own experience rather than measured results.
A platform constraint shaped the project's scope. The author states that X's free API tier could not read anything, returning a 402 on timelines and mentions, which killed a planned feature of replying on X. Telegram, which the author describes as free for both reading and writing, saved the project. This is a concrete, attributable claim about a third-party API tier from a developer who attempted to use it; it is not corroborated by any independent source in the supplied evidence.
The author also flags an unresolved product question rather than a settled answer: whether a bot of this kind should charge per question or by monthly subscription. They explicitly ask for other developers' takes. That open question is worth separating from the shipped mechanics, because the evidence documents the payment verification path but not any data on which pricing model performs better.
There is a commercial layer alongside the free release. The author offers a Pro version with what they describe as the full paywall, a commercial licence and support, priced at 49 US dollars on Gumroad. The free repository is described as MIT Lite, a term the author uses without defining its exact terms in the supplied text, so the precise difference between the free and commercial licences is not established here.
For working developers, the transferable idea is the verification pattern rather than the bot itself. Accepting a payment by checking a confirmed, error-free transfer of a specific amount from a specific sender to a specific recipient, then recording the signature to prevent reuse, is a general approach to gating access on a public chain without running an account system. The author's implementation is one instance of it, written while learning TypeScript, and should be read as such.
The tradeoffs are visible in the author's own account. A wallet-signature paywall removes signup friction and card processing, but it pushes complexity into verification logic and into the user experience of pasting a signature and address by hand. The author's cooldown bug shows how easily anti-abuse measures can misfire on legitimate new users. And the reliance on free tiers for inference and platform access introduces failure modes, such as empty model responses or blocked API reads, that a paid tier might not have.
What remains unknown is substantial. There is no information in the evidence about how many users have paid, how much has been collected, whether the verification logic has been reviewed by anyone else, or how the bot behaves under adversarial input beyond the stated replay check. The tests the author mentions are described as running real transactions, but no results, coverage or failure rates are given. The 0.1 SOL price is stated without any conversion or comparison.
The honest limitation on this report is that it rests on a single community post by the person who built the software. Every technical and commercial detail above is the author's claim, including the API behaviour on X, the Groq retry fix, the cooldown bug and the licence terms. Nothing in the supplied evidence independently verifies the code, the payment flow or the pricing. Readers should treat the repository as the place to check the implementation, and the author's write-up as a description of intent and experience rather than a validated result.
The practical conclusion for this audience is that on-chain micropayment gating is now cheap enough for a solo developer to attempt in a side project, and the hard parts are not the blockchain calls but the surrounding details: replay protection, abuse throttling that does not punish new users, and dependence on third-party free tiers that can change or block access without notice. The author's open pricing question is the right one to ask before building, because the verification mechanism is reusable but the business model is not settled by it.