# AI, Vibe Coding, Bitcoin, Stablecoins, Summer and a Mountain of Data

> Is it possible to vibe-code a blockchain explorer in 2026?

Published 2026-10-01 · by Artjoms Krasnopjorovs (https://krasnopjorovs.com/)

I got the idea for this article one summer evening, on vacation by the sea. I had started a vibe coding [1] project and had already spent a couple of evenings on it. It's a blockchain explorer. You can use it to check a crypto wallet before you accept money from it [2], or just to look around the blockchain and see who sends what to whom, and how much.

Around the same time, Reddit removed one of my posts. The moderator said it was written by AI, had low-effort technical content and no AI disclaimer. Fair enough — I did ask an AI to write it, and I was sharing one technical result with the community. To be honest, the solution behind it was not trivial at all. AI and a bit of effort on my side just made it look easy ;)

It made me think. Should we label AI-written text? Or should we label hand-made text instead, as a sign of quality?

Anyway, the text you're reading was written by a human and an LLM together.

It started as pure vibe coding
So here's the story of how I built an MVP of an explorer for Bitcoin, and for USDT and USDC on TRON and Ethereum.

Old work habits kicked in. In my very first prompt I asked the LLM not only for a product concept, but also to split the big product into smaller steps that are easier to deliver.

The first couple of evenings were pure vibe coding: send a prompt, watch the product grow. The LLM's plan had about seven steps. We did two of them quickly, and it looked like we'd be done in a week and spend the second week on polish. The first steps were simple: set up a node [3], download the blockchain. But soon it was clear that complex graph algorithms [4] are at the limit of what LLMs can do. You see it when there's still no result after three or four tries. The first "clean" run over the whole Bitcoin graph worked on the ninth try [5]. It needs a lot of computing power and took more than two weeks. This was still vibe coding — the only extra thing I did was ask the LLM to keep documentation on how it processes the transactions.

When the vibe ran out
The next challenge was keeping the data up to date with new blocks [6]. And here it got harder. The LLM that built the first version simply couldn't make the updates work. We split the work into smaller tasks, and I noticed something funny: LLMs quickly get lost in small details and forget the main goal. By then I had almost run out of patience. It wasn't fun anymore to keep telling the LLM that things didn't work. But I wanted to finish, so I brought in some structure: pick the most important task, break it down, make a plan, and work in sprints. First, though, I had to deal with the mess: tons of scripts, some documentation, and an LLM that had forgotten what it did two days ago. So I asked it to review the code and the data in the database, and to update the documentation. Then I switched to another frontier model — and things started moving. Lesson: keep documentation, in any form. Otherwise you lose track very quickly in anything bigger than a landing page [7].

Back to the updates. With the new process in place, we went back to them — and they showed several serious errors in the data we had already built. At some point I had every frontier LLM check the code, and the numbers still didn't add up. It was summer, it was hot, so I took a break and enjoyed the weather. Meanwhile, a new model came out. It could go further and made the breakthrough: the data was calculated and checked again from the ground up. The next days went into making the site nicer to use.

Stablecoins and 3 TB of deleted data
Bitcoin is great, but a lot happens in stablecoins. I checked my hardware and decided to add USDT and USDC — but only on the two most popular chains, TRON and Ethereum [8]. The main LLM was sure this would be much easier than Bitcoin. LLMs seem to have picked up some overconfidence from their training data. And in the end it was right — except that data got deleted several times, about 3 TB in total, and had to be restored [9]. The LLM didn't see that coming. In my experience, this is another thing about today's LLMs: when a task is less common in what they learned from, they make noticeably more mistakes. The rest was just a matter of time.

A mountain of data
A word about the data — there's a mountain of it. Every block has to be read, every transaction split by address, balances and links calculated, and everything saved into the tables the site uses. Bitcoin alone has 678 million addresses, and at one point the flow tables had 3.6 billion rows. The USDT transfers on TRON take about 955 GB, the address index another 352 GB, Ethereum 252 GB. The catalogue of address labels — exchanges, companies, sanctions, freezes — is rebuilt every night: 13 million rows. Sanctions and freezes are only a small part of it, about 11,000 addresses. Most evenings went not into code, but into calculating all this, recalculating it and checking that it matches. And this only works on fast NVMe drives or in RAM — on normal disks it takes days. That's real pressure on the hardware, and you need to plan for it from day one.

When everything came together, the whole thing turned out to be very slow. Nobody likes slow, so a few more evenings went into speeding it up. Most of it was solved by pre-calculating extra data and using faster hardware [10].

What I learned
That's already a lot for vibe coding. You need more than mood and motivation — you need discipline: think through the architecture, decide which server does what, write documentation, test, optimise. But it's all doable if you have the time and enough AI capacity. I use paid subscriptions to Claude, ChatGPT, Grok and Gemini — and even with four of them, the limits run out fast. If you know software development, use it to keep an eye on what the LLM is doing.

I planned one week and spent two months of evenings. Yes, I didn't write a single line of code by hand, and the product works. The LLM often said everything was done. But I was the one who decided what a correct result is, when to publish data, and which steps need a human check. Vibe coding works as long as you know exactly what you want to get. After that, it becomes product work: architecture, invariants [11], documentation, and no risky, irreversible steps without thinking through what can go wrong and how to recover.

The Reddit moderator saw an easy AI text. But the real work wasn't writing it — it was checking the result.

