DEV Community: TxDesk

A real transaction breakdown: what you see vs what is actually happening

TxDesk — Fri, 26 Jun 2026 15:45:40 +0000

Here is a transaction most people would approve without blinking. Here is what it actually does.

You are doing something normal. Connecting to a new app, trying to swap a token or deposit it somewhere. Your wallet pops up a confirmation. It says something like "Allow this app to spend your USDC," with an Approve button, a contract address you have never seen, and, if you expand the details, a wall of hexadecimal. Most people approve it. It is standing between them and the thing they actually came to do, and it looks routine.

Let me decode what that prompt usually is, using the most common version of it, an ERC-20 token approval.

Under the hood it is a single function call: approve(address spender, uint256 amount). The first four bytes that identify it, the function selector, are 0x095ea7b3, and they are the same on every ERC-20 token. spender is the contract you are granting permission to. amount is how much of your token it is allowed to move on your behalf.

The detail that matters is the amount. A lot of apps request the maximum possible value, a 78-digit number that is effectively infinite (it is two to the power of 256, minus one). Approving that does not move any tokens right now. It grants the spender permission to move up to that amount of that token, at any time, until you revoke it. You are not spending. You are handing over a standing key to one of your balances. If that spender is honest, fine. If it is malicious, or it gets compromised later, the approval you forgot about is the door it walks through.

So the real question the prompt is hiding is not "do you approve." It is "do you trust this specific contract with effectively unlimited access to this token, indefinitely." That is the question TxDesk answers, by reading. It pulls the actual approval and reports the facts that decide it: whether the allowance is effectively unlimited, the spender is this contract, the contract is or is not verified on the explorer, how many days old it is, and whether it is a proxy. An effectively unlimited approval to a contract that is verified and well-aged is a different risk than the same approval to one that is unverified and was deployed this week. It re-checks the current on-chain allowance too, so it will not warn you about an approval you already revoked, and it will not call you safe just because it failed to look.

Here is the reveal. Every single thing in that explanation, the function, the spender, the amount, the verification status, the age, was on-chain and public the entire time. None of it was hidden. It was just unreadable, sitting behind a hex blob and a generic Approve button. The gap is not secrecy. It is legibility. The information was always there. It was simply never in a form a normal person could act on in the three seconds before they confirm.

The safe version of this is boring, which is the point. Approve only the amount you are actually about to spend, instead of infinity. Or approve, do the thing, and revoke afterward, which is just another approval that sets the amount back to zero. TxDesk can build that revoke for you as an unsigned transaction you sign yourself in your own wallet. It never moves the token. It just hands you the un-grant.

For contrast, ask a generic assistant "is it safe to approve this contract" and it will give you a reasonable-sounding explanation of approvals in general. That is a definition, not an answer about your contract. Reading the actual approval is the answer. One describes how the world tends to work. The other is a fact about your wallet.

The scary part of crypto is rarely that the truth is hidden. It is that the truth is unreadable. Turning public-but-illegible into plain-language-and-actionable is the whole job.

The support loop is fine, right up until crypto goes mainstream.

TxDesk — Wed, 24 Jun 2026 13:46:38 +0000

The official help channel and the scam are the same Discord. Crypto-natives have stopped noticing. Newcomers never will.

Here is the pattern, stated flatly. A crypto app has a problem, or you do. It does not offer a help desk. It offers a Discord or a Telegram. You join. The pinned message is a warning about the room you just walked into: beware impersonators, staff will never message you first, do not trust anyone who reaches out, verify every link twice. Within minutes, someone messages you, warm and helpful, claiming to be support. They were in the channel the whole time. That is the design working as intended, not a bug in it. The official place to get help is also the single most efficient place on earth to find a confused person who has funds.

If you have been in crypto a while, you do not see this anymore. You have internalized the rules. You never trust a direct message. You assume every support agent who reaches out is a thief until proven otherwise. You verify every URL twice. This is a genuine skill, it works, and it is invisible to the person who has it. They forget they were not born knowing it. They learned it, usually by getting burned once, and now it runs in the background like a reflex.

The next wave of people coming on-chain did not come for this, and they do not have the reflex. They are not speculators hunting the next thing. They are people whose savings landed here, and whose retirement and ordinary investments are starting to follow. Many have never opened a Discord in their life. Picture telling someone whose pension is partly on-chain that when something looks wrong, the move is to go to a Telegram full of people impersonating staff, and just be careful. That is not support.

Here is the deeper point. Support that only works if the user is already an expert at not getting scammed is not support for newcomers. It is a filter. It quietly sorts people into two groups, the ones who already know the rules and the ones who do not. For a mainstream wave, the filter is the entire experience. It is a big part of why a lot of careful, sensible people take one look at this world and decide it is not for them. They are not wrong to.

