So the tools moved. @NenzyBrownAssistantBot on Telegram started life as a simple front desk for my work — services, questions, orders through /order. On 31 October it gained /signsafe, and with that it stopped being a front desk and started being where the products actually get used.

A signature check, inside the conversation

The flow takes seconds. Someone sends you a mint link or a "verify your wallet" page, you connect, and a signing request appears. Copy it into the bot with /signsafe and the reply breaks it down — the spender, the amount, the expiry, and whether it follows the drainer pattern of an unlimited approval pointed at an address you've never dealt with.

No tab-switching, no remembering a URL under pressure. The check sits in the same thread as the threat, which sounds like a small thing until you picture the alternative: a person mid-scam, being hurried by a fake support account, deciding whether to open a browser and find a tool they bookmarked last month. They won't. A command they can type right there, they might.

The rest of the shelf, one bot away

The bot carries the other tools as well. ProofReceipt for delivery proof when a file changes hands. ScamOrNot for the suspicious message itself — the parcel text, the prize claim, the too-friendly trading tip. Between the three, most of the ways money leaks out of a chat get at least one chance to be interrupted.

Underneath, it's the same engines as the websites, asked the same questions, giving the same answers. I didn't rebuild anything for Telegram. I just stopped insisting that people come to the tools, and took the tools to the room where the decisions happen.

A small product with a big confession

Everything here is days old and pre-revenue. The bot isn't hiding a growth chart; there isn't one. What it has is a distribution idea I wish I'd started with: safety features only work at the point of risk, and for most people that point is a chat window, not a homepage.

Try the /signsafe command on an approval you'd normally wave through, and compare the bot's reading with your own. Agreement is reassuring. Disagreement is more useful — send it to me either way.

That's the idea in one transaction. WordBond lets a seller back a delivery promise with a real bond held in a vault contract. Keep the promise and the bond stays yours. Break it and the buyer is compensated from the bond. It's running as a public pilot at https://wordbond-pilot.netlify.app — on Base Sepolia testnet, with a mock token, and I'll keep repeating that part because the distinction between test money and real money is where projects like this usually get slippery.

What happens between deposit and payout

The seller funds the bond first. Only then can they register a promise, and the contract does the arithmetic at registration: coverage plus the 2% registration fee has to fit inside the posted bond, or the transaction reverts. There's no honour-system version where a seller promises 500 against a bond of 50 and hopes nobody checks. The check is the contract.

Delivery runs on a buyer code. Goods arrive, the buyer confirms, the promise closes as kept. Silence until the deadline means broken, and broken means the payout path runs. Pulling a bond back out carries a 7-day wait, so a seller can't quietly empty the vault the evening before several deadlines land.

The mistake the pilot caught

Pilots earn their keep by failing cheaply, and this one did. The first version of the public board read the vault through functions I thought I had deployed rather than the ones actually in the contract, and under that reading a broken promise would have displayed as kept. On a trust product, that's the worst bug category there is — the dashboard smiling while the state says otherwise. The fix read the chain through a raw layer matched to the real contract, the board now shows the pilot's three test promises correctly — one open, one kept, one broken — and I wrote up the error instead of quietly patching it.

Not mainnet, on purpose

The vault has no admin withdrawal, no pause switch and no upgrade path, by design. What's missing before real money is unglamorous: an external audit, legal advice, and the gas to deploy properly. Until those exist, the pilot stays on testnet where anyone can inspect every state and every payout for free.

If you buy from small sellers online, the question I'd genuinely like answered is this: would a visible bond change who you buy from — or is it one more badge you'd learn to ignore?

The uncomfortable truth is that the click is the contract. Not the token swap afterwards — the signature itself. Some of those requests are harmless logins. Others quietly approve a third party to spend your tokens, and a few approve all of them, for years, in one tap.

SignSafe, live at https://signsafe-app.netlify.app, translates the request before you sign it. Paste in the payload — a permit, typed data, an approval — and it reads back, in sentences: this address can move this much of this token, until this date. Then it scores the request against the shapes drainers use.

Three things it calls out by name

The unlimited approval dressed as a small one. Raw amounts hide their size. A figure in the quadrillions just looks like a long number in a popup; decoded, it's effectively no limit at all. SignSafe says "unlimited" when that's what the number means.

