Forem: TxDesk

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.