The alternative is not complicated. A place to ask the obvious questions, "what is this," "am I safe," "did I just get scammed," that is not itself a place where you get scammed. No strangers sliding into your messages. No impersonators. Plain language. And it should answer by reading the chain, because most of these questions have factual answers sitting in public data: what a transaction did, whether an approval is dangerous, what a contract actually is. That is the thing I am building, and I will leave it at one sentence, because the point of this piece is the loop, not the pitch.

The loop is the part everyone already in crypto has quietly agreed to stop noticing. Newcomers will not extend that courtesy. They should not have to.

Your AI assistant shouldn't guess. In crypto, a confident wrong answer costs you your wallet.

TxDesk — Sun, 21 Jun 2026 14:26:15 +0000

Ask most AI assistants about your transaction and they will autocomplete an answer. The chain is right there. Read it.

A general-purpose model answers from training data. It learned a snapshot of text and it responds by predicting a plausible continuation. Ask it about a specific transaction hash or a specific contract address and it will produce something fluent and confident. It has no live view of the chain. It is autocompleting an answer that looks right.

In most domains, a confident wrong answer is an awkward correction. In crypto it is a drained wallet. That asymmetry is the entire reason I built TxDesk the way I did. When the cost of a wrong answer is your money, the model cannot be the source of truth. The chain has to be.
So here is what "reading the chain" actually means inside TxDesk, concretely.

When you ask about a transaction, it fetches that transaction from the chain's own RPC and block-explorer data, resolves the contract's interface, and decodes the real thing: the function that was called, the parameters it was called with, the events it emitted such as transfers and approvals. On EVM chains, if the transaction failed, it re-simulates the call to recover the actual revert reason when that revert still reproduces against current state. It is not describing how transactions like yours usually go. It is reading yours.

When you ask about an approval, it does not recite how token approvals work in general. It reads your wallet's current on-chain allowance for that token and that spender, right now, and re-checks it so it will not report an approval you already revoked. If the allowance is large enough to be effectively infinite, it says so, because an unlimited approval means the spender can move that token until you revoke it.

When you ask about a contract, it pulls structured signals: whether the contract is verified on the explorer, how old it is, whether it is a proxy. The model's job is to explain that data in plain language, not to remember facts about the world.

The part I care most about is the honest boundary. A tool like this earns trust by being explicit about the edge of what it actually pulled. "Here is what I can see on-chain, and here is what I cannot verify" beats a smooth answer that hides the seam. That shows up in two concrete ways.

First, it does not treat the chain's free text as proof of anything. A token's symbol, a contract's name, a transfer memo, a spender's label: every one of those is a string chosen by whoever deployed the contract or crafted the transaction. An attacker can name their contract "Safe Router" or issue a token whose symbol reads "verified airdrop." So none of those fields are ever used as safety or verification evidence. A name that claims to be trusted is treated as an unverified assertion by an untrusted party, because that is precisely what it is. Safety calls are based only on structured signals: the explorer's verification flag, on-chain age, computed risk factors. A label cannot talk the tool out of a warning, and an attacker cannot lower their own risk score by relabeling their spender.

Second, when it cannot read the data, it says so, instead of filling the gap. If the underlying read fails, it tells you it cannot check right now. It does not return an empty result that quietly implies you are clean. On one chain where approval data can come from two different sources, if both are unreachable the answer is an explicit "unknown," never a falsely reassuring "no approvals found." A blank is not a clean bill of health, and the tool refuses to let it read like one.

There are two ways to be wrong in this category of product. One is an assistant that does support but cannot read a chain, so it is friendly and uninformed. The other is a generic agent that reads nothing and guesses, so it is confident and uninformed. I built TxDesk to do the opposite of both: read first, then talk. It is read-only with respect to your funds, it never holds a key, and it works across more than forty chains. But the read-first part is the whole point.

In a domain where a confident wrong answer costs you your wallet, the model should not be the thing you trust. The chain should. The model's job is to read it to you, and to be honest about the edges of what it could see.

A protocol and its users are not having the same emergency

TxDesk — Fri, 19 Jun 2026 14:12:03 +0000

Sit in the protocol's seat during an incident. The job is clear and brutal: pause the contracts, trace where the funds went, pull in security firms, coordinate a response, get a statement out. Every one of those actions is about the protocol surviving. That is the right list. If you run a protocol mid-exploit, that is exactly what you should be doing.

Now sit in a user's seat at the same moment. The questions are completely different. Did this touch my wallet. Did I approve that contract at some point. Is my money still there. What do I do in the next ten minutes. None of those questions are answered by pausing a contract or tracing a treasury.

These two seats run on different clocks. The protocol's response plays out over hours and days, and that is appropriate for the protocol. The user's panic runs in minutes. What the user gets in those minutes is a pinned post and a link to a chat room. The clocks never line up, so the fast emergency ends up waiting on the slow one.