Approve-everything calls. A setApprovalForAll request doesn't concern one item. It hands over an entire collection in a single signature. The translation puts that in the first line, not the footnotes.

A spender that doesn't belong. Requests often name-drop a protocol. If the address set to receive your approval isn't that protocol's, the mismatch gets flagged instead of buried. Known names like Uniswap's Permit2 and OpenSea's Seaport are matched against what's actually in the payload.

Why it runs where it runs

The analysis happens in the browser tab. Your pasted request isn't uploaded, logged or kept, because a safety tool has no business building a database of what people almost signed. The same engine also sits inside my Telegram bot now, for the times the dodgy link reaches you in a chat — which, let's be honest, is most of the time.

Limits, stated while I'm ahead

It decodes the common request shapes — EIP-712 typed data, permits, Permit2, the standard approval functions. An unusual payload it can't parse gets called unparseable, not safe. It launched on 31 October, it's free for a few checks a day, and it hasn't earned anything yet. Tools like this earn trust by being right in public, slowly.

Next time a popup asks for a signature, take the extra twenty seconds and read the translation first. The button will still be there. Your tokens might not be, afterwards.

ScamOrNot exists for those ten seconds. It's a free checker at https://scamornot-app.netlify.app: paste the message, the link or the wallet address, and get a risk score with each red flag named in ordinary words, plus a suggestion for what to do next.

What's under the paste box

The checker looks for the shapes scams reuse. A fee you must pay before money gets "released". A prize from a draw you never entered. A stranger who turns friendly fast, then starts talking about a trading mentor. Links wearing a real brand's name on the wrong domain. A wallet address attached to a story that doesn't add up.

Some warnings matter far more than others, so the engine weights them. Anything asking for a seed phrase or a verification code sits at the top of the scale — no honest company asks for those, ever. Pressure and secrecy add weight. A single mild oddity gets noted, not screamed about.

Built to stay out of the way

Two design calls I'm still happy with.

First, everything runs in your browser. The text you paste never gets sent to a server or stored. People paste genuinely private messages into a checker like this — bank texts, family chats — and a privacy promise in small print means less than an architecture where uploading isn't possible in the first place.

Second, it had to learn restraint. Genuine bank messages and security advice mention scary words, and early versions scored some of them badly. The tuning work — the unglamorous, repeated testing against real scam scripts and boring real messages — is what got known scams landing high and everyday messages landing at zero.

What I'd tell a family member

This isn't a guarantee and it doesn't pretend to be one. No pattern list catches a brand-new script, and a low score means "nothing obvious showed up", not "safe". If money is about to move, the checker is a pause button, not a permission slip. Phone the bank on the number printed on your card. That advice is boring because it works.

The checker is free for a few checks a day with no account, and it launched two days ago with zero revenue behind it. If a message has ever made you hesitate with your thumb over the send button, that's precisely the message it was built for.

That gap is why I built a second piece for ProofReceipt. The receipt app at https://proofreceipt.netlify.app has been live for a while: hash a file with SHA-256 at delivery, keep the receipt, and the file's identity stops being a matter of opinion. The newer part is a verification endpoint built for software, not people.

One endpoint, one question

The endpoint lives at https://proofreceipt-verify.netlify.app. Software sends it a receipt and an amount. It answers MATCH or MISMATCH and, on a mismatch, points at the check that failed.

Two tamper cases shaped the whole design. Edit a single character in the delivered file — mismatch. Change a single cent in the amount — mismatch. If a receipt system waves either of those through, it's decoration, so those were the tests I kept rerunning while building it.

Why it answers 402 on purpose

The endpoint speaks x402, which means payment is part of the HTTP conversation. No signup, no key management, no subscription tier. An unpaid call receives a 402 Payment Required response carrying the price: half a percent of the invoice amount being verified, rounded up, never below one cent. Verifying a $25 invoice comes to 12.5 cents. A $2 invoice hits the floor.

For a person, 12 cents is nothing. For an automated flow checking hundreds of deliveries, a price that scales with the invoice makes more sense than a flat fee — and a protocol-level payment means an agent can pay it without a human opening a billing page.

The part that's still test mode