Key takeaways: today's frontier LLMs can already solve complex problems by turning them into a step-by-step plan. But without control, and without someone bringing them back to the main goal, AI can't get to the result on its own yet. Who knows — maybe the next generations will build projects like this from one prompt. Until then — build, explore and enjoy the new technology.

👉 See the result: btc.artjoms.ai





Technical details
[1] Vibe coding. There are many definitions, but this one, from Rick Rubin on The Ben & Marc Show podcast (a16z, May 2025), is my favourite:

"How I started in music was punk rock. If you had something to say, you could say it. You didn't need the expertise or skill set, other than your idea and your ability to convey it. And vibe coding is the same thing: it's the punk rock of coding."
Source: a16z.com — Rick Rubin: Vibe Coding is the Punk Rock of Software

[2] Clean, grey or worse. The registry holds 11,062 addresses under official sanctions (OFAC — USA, SECO — Switzerland) or issuer freezes (Tether, Circle). For each one you can see who imposed the measure, under which programme, and when. A direct match with a sanctioned address and an issuer freeze are different signals, and a wallet's counterparties are visible in its transfer history. An address not being on a list doesn't make it "clean": sanctions address lists are known to be incomplete. The names of sanctioned parties are stored in the database but not shown publicly.

[3] Hardware. At the start I had no clear picture of which tasks would run where. The first rule I set for the AI: computation runs on one server, serving and nodes on another, and finished immutable releases are passed between them rather than a shared disk. Own Bitcoin, TRON (java-tron) and Ethereum (reth) nodes. Core processing runs on our own copies of the blockchains, with no third-party analytics services; one section of Ethereum history came from an external RPC [9]. Hot data sits in RAM and on NVMe, history on HDD/SAS.

[4] Bitcoin graph. Clustering by the co-spend heuristic (union-find): addresses spent together in the same transaction are presumed to belong to one owner. This is an assumption, not proof; CoinJoin transactions, for example, can wrongly merge different owners. Result: 678 million addresses grouped into ~117 million clusters.

[5] What a "clean" pass means. Every wallet balance is counted in whole satoshis. At block 961,926, all wallet balances plus the few outputs without an address added up to exactly 2,006,829,176,030,288 satoshis — the same total as Bitcoin Core's own set of 165,794,910 unspent outputs. The check is strict: one satoshi off and the release is rejected. A second check rebuilds the balances from the full transaction history and must land on the same numbers. These checks caught several accounting errors — that's why it took nine attempts. They don't prove that the ownership clusters are correct; that needs separate validation.

[6] Incremental catch-up. Hourly and fully automatic: new blocks → recompute → publish. Publication is fail-closed: five independent layers (facts, identity, UTXO, serving, transactions) must agree on the same block height and hash, otherwise nothing is published. Releases are immutable; switchover is atomic. Wallet IDs stay stable across recomputations. Every formal screening creates an immutable evidence record: the state of the blockchain, knowledge base and engine at the moment of the check.

[7] Documentation as context handover. One model built the full recompute but couldn't handle the incremental one. Another model picked up the project, which was possible thanks to the documentation. Models aren't interchangeable; documentation is the main thing that survives a change of model.

[8] Stablecoins. USDT and USDC on TRON and Ethereum account for about 82% of all USDT and USDC in circulation and 69% of all stablecoins (DefiLlama, 27 Sept 2026). History is complete, from contract deployment to today's block. TRON USDT alone is 3.69 billion transfers and 318 million addresses. Ethereum continuity is verified across blocks 4,550,000–26,062,531, after which a live tail updates every 3 minutes. TRON updates every 2 minutes and lags the network by about a minute. Ethereum source data: ~1.2 TB of transaction history plus 216 GB of compressed receipts.

[9] Deleted data. Over the project about 3 TB was deleted this way and had to be restored; the most telling case was Ethereum history. The first route to it via RPC hit a pruned node. In the second, we assembled a second reth node from snapshots: the LLM suggested "fixing" a checkpoint in its database, and on start-up the node ran its self-healing and deleted 471 GB of extracted data within minutes (the archives survived). I approved that change, so there was a human in the loop. The third route worked: read the files directly, read-only, and close the remaining gap through an external RPC. Lesson: human approval alone isn't enough — a risky action needs an impact assessment and a recovery plan first.

[10] Performance. Two stories. First: a TRON wallet query grew from ~1.4 s to a minute once the live layer reached 20 GB. The fix: every night the closed layer with precomputed per-address aggregates rolls forward, leaving only a few hours of live tail. Second: search by date took 60 seconds. It turned out an old copy of a module with the same name was being loaded from the home directory, opening 2,727 connections to the database. After the fix, a cold date search takes 1.4–4.5 s. Add a stale-while-revalidate cache and warm-up every minute, so common queries don't hit a cold cache. Result, in my measurements: a transaction opens in 0.04 s, a wallet in 0.1–0.3 s. The TRON USDT address index is 352 GB. Stack: DuckDB + Parquet, no heavyweight DBMS.

[11] Invariants are rules that must always hold; if one is violated, the system stops instead of publishing. Examples: balances match Bitcoin Core to the satoshi, no negative balances, sent = received for stablecoins, wallet IDs never change.

Source: https://krasnopjorovs.com/articles/ai-vibe-coding-bitcoin-stablecoins-summer-and-a-mountain-of-data