This is not the protocol being negligent. A protocol cannot field thousands of individualized "am I exposed" questions during an active incident, and answering them is not what saves the protocol. So it does not happen. The gap is built into the situation. Pointing at it is not blaming anyone. It is noticing that the person with the most at stake, the individual user, is the one person nobody is positioned to answer in real time.

Here is the part that bothered me enough to build around it. The information that would actually answer the user already exists. It is on-chain, public, and sitting there the whole time. Whether your wallet holds a live approval to a given contract is a fact you can read. What a specific transaction of yours actually did is a fact you can read. What has moved in your wallet is a fact you can read. The data is not missing. It is just not packaged for a frightened non-expert in the moment they need it.

That gap is what I build TxDesk for. It reads the chain and answers in plain language. It can pull a wallet's active token approvals and flag the dangerous ones: the unlimited allowances, and the ones granted to contracts that are unverified or only days old. It can take a single transaction and tell you what it did, in words. It can look at a contract and report what is actually knowable about it: whether it is verified, how old it is, whether it is a proxy. It is read-only. It does not hold your keys and it cannot move your money. It reads, and it explains.

I want to be precise about what that is and is not. It is not a button that says "you were in this hack, here is your refund." It is the ability to ask the chain the specific questions you actually have, the moment you have them, instead of waiting in a queue that was never built to answer you one at a time. "Do I have an approval to this contract." "What did my transaction with it actually do." Those are answerable right now, from public data, and almost nobody packages them for the person asking.

The two emergencies will keep being two emergencies. The protocol's clock is not going to speed up to match yours, and it should not have to. The fix is to give the user their own way to ask, grounded in the same on-chain reality everyone else is reading. That is the problem I work on now.

I built TxDesk for the wrong customer. Here is what that taught me.

TxDesk — Wed, 17 Jun 2026 15:21:22 +0000

A crypto project gets something wrong, so you go looking for help. Its website points you to a Discord. You open the Discord, and the pinned message warns you about impersonators and says staff will never DM you first. Then someone DMs you. They are in that same Discord, because the official support channel is also where the scammers wait. The official help path opens by telling you the official help path is dangerous.

I could not unsee that. So I built a company to fix it. Then I realized I was fixing it for the wrong customer.

More of normal life is moving on-chain every year. Not just trading. Savings first, and then, slowly, the things that sit behind savings: retirement, equities, the boring money. That shift brings a steady wave of people who are new to all of this. They are not here for the casino. They are people who happen to have real value on a blockchain now, and who will, eventually, need help with it.

Here is what help looks like for them today. The app or protocol sends you to its Discord or Telegram. The channel greets you with a scam warning about itself: do not trust DMs, staff will never message you first, verify every link. And the people that warning is about are right there in the channel, watching for someone confused enough to talk to. The support surface and the predator's hunting ground are the same room. Crypto-native users have fully normalized this. They learned the survival rules so long ago they forgot they ever had to learn them. A newcomer has not. The moment you say the loop out loud to someone outside crypto, it sounds insane, because it is.

The thing that first made me stop was small. A protocol's own site pointed to a Discord, and the Discord's pinned message was a scam warning about the Discord. The official channel, telling you the official channel is dangerous. Once I saw that pattern I started seeing it everywhere.

Then I watched large lending protocols start pulling out of Discord and Telegram, in part over exactly this. The support surface had become a liability they did not want to own.

So I built TxDesk. The first version was B2B: support infrastructure a protocol could run so its users got real answers instead of a scam-infested chat room. Underneath, the product did something specific, and it is the same thing it does today. It reads live on-chain data and explains it in plain language. It decodes a transaction, checks an approval, looks at what a contract actually is, and answers from live on-chain data. It is read-only with respect to your funds. It never asks for or holds a private key. The bet was that protocols would adopt this as their support layer.

Then I paid attention to what actually happens during an incident. When a protocol is being exploited, its attention goes exactly where it should: pause the contracts, trace the funds, pull in security people, coordinate, get a statement out. That is the correct priority for the protocol in that moment. The consequence is structural, not a moral failing. The thousands of individual users flooding in with "am I affected, was my wallet exposed, where are my funds, am I safe" are not, and cannot be, the priority in that window. The buyer I was selling to did not want to own that layer the way I had assumed. At the exact moment it mattered most, answering the individual user was nobody's job.

That reframed the whole thing for me. The people who have the questions, and the worry, and the money on the line, are the users. Not the protocols. The demand had been downstream the entire time. I had built the right tool and pointed it one customer too far upstream.

So I pointed TxDesk directly at the people who actually ask "am I safe." Same product underneath. Same thesis: people are coming on-chain and they need real answers, not a chat room with a scam warning pinned to the top. Different customer. The version I am building now lets the user ask the chain directly, in plain language, and get an answer grounded in what is actually on it.