Straightforwardly: the endpoint currently runs on Base Sepolia, in test mode, while mainnet payment keys are pending. The 402 challenge it returns is genuine, the verdicts are genuine, and the format matches the live receipt app byte for byte. What isn't live yet is real-money settlement, and I'd rather state that here than let anyone assume it.

Where this fits

Escrow platforms, freelance marketplaces and agent frameworks all run into the same wall — delivery is easy to claim and awkward to prove. A hash receipt plus a callable check doesn't solve trust, but it shrinks the argument from "who's telling the truth" to "does the hash match", and that second argument ends quickly.

ProofReceipt is pre-revenue and the endpoint hasn't taken a mainnet payment. Try the manual side if you deliver files for money; try breaking a receipt if you don't. Both teach you more than this post can.

A "wrong number" chat that turns into a trading mentor with an uncle at an exchange. A prize that only needs a $45 processing fee. A parcel held at customs for a small redelivery charge. A job that pays $300 a day to like videos — withdrawals after you "recharge."

Global scam losses run past $1 trillion a year. The victims are not stupid. The scripts are professional, patient, and engineered around one moment: the moment of doubt, when something feels off but you act anyway because the pressure is louder than the doubt.

So I built a tool for exactly that moment.

ScamOrNot

👉 https://scamornot-app.netlify.app

Paste any suspicious message, link, or wallet address. You get back:

• A risk score out of 100
• Every red flag found, explained in plain English — not "pattern matched," but why it's a fraud signal
• What to do next, specific to the flags found

No sign-up. No account. And by design, the check runs entirely in your browser — what you paste is never uploaded or stored anywhere. A scam checker that collects your private messages would be a strange kind of irony.

One job, done well

I took the narrowest possible scope on purpose: not a security suite, not an AI platform — one job. Tell me if this thing is a scam.

Under the hood it's a pattern engine covering 15 fraud families:

• Seed-phrase and credential theft
• Advance-fee "pay to unlock" structures
• Crypto doubling giveaways
• Pig-butchering scripts (the friendly-stranger-to-trading-platform pipeline)
• Task-job scams, fake parcels, authority impersonation, romance-to-money pivots
• Plus structural link analysis: brand names on domains the brand doesn't own, punycode look-alikes, IP-address hosts, @-trick URLs, abused TLDs

Calibrated, not vibes

Before launch I tested it against the cases that matter — real scam scripts and, just as important, things that must not be flagged:

That last one needed a deliberate guard: safety education mentions the dangerous phrases while warning against them. Context matters, so the engine checks for protective framing before it counts a theft pattern.

Honest limits

ScamOrNot is a pattern checker, not an oracle. It says so on the page: a clean result means no strong patterns detected, never guaranteed safe. Scammers adapt; the last line of defence is still the pause — verify through the official app or the number on your card, never through the message itself.

Why free, and what's paid

The moment of doubt is exactly when help should cost nothing, so checks are free (3 a day). Pro is $9/month for unlimited checks — paid in USDC, because the people who need this most are often screening gig offers and deals in crypto-native spaces. Teams is $29 for communities and family groups that forward each other "opportunities."

It joins my other build, ProofReceipt (SHA-256 delivery receipts for freelancers) — both came out of the same conviction: small, verifiable tools that protect people at the exact moment money is about to move.

Try it on the next "opportunity" that lands in your DMs. And send it to the one person in your family who forwards everything — they're the ones who need it most.

— NenzyBrown, Dubai

What I shipped this week

Telegram bot v3: a free crypto front desk

I shipped v3 of my free Telegram crypto front desk, @NenzyBrownAssistantBot. It gives prices, token safety checks, alerts, and market news. Try it free here: https://t.me/NenzyBrownAssistantBot

The token checker and alerts are the parts I focused on this week: a quick check before you interact with an unfamiliar token, and alerts so you do not have to keep refreshing prices yourself. The channel for updates is @nenzybrownbuilds.

ProofReceipt verification

I also worked on ProofReceipt verification. ProofReceipt is SHA-256 delivery verification for freelancers, live at https://proofreceipt.netlify.app. It is pre-revenue, and I am sharing it as a built product, not as a traction claim.

My other product in progress is PlateWallet, a UAE license-plate payment network launching in 2026. It is pre-revenue and pre-pilot.

What it costs to hire me

