After writing a Celestia script: Many aspects of Cosmos are poorly executed
TechFlow Selected TechFlow Selected
After writing a Celestia script: Many aspects of Cosmos are poorly executed
Celestia definitely didn't have adequate measures in place to handle large-scale traffic at the time, and their RPC node configuration was also quite perfunctory.
Navigating Web3 tides with focused insightsAuthor: Wuyue, Geeker Web3
On December 17, I realized that CIAS inscriptions were about to go live on Celestia, so I decided to quickly whip up a script to farm inscriptions. Now, I have quite a few complaints regarding Celestia, its position within the Cosmos ecosystem, and the CIAS event itself.
In fact, writing a script to farm inscriptions isn't difficult—it mainly consists of three modules: wallet setup, node connection, and transaction flooding. The first two steps can typically be implemented quickly by referring to developer documentation for the target blockchain.
I first checked Celestia's official website and GitHub repository but found no use cases aimed at developers building user-facing applications—most of the documentation focused on running nodes. This is understandable, because Celestia is not a consumer-facing (ToC) blockchain. Celestia only briefly mentions in a corner that it's based on Cosmos and can interact with its mainnet via CosmJS.
So I went straight to CosmJS. But Cosmos, well, they can't even get their documentation right. I headed directly to GitHub, where such JS libraries usually include usage examples. However, the tutorial was buried deep within a secondary page, and when I followed the configuration instructions, it threw errors.
The error wasn’t due to my environment; it was because the tutorial hadn’t been updated alongside the codebase, resulting in issues like renamed classes or inaccessible methods. I switched npm library versions to match older tutorials, but some examples still wouldn't run. After struggling for a while, I gave up.
Then I tried Googling again, only to discover that the correct documentation was actually on the official site, not GitHub—which defies common practice. Seriously, couldn't the GitHub README just update the link to point to the official documentation?
After finding the correct tutorial, I quickly completed the wallet creation and node connection steps. Then came the transaction flooding module. This part is essentially just a for-loop handling transaction signing and network requests. But here, I ran into more problems:
In the CosmJS library, all transaction methods expose only the parameters of the transaction itself, but do not expose the "sequence" number, which is analogous to nonce in Ethereum—a counter used to prevent replay attacks, automatically incremented after each transaction.
The sequence is fetched from the network during the sign phase (same with chainId), going through sendTokens() → signAndBroadcast → sign(). Making a network request every time before submitting a transaction slows down the farming speed and generates unnecessary traffic, which is bad for flooding, and also makes accelerating or canceling transactions harder.
Let’s recall how Ethereum’s Web3JS sends transactions—you can manually specify the nonce. But you can’t do this in CosmJS. I still believe Ethereum’s design is far more reasonable, allowing direct nonce specification to accelerate or replace stuck transactions. If a transaction gets stuck, you can simply send another one with the same nonce to overwrite it—and this feature is also useful for our flooding purposes.
With limited time and several functions needing modification across other libraries, I decided against using Proxy hooks and instead modified the CosmJS library directly.
The idea behind triggering flood transactions in the script is to continuously initiate transactions and generate signatures via a for-loop, sending them to the RPC node. After each transaction, the sequence/nonce increases by 1. After sending 20 transactions, the cycle restarts.
The sequence is only pulled locally once at the beginning of each flooding cycle, avoiding the default CosmJS behavior of re-querying the node for sequence after every single transaction. Meanwhile, chainId is hardcoded to avoid repeated network requests. (Editor’s note: The loop count here is relatively low—clearly the author wasn’t being overly aggressive. Someone farming Conflux inscriptions once set the loop count to 1000 per cycle, sending around 200 unique transactions per minute.)
In the end, I had a rough Celestia farming script. On the night of December 17, shortly after CIAS disconnected the network, I did a quick test and sent out hundreds of transactions. Then, when CIAS resumed on the early morning of December 19, I successfully minted some CIAS (about 1,800). But there are still several things worth complaining about:
-
On December 17, Celestia’s RPC nodes suffered severe data desynchronization, with large discrepancies in block height across different nodes. When querying your account’s sequence from various nodes, you’d often get inconsistent results—an extremely frustrating experience. The Celestia block explorer also became unusable, leaving users mostly blind. You could say that although the Celestia network didn’t technically crash and blocks were still being produced, it was clearly nearing its breaking point.
-
That day, seeing Celestia struggling, the CIAS team abruptly announced that all inscription minting transactions submitted after block 48460 would be invalid—reminiscent of an exchange “pulling the plug.” To make matters worse, the CIAS website itself also crashed.
-
Some argue that the native consensus protocol of Cosmos chains performs poorly in block consensus—I won’t comment on that, but the CIAS team’s decision to pull the plug certainly raises questions.
-
On December 17, it was nearly impossible to find a fast-syncing node because almost all RPC nodes were overwhelmed and frequently unresponsive. I later attempted to write code to automatically switch between nodes.
-
The CIAS inscription format differs slightly from others—for example, in brc-20 JSON, all numbers are strings, whereas in cia-20, they’re actual numbers.
-
At peak times on that night, the cost of a single CIAS inscription surged to $1.5–2.0, with some users reportedly paying as much as $80 for one inscription. This high fee reflects severely limited TPS. The claim by Celestia’s founder that the network can handle 10k transactions per second appears to be pure nonsense.
Overall, the experience on the night of December 17 boils down to one sentence: Celestia clearly wasn’t prepared for large-scale traffic, and their RPC node configurations were shockingly inadequate (it’s hard to imagine dozens of RPC nodes getting taken down within just one hour).
By the evening of the 19th, things improved significantly—aside from the spike in gas fees, there weren’t major issues. So we can say that Celestia, as a data availability (DA) network designed specifically for distributing data to light nodes, temporarily passed the stress test. But who knows what other pitfalls may lie ahead.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