Most people who follow my work knew TxDesk as a B2B product. I am not going to quietly pretend it was always this. It was not. I built it for one customer, learned the demand lived with another, and moved. The consumer version is what I am building now.

Your Support Team Shouldn't Need to Read a Block Explorer

TxDesk — Mon, 04 May 2026 14:27:48 +0000

It's 3am UTC. Someone in your Discord pastes a transaction hash and the message: "did i just get drained??"

What happens next is mechanical. A moderator opens the block explorer, scrolls past gas limits and method calls and log topics, decodes the transfer, translates 0xa9059cbb into "this was an ERC20 transfer," cross-references the destination address, then types something like "looks like you swapped on Uniswap, here's the route." The user replies with a follow-up. Maybe the same flow runs five more times.

That same conversation will run two hundred times in this channel tonight. The moderator wasn't hired for forensics. The protocol didn't budget for it either.

The notification gap

The Drift exploit on April 1 ran for about twelve minutes. 31 withdrawal transactions, $285M out the door, and the protocol's first X post telling users to halt deposits arrived after on-chain analytics firms had already flagged the active attack. Wasabi on April 30 followed the same shape: the attacker started draining at 07:48 UTC, kept going for roughly two hours, and the official acknowledgment showed up afterward. Users watching the price action on their phones knew something was wrong before the team confirmed it.

This isn't anyone's fault. The sequence has to be: detect, pause, investigate, post. Posting first risks broadcasting an exploit before the contract is safe. Pausing first protects the funds. Communication is last because it has to be.

But during that gap, the people who deposited into the protocol have no answer to the question they care about most: is my position safe right now. They get told to "monitor official channels," and the official channel is silent.

The "am I affected?" flood

April 18, Kelp DAO: a forged LayerZero message drained 116,500 rsETH, about $292M. Within hours, nine downstream protocols had paused something. Aave froze rsETH and WETH markets. Around $8.45B fled Aave's pools in the next forty-eight hours. The Aave forum's incident report counted 119 borrower positions at liquidation risk after the dust settled.

Each of those protocols got the same wave. Discord channels filled with the same five questions: am I affected, do I need to do anything, where is my money, can I withdraw, what should I revoke. Same questions, hundreds of times, in parallel across nine protocols. Each answer requires looking at the user's specific position. The volunteer mod can't batch them.

Revoke.cash maintains a permanent page at revoke.cash/exploits called "Check If You're Affected." It exists because every exploit produces this exact flood, and someone built a static site as the least-bad triage tool. The existence of that page is the evidence.

The revoke.cash gap

After Wasabi, the official guidance was to revoke approvals at revoke.cash. Within hours, a phishing account named "Wascbi Profocol" posted a fake revoke link in the same threads where users were asking what to do. Per Blockzeit's coverage, it "apparently misled several people."

Read what the official advice actually asks of a user. Identify which contracts you've approved. Recognize the real protocol's account from the impostor. Open a tool you've probably never used. Sign a transaction whose effects you can't preview. Do all of this fast, while panicking, while scammers are setting up imitation links.

The revoke.cash advice is correct. It's also incomplete in a way that matters. Users following the safety procedure got drained again because the procedure assumed knowledge they didn't have, on the day they could least afford a wrong click.

The layer nobody built

Protocols have monitoring. Hypernative, Blockaid, Cyvers all detected the recent exploits within seconds. Protocols have docs, audit reports, X accounts, status pages, Discord. What's missing isn't information. It's translation.

A monitoring alert says "rsETH/WETH market frozen." A user wants to know "is my $40K still there, what is the worst case for me, and what do I need to do in the next ten minutes."

These are not the same artifact. One is protocol-shaped. The other is position-shaped. The translation between them is what Discord moderators have been doing manually, one user at a time, with a block explorer open in another tab.

Morpho moved its public Discord to read-only on February 1, 2026. Co-founder Merlin Egalite, on record: "Discord is actually full of scammers. people would get phished while actually searching for answers despite heavy monitoring, safeguards, etc." DefiLlama is migrating off Discord too. The volunteer-mod-with-block-explorer model is being abandoned by the protocols that originally built it.

What the workflow looks like instead

The piece I've been building is the translation layer. TxDesk (txdesk.io) takes one input, an address or a transaction hash, plus a question in plain English. It runs the lookups a moderator would run, against the user's actual on-chain state, and returns the answer in seconds.

A user pastes a tx hash and asks "what happened?" The agent decodes the transaction, returns status, parties, amounts, fees, and the decoded method call, in a paragraph a non-technical user can read.

A user asks "will I get liquidated if ETH drops 20%?" The agent calls explain_liquidation_risk against their lending position. It returns currentHealthFactor, distanceToLiquidationPercent, and an array of perAssetLiquidationPrices with one row per collateral asset. Plus suggestions: requiredDebtRepaymentUsd to hit a target health factor, or requiredCollateralAddUsd to add instead. The user gets a number, not a vibe.