I take direct hires. Here is the current list:

• AI agent builds — from $150
• Telegram bot builds — from $150
• MT4/MT5 EA builds — from $250
• Exchange trading-bot builds — from $300
• Web3 research reports — $75
• Campaign / content packs — from $50

How to order

1. Message me on Telegram at @NenzyBrown, on LinkedIn at NenzyBrown, or on GitHub at Nenzy10, with what you want built and your timeline.
2. I will confirm scope and price.
3. Payment is in USDC/USDT on Base/EVM to wallet 0x48E78fFC3f02A65c6A9718b4dc293ae14cBb7985. Work starts on payment or escrow.

If you are not sure yet, try the free bot first. It is the fastest way to see how I build.

Originally published on dev.to: https://dev.to/nenzybrown/building-in-public-what-i-shipped-this-week-telegram-bot-v3-and-proofreceipt-verification-44m9

The starting point

I work as an AI and Web3 builder in Dubai. My "intake process" used to be chaos: enquiries scattered across email, LinkedIn, and three messaging apps, half of them missing the details I needed to quote the work. Meanwhile, I was also answering the same crypto questions in group chats — what's the gas now, is this token a rug, did you see the news — over and over.

One evening it clicked that both problems live in Telegram already. So the design brief became: one long-polling Node.js bot, two halves.

The toolbox (free): live prices (/price), a DexScreener-based token checker with rug-pattern warnings (/token), headlines from CoinDesk and Cointelegraph (/news), gas fees (/gas), a portfolio view, price alerts, a watchlist, a trade journal, a position calculator, and a small plain-language learning section.

The store (paid work): /services lists four offers — AI agent builds from $150, Web3 research reports from $75, launch campaign plans from $50, technical explainers and docs from $40. /order opens an in-chat order flow, and /brief lets a client send their project brief straight to me.

Architecture decisions that mattered

Long polling over webhooks. A webhook needs a public endpoint, TLS, and uptime guarantees. Long polling needs a process that stays alive — one Node process, a watchdog to restart it, and a small state file for its update offset. Far less to babysit. State (watchlists, alerts, journal entries) lives in plain local storage the process owns — no database to provision, nothing to pay for.

The offset file is the whole reliability story. Telegram delivers updates with increasing IDs. Persisting the last processed offset means a restart resumes where the bot left off instead of re-answering yesterday's messages or silently dropping them. It sounds mundane; it was the difference between a demo and a service.

Non-custodial by construction, not by promise. The bot never asks for keys, never connects a wallet, and cannot move funds. Payment for orders works the unglamorous way: the bot shows a wallet address and the order steps; the client pays in USDC or USDT; the claim comes to me; I verify the payment and approve it with a command (/approve), which triggers a one-time invite link to the premium channel for ongoing clients. A human — me — is the payment oracle. That's slower than a payment gateway and, for a one-person practice, much safer than bolting custody onto a chat bot.

Delivery proof as a feature, not an afterthought. Freelance work has a classic dispute: "that's not the file you sent me." I already had a tool for this — ProofReceipt — which fingerprints a delivered file with SHA-256 so both sides hold the same receipt hash. Wiring that into the order flow means a client can verify, byte for byte, that what they received is what was delivered — removing an entire category of argument.

The command surface is a design problem

Telegram's setMyCommands gives you a menu — which means every feature has to earn a slot and a one-line description a stranger understands in two seconds. I published 24 commands and grouped them by intent: check something, track something, learn something, order something. The discipline hurt in a good way. If I couldn't explain a command in five words, the feature wasn't clear enough to ship.

The token checker taught me the sharpest lesson. It pulls live pair data and flags rug patterns — thin liquidity, brand-new pairs, lopsided volume — but the first version's wording sounded like a verdict. I rewrote every warning to describe evidence ("liquidity is under $X", "pair created 2 hours ago") instead of declaring safety or danger. A tool that says "this is a scam" will eventually be wrong in public; a tool that shows its working stays useful even when you disagree with it.

What running it looks like

The bot runs as a single process under a watchdog that restarts it on failure; a daily digest reports what it did. The companion channel, @nenzybrownbuilds, is where I post one useful tool tip at a time rather than announcements — the channel has to be worth following on its own merits or it's just advertising with extra steps.

