Celatone

¶Overview

Celatone originated from an idea I had while working on Nebula Protocol back in 2022. It started as an internal tool for my team, which we later pivoted to focus on entirely.

I founded Alles Labs around that opportunity: developer infrastructure for Cosmos SDK chains. Celatone grew from the internal tool into a commercial explorer and smart contract interface used by five paying chains. Initia acquired Alles Labs in June 2024.

¶Adoption

Across all non-documentation Celatone Google Analytics properties, combined monthly active users peaked at 126,228 in January 2024. In May 2024, the final full month before acquisition, the product recorded 73,119 combined monthly active users.

These figures sum active users across deployed instances and do not deduplicate people who used more than one chain. I use the combined measure because each instance was a distinct customer deployment and product surface; the full 2022-2025 series is retained for the portfolio analysis rather than reducing the story to a single launch spike.

¶The Problem

The core motivation was simple. At that time, CosmWasm was gaining popularity due to the emergence of chains like Terra, Osmosis, Neutron, and others. However, developer tools were almost non-existent. Deploying and interacting with CosmWasm contracts meant using the chain's default, unergonomic daemon tool.

gaiad tx wasm...

And after deployment, you basically have no visibility into them: their state, usage patterns, or functions (called messages in CosmWasm). This is primarily because CosmWasm contracts do not have a standard, widely adopted schema file like Solidity's ABI, which means there is no easy method to introspect available messages. A JSON-Schema crate exists, but it has not been widely adopted beyond a few teams. They essentially become black boxes that you can only peek into using chain endpoints, scripts, or CLIs.

While there are useful tools like terrain and beaker (thanks to ibossptk for both <3), quickly viewing or testing a contract is still far more complicated than it should be. This is especially true for non-developers or end users who want to understand and inspect smart contracts.

¶Solution

Seeing this gap, we built Celatone. Initially, we planned for it to be more of a developer tool, something developers or power users would use alongside an existing block explorer. The MVP was a smart contract explorer where users could inspect a contract's initialization parameters, deployment details, and available messages in one place. From there, they could select a message and query or execute it directly in Celatone with their chosen parameters.

As users began utilizing the MVP on Osmosis, we observed a growing demand for traditional block explorer features. In response, we added pages for accounts, blocks, transactions, and more, along with custom pages for specific chains. Over time, this feedback and usage led Celatone to become the primary block explorer for networks such as Neutron, Sei, and Initia.

¶Key Highlights

¶Query & Execute Shortcuts

While CosmWasm contracts do not have a schema file like Solidity's ABI, we discovered that querying a contract with an intentionally invalid message returns an error that lists all valid query options.

Thus, we can simply make an invalid request, parse the error response, and show the output in the UI to achieve a similar result. We also found that we could take a similar approach when executing a contract, this time using the chain RPC's built-in simulation endpoint to achieve a similar result.

This gives us a similar result to the query shortcut, but for the ExecuteMsgs that the contract supports.

Once a user selects the message they want to query or execute, sending a message with an empty body will return the first required parameter for that function. In theory, we could recursively build the message object by parsing the error response and constructing the parameter object step by step. However, this approach has several downsides:

• Slow: The recursive method would be slow because each iteration requires a new network call.
• Incomplete: This approach does not expose any optional parameters that the user might want to set.
• Lacks Context: The user would only receive the parameter name without any context about the parameter type, description, or default values.

Ultimately, we concluded that this approach was impractical and decided to only perform the initial message list parsing.