A user pastes a Sui package ID and asks "is this safe?" The package risk tool returns riskLevel, isLatestVersion (false flags deprecated versions, the pattern that bit Scallop), and upgradeCapOwnerKind (AddressOwner with an upgradeable policy is the single-key blast-radius pattern that bit Volo). A full Cetus CLMM scan returns end-to-end in 1.7 seconds.

A user pastes a failed transaction. The diagnosis tool returns one of eight Sui failure categories, with two or three suggested fixes computed from the user's wallet state.

Every field is tagged dataAvailable: full | partial | unavailable, so the agent can't invent values that didn't load. 39 tools, 43+ chains.

Every exploit in April produced the same support failure. Different attack vector each time, same broken communication on the user side. The fix isn't more moderators, faster Discord triage, or better Twitter posts. It's an answer that runs in seconds, in plain English, against the user's actual on-chain position, available the moment the user asks. That layer didn't exist. Now it does.

Three Sui Exploits in One Week. So I Built 5 Security Tools to Catch Them.

TxDesk — Thu, 30 Apr 2026 13:21:02 +0000

In nine days, three Sui DeFi protocols got hit. Volo lost $3.5M on April 21. Scallop lost $142K on April 26. Aftermath Finance lost $1.14M USDC on April 29.

Three different protocols, three different attack patterns, one shared root cause: nobody had a way to check the structural risk before signing.

The three patterns

Scallop: Sui packages don't disappear when you upgrade them. They get superseded — but the old version stays callable on chain forever. Scallop's V2 staking-rewards package from November 2023 sat dormant for 17 months until someone found an uninitialized last_index counter and claimed rewards from a synthetic position that "existed since the spool launched." The frontend pointed at the new version. The on-chain remnants didn't care.

Volo: Not a smart-contract bug. The contracts were audited. The single keypair holding upgrade authority over three vaults got compromised. $3.5M gone in one signing session. The audit didn't matter because the audit assumed the key was safe.

Aftermath Finance: A public entry function called add_integrator_config had no authorization check. The attacker set max_taker_fee to 0. A signedness bug then interpreted that as negative. They got paid to trade. Eleven transactions, 36 minutes, $1.14M.

Three patterns: deprecated code still callable, single-key admin, missing auth on a public entry. None of them are detectable by reading dApp UIs. All three are detectable from RPC data.

The five tools

I built five Sui-specific security tools for TxDesk, the AI support layer for crypto products I've been working on. Each tool is a single TypeScript service, fully tested, plugged into the agent's tool registry.

assess_sui_package_risk. Detects deprecated package versions by walking the UpgradeCap chain — the original Scallop pattern. Classifies cap ownership (single-key vs Shared multisig vs Immutable) — the original Volo precondition. Counts public entry functions that don't take a Cap parameter — a heuristic for the AftermathFi pattern. The interesting bit: my original plan called for three discovery paths to find the UpgradeCap. Smoke testing against mainnet revealed Sui's 0x2::package module emits no Move events at all, so the event-based path was structurally impossible. Deleted it. The remaining publish-tx scan does all the work, faster.

diagnose_failed_sui_transaction. Classifies eight failure categories — INSUFFICIENT_GAS, MOVE_ABORT_SLIPPAGE, MOVE_ABORT_AUTH, MOVE_ABORT_GENERIC, OBJECT_VERSION_CONFLICT, SHARED_OBJECT_CONGESTION, INVALID_GAS_OBJECT, TYPE_ARGUMENT_ERROR — with plain-English suggestions per category. The interesting bit: I tightened the slippage heuristic during planning. The original idea was to guess slippage from module name alone (any abort in a pool module = probably slippage). That's wrong. Many functions in pool modules aren't swaps. Now slippage requires BOTH the module name to match (pool|swap|amm|dex|router) AND the function name to match (swap|trade|exchange|exact_(in|out)|exec). If the function name isn't resolvable from the abort error string, classification falls back to MOVE_ABORT_GENERIC. False negatives over false positives.

inspect_sui_object. Single-RPC tool that returns object type, ownership kind (one of AddressOwner / ObjectOwner / Shared / Immutable), version, and decoded content. For Coin<T> objects, a parallel suix_getCoinMetadata(T) call decodes the balance with proper decimals. The interesting bit: when the metadata fetch fails, we surface the raw balance string and decimals: null rather than defaulting to the SUI decimals. Showing "1,500,000,000 (raw, decimals unavailable)" is honest. Showing "1.5 SUI" when we don't know the actual decimals would be a guess.