What I'd tell another builder

1. Ship the boring reliability first — offset persistence and a watchdog before any clever feature.
2. Draw the custody line in code, not in your FAQ. If the bot can't hold funds, whole categories of risk and support pain disappear.
3. Let one surface do intake. The order flow's real value isn't payments; it's that every enquiry arrives with the same structure, in one place, with the brief attached.
4. Write warnings as evidence. Your users keep their judgement; you keep your credibility.

The bot is live as @NenzyBrownAssistantBot if you want to poke at the result — /services shows the store half, /token shows the toolbox half. Builders welcome; steal the architecture, it's mostly common sense and one stubborn little state file.

What @NenzyBrownAssistantBot does (free):

• /price BTC, /market, /gainers — live prices, market cap, BTC dominance, Fear & Greed
• /token — paste any EVM token contract and get live liquidity, FDV and pair data, with the rug-shape warnings spelled out
• /alert BTC above 90000 — price alerts checked every minute, delivered by DM
• /watch, /portfolio — watchlists and a holdings tracker valued live
• /calc — a position-size calculator that starts from risk, not hope
• /gas — Ethereum + Base gas; /convert — instant USD conversion; /news — headlines
• /learn, /safety — short lessons and the scam checklist I wish every beginner read first

The shop inside it: I build tools for traders — MetaTrader EAs, exchange trading bots that run on YOUR keys, Telegram bots, AI agents, plus Web3 research and content. Ordering happens in the chat (/order), payment is USDC/USDT on Base, and every delivery carries a SHA-256 ProofReceipt. Premium (signals & alerts, education only) is $15/month.

The lines I won't cross, because they're the product: the bot never trades, never holds funds, never promises profits.

Try it: https://t.me/NenzyBrownAssistantBot — updates and offers live on the channel: https://t.me/nenzybrownbuilds

Built by Nenzy Brown (Dubai) — founder of ProofReceipt and PlateWallet. Day by day, in public.

The storefront — @NenzyBrownAssistantBot (t.me/NenzyBrownAssistantBot): /services lists AI agent builds from $150, Telegram bot builds from $150, MetaTrader EA builds from $250, trading-bot builds from $300, Web3 research reports $75, content packs from $50. /price BTC gives live spot checks, /signal gives one free educational trading lesson a day, and /subscribe opens Premium signals & alerts at $15/month.

How a sale works, end to end: the buyer pays USDC on Base straight to my wallet — no platform in the middle, no 20% fee, no 14-day clearance. They send the bot their transaction hash, the claim lands in my Telegram, I verify on-chain, tap approve, and the bot issues a one-time invite to the Premium channel. Every delivery carries a SHA-256 ProofReceipt.

The lines I won't cross, printed inside the product itself: signals are education only — not financial advice, no profit promises. The bot never executes trades and never holds anyone's money.

Price list channel: t.me/nenzybrownbuilds

I'm a self-taught founder in Dubai; the work is the pitch. The shop is open.

I'm Nenzy Brown — self-taught founder, based in Dubai. No degree, no accelerator, no investors. For years I've been building in the dark: payment systems, stablecoin products, AI tools. Good work that almost nobody has seen.

That ends today. From now on, everything I build gets published — the wins, the code, the receipts, and the zeros. If I'm a nobody to the public, that's on me for staying invisible. Not anymore.

What I'm building (all verifiable — links below)

PlateWallet — a payment network built into your license plate. ANPR cameras settle parking, fuel, tolls and drive-thru automatically. The charge engine is built: a double-entry ledger in integer fils, idempotent event ingestion, a review queue for low-confidence reads, fee/VAT splits, dispute reversal, settlement batching. Launching in the UAE in 2026. Pre-revenue, pre-pilot — I say that plainly.

ProofReceipt — verifiable delivery receipts for freelancers and AI agents. Hash your deliverable (SHA-256), get a receipt anyone can verify. It's live right now: proofreceipt.netlify.app. When an AI agent does paid work for you, "trust me" is not a delivery standard. A receipt is.

WordBond — promise-staking for sellers. A seller stakes a bond behind a delivery promise; keep it and the bond returns, break it and the buyer is compensated automatically by a smart contract. It's live on Base Sepolia testnet and proven end-to-end with real transactions: bonds posted, a kept promise released, a broken promise paid out — with the protocol fee (2% registration + 10% of forfeits) verified in the contract reads. Mainnet comes after audit — I won't put real user money behind unaudited code, and I'll publish that process too.

The operation — I run an AI-agent delivery operation that takes real, escrow-settled work: research, builds, automation. First engagement settled through escrow with every cited requirement verified as met. Small numbers. Real ones.

The rules of this feed

1. Proof over pitch. Every claim links to something you can check — a live product, a repo, a transaction.
2. Honest labels. Live means live. Testnet means testnet. Pre-revenue means exactly that.
3. Zeros shown as zeros. If a week produces nothing, the post says so and explains what changes next.

Why now

Because building great things in silence is a strategy for staying unknown. The work is real — it deserves witnesses, users, critics, and customers. So: two to three posts a week here, every demo on GitHub (Nenzy10), videos starting this week, and the canonical home for all of it at nenzybrown.netlify.app.

If you build in Web3, payments, or AI agents — follow along, argue with me, steal the ideas and make them better. If you need this kind of work done, you now know where to find the person who ships it in the open.

Day one. Let's go.

— Nenzy Brown, Dubai

It's correct. It's also not an argument against hashes — it's a scoping statement.

Think of the delivery stack in layers:

1. Existence/integrity — were these bytes delivered, by whom, for which job, for how much? (hashes solve this, cheaply and forever)
2. Quality — was the work good? (rubrics, reviewers, evaluators — expensive, human/automated judgement)
3. Settlement — does money move? (escrow, x402 — increasingly solved)

Most disputes I've seen don't start at layer 2. They start at layer 1: "that's not the file I sent / not the version I ordered / I never received it." If layer 1 is unsettled, layer 2 arguments are built on sand.

ProofReceipt (https://proofreceipt.netlify.app) is deliberately only layer 1: a SHA-256 receipt computed in your browser binding seller + client + job + amount + deliverable, verifiable by anyone, free, forever. It layers under escrow and evaluators — including the hash-of-output proof step those escrow designs already describe — instead of pretending to replace them.

Try it with a throwaway file, change one byte, and watch verification fail. That's the whole pitch.

— Nenzy Brown, founder (Dubai). Building in public; revenue is $0 and I'll post the number when it isn't.

Disclosure: I'm NenzyBrown, a Dubai-based AI & Blockchain specialist. ProofReceipt is my product, live today, built with my AI agent. This post is the honest launch log.

For the past two days I've been earning (or trying to earn) USDC as an agent on the open web — Taskmarket bounties, Synmerco escrow jobs, a cryptography verification on 1F916. That last job taught me the lesson this product is built on: I verified a receipt whose cryptography passed perfectly — and whose outer shell still couldn't be re-bound to the work it claimed to prove. The proof and the thing proven weren't tied together.

That gap is everywhere once you look:

• Settlement is solved: x402-style rails move USDC in about a second.
• Identity is solved: ERC-8004 gives agents portable on-chain identity.
• Verification is open: nothing standard proves a deliverable is the deliverable. A 2026 study of ERC-8004 reputation found that after filtering Sybil behavior, 86.8% of rated agents had no valid feedback left at all. The scores exist. The evidence doesn't.

So I built the smallest thing that closes it:

ProofReceipt — https://proofreceipt.netlify.app

Paste a deliverable (or drop a file), add seller / client / job / amount, and it seals everything into a single SHA-256 receipt, computed entirely in your browser. Share the receipt JSON with your client. Anyone can re-run verification: the original deliverable returns MATCH; change one character and it returns NO MATCH. That one-character test is the whole product in miniature — evidence that either binds or visibly doesn't.

Your receipts accumulate into a Proven Work profile: total value delivered, backed by hashes instead of testimonials.

Pricing is deliberately boring: free for 5 receipts, Pro $9/month in USDC for unlimited, Teams $29/month (acceptance flow + API on the waitlist). No token, no points — a receipt tool that charges money for receipts.

From here the ladder is: client acceptance inside the receipt → escrow settlement on verified receipts → an API marketplaces can call per verification. Each step only works because the step before it created receipts people actually use.

Try it, break it, tell me what's missing. First 5 receipts are free.