check_sui_coin_metadata. Answers "is this token legit, and who can mint it?" Validates the coin type structure (also accepts the wrapped form 0x2::coin::Coin<...>), fetches metadata and total supply, locates the TreasuryCap<T> and inspects its current owner. The interesting bit: I introduced an RpcOutcome<T> discriminated union here — { ok: true; value: T | null } | { ok: false }. The reason is subtle. For metadata, a null result from suix_getCoinMetadata means "definitively no metadata published" (a scam signal). A network error means "we don't know yet." The original safeRpcCall helper flattened both to plain null, which would have falsely flagged real coins as scams during transient RPC outages. The discriminated union forces the call site to distinguish.

check_sui_account_risk. SUI balance, owned-object inventory, UpgradeCap inventory, recent transaction count. Flags addresses holding upgrade authority over five or more packages as CRITICAL — the Volo blast-radius pattern. The interesting bit: a 30-second total operation timeout wraps the entire pipeline. Whales with thousands of owned objects could otherwise drag the agent. If the deadline fires mid-pagination, the report returns with coverageComplete: false, which forces riskLevel: 'UNKNOWN'. We never fabricate a "looks fine" answer from a partial scan.

The mainnet smoke test

I picked Cetus CLMM as the target. It's a well-known Sui DEX, handles real daily volume, and the team is reputable. The package ID came from the Cetus contracts Move.toml on GitHub: 0x1eabed72c53feb3805120a081dc15963c204dc8d091542592abaf7a35689b2fb.

The agent classified the intent as security_concern, routed correctly to assess_sui_package_risk (not assess_contract_risk — the EVM version), and returned CRITICAL in 1.7 seconds (post-cleanup). Two findings:

isLatestVersion: false. The package was superseded by 0x25ebb9a7…dfee5e3. Calling the old version is the Scallop pattern, live in production on a real protocol.
upgradeCapOwnerKind: 'AddressOwner'. A single keypair (0xdbfd…4a47) controls upgrades. The Volo precondition.

That's not a hand-picked test fixture. That's the product working on a real Sui DEX on day one.

The never-lie principle

The default engineering reflex when an API call fails is to return false. It compiles. It type-checks. It doesn't crash. And it's a lie.

"API failed" and "the answer is no" are different statements. Defaulting to false collapses them and propagates a wrong answer with full confidence.

Every Sui tool I built uses nullable booleans for every signal that could fail: isPackage: boolean | null, isLatestVersion: boolean | null, treasuryCapStatus: SuiTreasuryCapStatus | null. Each report includes a dataAvailable: 'full' | 'partial' | 'unavailable' flag. Only 'full' reports are cached. Partial reports are returned to the user but never written to Redis, so the next call retries.

Concrete example. If we can't find the UpgradeCap for a package — the publish tx got pruned, the RPC timed out, whatever — we don't say there's no cap. We say upgradeCapId: null, upgradeCapOwnerKind: null. Those are different statements. The first would imply an immutable package. The second admits we don't know.

The cost: users sometimes see "we couldn't determine X." The benefit: when we DO say something, it's worth trusting.

What mainnet smoke testing taught me

I wrote all five tools, wrote 87 tests, all green. Then I ran four curl commands against the actual Sui mainnet RPC. Three findings:

The SuiVision verification URL I'd put into the package-risk service (api.suivision.xyz/v1/packages/...) didn't resolve. DNS error. The endpoint I'd assumed existed never did.
The Move event filter for UpgradeCap discovery (MoveEventType: '0x2::package::PublishEvent') returned empty 200 responses. Broadening to the entire 0x2::package module returned zero events from any source. Sui packages don't emit Move events for publish — at all.
The CurrencyCreated event filter for TreasuryCap discovery DID return events, but the event type is generic (CurrencyCreated<T>) so a non-parameterized filter never matches, and the event's parsedJson only contains {decimals} — not the cap ID I'd assumed.

All three findings led to deletion, not workarounds. SuiVision call: deleted entirely. Path A in package-risk: deleted (Sui literally cannot provide what I was asking for). Path A in coin-metadata: replaced with a publish-tx scan that piggybacks on a sui_getObject call already happening, costing one additional RPC instead of three.

Tool execution dropped 46%. Code got smaller. The result is more honest. The lesson: never write a code path that depends on an API behavior you haven't verified — and when smoke testing reveals that path is dead, delete it. Don't leave it as a "best-effort fallback" that's actually a no-op.

Numbers

5 new services: 2,893 lines
5 test files: 2,080 lines
87 new tests, 1,097 across the codebase
37 tools total in TxDesk now (up from 32)
One evening session, planning through commit 54b2b40
Smoke test caught real CRITICAL issues on Cetus CLMM on day one

Closing

If you're building on Sui or using Sui DeFi protocols, these tools are live at txdesk.io. And if you're a protocol team dealing with fifty identical "am I affected?" messages after every exploit — that's the problem TxDesk solves.

What's the largest project you or any programmer you know has completed entirely with AI assistance?

TxDesk — Tue, 28 Apr 2026 10:49:45 +0000

I'm 18 and I built a Layer 1 blockchain from scratch in Rust

TxDesk — Mon, 27 Apr 2026 13:40:40 +0000

The project

NOVAI is a Layer 1 blockchain where AI entities are protocol primitives, not smart contracts. Most "AI blockchains" bolt AI onto an existing VM through oracle calls or contract wrappers. NOVAI does it differently. AI entities exist at the same level as accounts and validators. They have on-chain identity, persistent memory, economic balance, and capability flags. All enforced at the protocol layer.

There is no smart contract VM. No WASM runtime. Every transaction type is a native protocol operation.

The entire codebase is clean-room. No code from Substrate, Tendermint, Cosmos SDK, or any other implementation. 65,000+ lines of Rust across 16 crates, 1,100+ tests, zero unsafe code.

GitHub: github.com/0x-devc/NOVAI-node
Website: novai.network

What makes NOVAI different

On most blockchains, "AI integration" means an off-chain model that pokes the chain through oracle calls or contract wrappers. The AI runs somewhere else. The chain just stores the result.

NOVAI puts AI entities inside the protocol. An entity is a first-class on-chain identity that:

Holds its own balance and pays its own fees
Has its own Ed25519 signing key and signs its own transactions
Publishes signal commitments (anomaly, prediction, risk-score, and 4 more types)
Owns persistent memory objects (chain summaries, statistics snapshots, anomaly logs)
Has governance-controlled autonomy modes and capability flags

The chain doesn't need to interpret bytecode to understand what an entity is doing. Every operation has known semantics at the protocol layer.

What shipped this week

Open source launch

The full codebase went public under Apache 2.0. Git history was cleaned. CI is green on GitHub Actions.

Developer docs - 5 deliverables

1. Quick Start Tutorial - "Build Your First AI Entity on NOVAI in 10 Minutes"

Step-by-step CLI walkthrough. Generate keys, fund from faucet, register an AI entity with its own signing key, publish a signal, create a memory object, query everything back. Every command and output block is real captured data from a live 4-node devnet.

Read it on GitHub

2. TypeScript SDK Tutorial

170-line working example. Connect to a node, fund an account, transfer tokens, register an AI entity, verify it on chain. Self-contained npm project. Just run npm install && npm start.

See the example

3. Rust SDK Tutorial

Same flow in idiomatic async Rust on tokio. Single file, runs with cargo run --example quick-start.

See the example

4. RPC Reference

777 lines covering all 13 JSON-RPC endpoints. Each one has a description, parameter table, response shape, error table, and a real curl command with captured output.

Read it on GitHub

5. Architecture Deep Dive

Crate-by-crate walkthrough of all 16 crates organized by dependency layer. Mermaid diagrams for the consensus flow and the transaction lifecycle. Three guided reading paths for newcomers.

Read it on GitHub

Block explorer

React + Vite + Tailwind single-page app that calls the node's RPC endpoints. Live block list with 2-second polling, block detail page, account lookup, AI entity page with memory objects and signals, and a network stats dashboard. Developers run it locally against their devnet.

AI entity demos

Three runnable demos showing the AI-entity-as-protocol-primitive pattern.

Anomaly bot - A TypeScript bot that registers itself as an on-chain entity, polls chain activity every 1.5 seconds, runs three heuristic detectors (empty block streaks, round spikes, stalled chains), and publishes an anomaly signal plus a memory object whenever one fires. Cooldowns prevent re-firing on the same condition.

Multi-entity demo - Two bots interacting purely through the chain. Bot A (predictor) publishes prediction signals guessing future block tx counts. Bot B (risk-scorer) reads those predictions via on-chain memory objects, waits for the target block, compares predicted vs actual, and publishes a risk-score signal with the delta. No shared database. No API calls between them. Just on-chain data.

CLI demo script - Full entity lifecycle in bash with banner sections for blog posts or video recordings. Keygen, faucet, register, credit, signal publish, memory CRUD, query.

The bug fix that unblocked everything

While building the tutorials I found that entity-signed signal and memory transactions were silently failing through the RPC path. The root cause was four handlers using the wrong lookup key. They did a primary-key lookup with an address value instead of using the reverse index that maps address to entity ID. The entity record was never found so every signal and memory transaction quietly returned an error that got swallowed.

The fix was refactoring all four handlers into inner functions that take a pre-resolved entity. Added 7 regression tests that exercise the full dispatch path. Verified end-to-end on a live devnet.

I wrote about a similar silent-failure bug in my first blog post: The Bug That Silently Broke My Entire Blockchain

The numbers

65,000+ lines of Rust
16 crates in the workspace
1,100+ tests passing
30M+ blocks committed on the private testnet
Zero unsafe code
10 native transaction types
4-validator private testnet running since early 2026
HotStuff BFT consensus with 3-chain commit rule
Sparse Merkle Tree state with deterministic 32-byte roots
Ed25519 signatures, Blake3 hashing, Noise XX transport encryption
Apache 2.0 licensed

What's next

Public testnet. The private testnet runs on a shared VPS that causes state root divergence under sustained load. The fix is a dedicated CPU server. Once that's in place we'll have a public RPC with SSL, validator onboarding, and the block explorer deployed at explorer.novai.network.

I'm also looking for a technical co-founder. I'm building this solo. If you're a Rust engineer interested in BFT consensus, on-chain AI primitives, or clean-room blockchain development, the codebase is open and PRs are welcome.

Website: novai.network
GitHub: github.com/0x-devc/NOVAI-node
Twitter: @NOVAInetwork

I'm 18, I built an AI support agent for DeFi protocols with 77K lines of code, and I have zero customers

TxDesk — Sun, 26 Apr 2026 16:26:27 +0000

I'm Victor, 18 years old, solo founder. I've spent the last several months building TxDesk, an AI-powered support widget that DeFi protocols can embed on their sites. Users paste a transaction hash or wallet address, and the agent decodes it into plain English.
What it actually does
The agent pulls live on-chain data across 46 blockchains (21 EVM chains + Solana + Bitcoin + TRON + XRP + 20 more). It can:

Decode any transaction and explain what happened in plain language
Scan token approvals and flag risky unlimited allowances
Check wallet balances across any supported chain
Diagnose why a transaction failed
Track cross-chain bridge transfers
Assess smart contract risk
Verify wallet ownership via WalletConnect (Sign-In With Ethereum / Solana)

It deploys as an embeddable website widget (one script tag), a Discord bot, or a Telegram bot.
The stack

TypeScript monorepo (api + widget + website + shared package)
Preact for the widget (needs to be tiny, it loads on other people's sites)
Rollup for bundling the widget into a single JS file
OpenAI function calling for the AI agent layer
RocksDB-backed caching for chain data
30+ tool functions the AI can call depending on the question
WalletConnect v2 for wallet verification
Stripe for billing
Hetzner VPS, Nginx, Docker

How I built it
I don't write code from scratch. I use Claude Code (Anthropic's CLI coding tool) to build everything. I describe what I want, review the output, debug issues, and make architectural decisions. The AI writes the code, I steer the product.
This sounds like it shouldn't work for a production system. But here's what the repo looks like after months of this workflow:

~77,000 lines of TypeScript
~1,700 tests passing
Zero clippy-equivalent warnings
Multi-tenant SaaS with auth, billing, rate limiting, and role-based access
Full CI pipeline

The key to making AI-assisted coding work at scale is decision documentation. I run 2-3 Claude Code terminals in parallel. Each terminal has no memory of what the others decided. So I write markdown docs that capture every architectural decision and load them into each session. Without that, the AI will happily undo work from another session.
The problem nobody tells you about
Building the product was the easy part. Distribution is where I'm stuck.
Here's what I've tried:

80+ cold DMs to protocol founders on Twitter, zero replies
40+ cold emails, zero replies
Daily Twitter posting, engagement but zero inbound leads
Discord community presence, got auto-muted for spam when I posted about TxDesk
Posting in protocol Discords, most block new members from posting links

The product works. I can demo it right now at txdesk.io. But nobody knows it exists, and cold outreach from an unknown 18-year-old solo founder looks identical to the 50 other pitches a protocol team gets every week.
What I'm doing differently now
I've stopped cold outreach entirely. New strategy:

Targeting crypto community management agencies instead of protocols directly. One agency manages 10-50 client communities, so one sale means multiple deployments.
Being helpful in protocol Discords without mentioning TxDesk. Answering on-chain questions manually to build reputation first.
Twitter engagement on trending crypto security events. Replying with smart analysis on exploit threads. One reply got 1,764 views from 13 followers because I was adding genuine insight, not promoting.
In-person events. Attending Ethereum London meetups. A 5-minute laptop demo beats 100 DMs.
Applying to CV Labs Accelerator in Zug. I grew up there, it's my home turf.

What I've learned so far

Nobody cares about your feature list. "46 chains and 30 tools" means nothing to a buyer. "Your moderators won't need to open Etherscan anymore" means everything.
Cold outreach doesn't work when you have zero brand. You need to be known before you pitch.
Building with AI tools is a legitimate superpower for shipping speed. But shipping speed doesn't matter if nobody uses what you ship.
The hardest transition is going from full-time builder (12 hours of coding) to full-time seller (2 hours of outreach and then waiting). The waiting feels like you're not working. You are.

If you're in a similar spot, zero customers, great product, no distribution, I'd genuinely love to hear what's working for you. And if you're building in the DeFi space and want to try TxDesk, the demo is live at txdesk.io.