This article was originally published on Delphi Digital by Delphi Labs and Red Phone on Earth Date Jan. 18, 2024. It's now been irrevocably inscribed for posterity on Asteroid Protocol.
Summary: Delphi Labs and Astroport contributors have unleashed a new inscriptions metaprotocol on Cosmos Hub — a blockchain that, by design, has no native support for NFTs or fungible tokens.
Yesterday evening around 9 p.m. UTC, Delphi Labs and Astroport released an open source metaprotocol for inscriptions on Cosmos Hub. The world’s largest Cosmos blockchain by market cap, the Hub has no native support for fungible tokens or NFTs by design.
Asteroids change that.
Now anyone can embed content directly on the Hub – including a new form of tokens: Cosmos Fungible Tokens or CFT-20s. The Cosmos community was galvanized.
“Honestly, the Asteroid protocol is probably the most exciting development on Cosmos Hub since IBC,” popular Cosmos influencer John Galt wrote of the launch. “It’s that big. The Hub may have finally found its purpose – a minimalistic, highly secure data storage chain for the Cosmos ecosystem.”
To understand the protocol, let’s first look at the rise of inscriptions on bitcoin.
Launched by Casey Rodarmor in January of 2023, bitcoin ordinals allowed anyone to publish or “inscribe” data directly into the 500+ gb file that makes up the bitcoin blockchain. Controversial and irreverent, artists, techies and devs raced to push JPGs onto the blockchain.
Every piece of content uploaded to the blockchain received an “inscription number.” That means the first ordinal – a skull inscribed by Rodarmor himself – was Inscription #0. The second was Inscription #1 and so on.
By Feb. 1, 2023, there were 679 inscriptions in existence. Just one month later, there were 243,419.
Around that time, Delphi Labs contributor Redphone, published a tweet proposing a way to inscribe fungible tokens onto Bitcoin using .json files. He dubbed the idea BRC-20s.
A few days later, another anon, Domo, formalized the concept into a specification and deployed the first token, ORDI, directly on top of bitcoin.
Sheer madness ensued. And BRC-20s became the leading use-case on ordinals.
Today, there are more than 60,000 tokens on top of bitcoin with a combined market cap in the billions of dollars. ORDI alone has a market capitalization of $1.5 billion and trades on more than 20 centralized exchanges including Binance and OKX.
Every time a token is deployed, minted or transferred on-chain, a new inscription is created. That helped send inscriptions parabolic.
All told, there are now more than 55 million bitcoin inscriptions in the world. And the concept has set off a flurry of development, not just on bitcoin but throughout the entire crypto ecosystem. Inscriptions are also rapidly propagating across every major L1 blockchain (Ethereum, Solana, Dogecoin, Litecoin and more) and even non-blockchain-based publishing platforms like X (formerly Twitter).
While much of the activity is speculative in nature, we believe there’s profound technological innovation here. Unlike NFTs, which often point to off-chain data stored on Filecoin, IPFS, Arweave or even centralized databases, inscriptions live entirely on-chain. In that way, inscriptions treat blockchains as permissionless, immutable databases.
In other words, inscriptions give anyone the ability to permanently write data to a blockchain and be assured that that data will live on that blockchain for as long as it exists.
As we’ve thought about and explored the inscriptions model over recent months, we’ve come to view them as a bridge between the worlds of web2 and web3.
Before inscriptions, developers had to have familiarity with smart contracting languages and web3 dev tooling. With the rise of inscriptions, even web2 devs can leverage the benefits of blockchains to build web3 applications without writing a single line of smart contract code. They can simply read in data that’s written directly on-chain.
It represents a seachange for crypto, and a massive opportunity to enhance functionality on Cosmos Hub and grow fee income for validators and their ATOM stakers. The world’s largest Cosmos blockchain by market cap, the Hub currently lacks support for native tokens and smart contracts by design. Asteroids introduce that functionality in a way that’s accessible to anyone – including end users and web2 devs.
Let’s look at how it works.
Hurtling through the galaxy at speeds of 250,000 kph+, asteroids leave indelible marks on the planets unfortunate enough to stand in their paths. They resculpt the very surface and leave traces of their impact for as long as a planet exists.
Cosmos Asteroids have a similar effect. With them, anyone can permanently write data to Cosmos Hub (and potentially other Cosmos SDK blockchains), and that data will live on for as long as the blockchain exists.
The Asteroid Protocol is a generalized metaprotocol framework. That means anyone can use it to create their own protocols on top of Asteroids. To date, contributors have already defined two key types of Asteroid metaprotocols:
Let’s look at how both types work.
The Cosmos Inscriptions Specification details a way to inscribe arbitrary data onto a Cosmos SDK blockchain. Inscribing data onto the chain ensures it will live on for as long as the chain is running.
The design takes inspiration from the rather clever ordinals implementation on bitcoin, which uses data pushes within unexecuted taproot conditionals, called “envelopes.” This “backdoor” approach enables users to write data directly to the bitcoin blockchain.
The Cosmos SDK differs in a big way from other blockchain implementations in that messages are validated, and rarely do you find any part of a transaction that isn’t strictly controlled by some definition. This is generally good and avoids a lot of mistakes, however, it also makes it harder to put arbitrary data in a transaction.
One of the fields that are somewhat suited for inscriptions is the “memo” field. The memo field is used in transfers to centralized exchanges as well with IBC-Hooks. The memo field is very limited though, with a maximum length of 512 characters on Cosmos Hub. There was an attempt on the Cosmos Hub forum to increase the size of the field, but it doesn’t seem a proposal was put to a vote on this.
There is another section of a transaction that allows arbitrary data to be added as long as you conform to the message type built into the chain. This section is non_critical_extension_options (NCXO).
From the SDK documentation:
extension_options are arbitrary options that can be added by chains when the default options are not sufficient. If any of these are present and can’t be handled, they will be ignored
The final part of the description is key: “If any of these are present and can’t be handled, they will be ignored.” This leaves a path for adding content that is not validated past the protocol buffer type. As long as you use a type known to the chain, it can be used. An example is the sending of tokens below using the /cosmos.bank.v1beta1.MsgSend type:
{
"@type": "/cosmos.bank.v1beta1.MsgSend",
"from_address": "cosmos1fkwcez7yzjz2gpzhesdsd3r5wp0w82cftr4k95",
"to_address": "cosmos198tjtk9rzwzwcce6r8uu2gj950p9gqakm6jz92",
"amount": [
{
"denom": "uatom",
"amount": "1"
}
]
}
In this example, the field names are validated, but the content of the fields are not. This is expected as this specific option isn’t handled and thus ignored. Indeed, none of the tests we attempted generated errors. One of the caveats of this approach, however, is that SIGN_MODE_DIRECT is required, which means this will not work with Ledger devices.
MsgSend is not really well suited for what we want to achieve, and we feel that /cosmos.authz.v1beta1.MsgRevoke is better suited. It has the following structure:
{
"@type": "/cosmos.authz.v1beta1.MsgRevoke",
"granter": "cosmos1fkwcez7yzjz2gpzhesdsd3r5wp0w82cftr4k95",
"grantee": "cosmos198tjtk9rzwzwcce6r8uu2gj950p9gqakm6jz92",
"msg_type_url": "/cosmos.bank.v1beta1.MsgSend"
}
With a bit of creativity, that means we can:
That gives us:
{
"@type": "/cosmos.authz.v1beta1.MsgRevoke",
"granter": "{\"name\": \"My inscribed image\"}",
"grantee": "IHNobGRrIGxoc..gbDtkaGE=",
"msg_type_url": "image/png"
}
With each field is defined as follows:
Field | Description |
---|---|
@type |
The protobuf type that the chain recognises, but doesn't validate |
msg_type_url |
Can be anything |
granter |
base64 encoded metadata about the content |
grantee |
The actual base64 encoded content. All content is to be base64 encoded |
We use the MsgRevoke here as no-op, and it is ignored by the chain when part of non_critical_extension_options. In any case, the content is invalid and the chain would reject the message if it was ever implemented as part of non_critical_extension_options since Asteroids rely on the content not being validated.
Note that Asteroids rely on public RPC nodes for submitting transactions and indexing inscriptions and tokens. If those nodes go offline, transactions could fail and/or be delayed. In the event of a delay, Asteroid indexers could temporarily report stale/inaccurate information. Use caution when interacting with Asteroids during periods of network congestion and/or offline RPC nodes.
The CFT-20 token standard describes how to create, mint and transfer fungible tokens using the Asteroid metaprotocol framework. It is derived from the initial BRC-20 idea from Red Phone and the final implementation from Domo.
However, CFT-20s differ in implementation, taking an approach inspired by Casey Rodarmor’s RUNES protocol, which is under development, as well as the nascent CBRC-20 protocol. This helps differentiate Asteroids from COSS, which is a pre-existing token standard on Cosmos (one that implements a BRC-20 approach on the Hub and does not support NFTs).
The CFT-20 standard is implemented using the Asteroid metaprocotol framework. It relies only on the URN in the memo field with the exception of an optional logo that may be specified when creating a token that uses Asteroid inscriptions.
To create a CFT-20 token, use the following URN:
urn:cft20:{chain-id}@{version};{operation}${param}={value},{param}={value}
The operation values are:
Key | Value | Description |
---|---|---|
chain-id | cosmoshub-4 | The chain ID for the Cosmos Hub |
version | v1 | The current version |
operation | deploy | Deploy a new token |
The required parameters are:
Param | Description | Restrictions |
---|---|---|
nam | The name of the token | Must be 3-32 characters |
tic | The token ticker, must be unique across all tokens on the same chain-id | Must be 3-5 characters |
sup | The max supply of the token | Must be less than uint32 max |
dec | The decimals for the token | Must be between 0 and 6 (inclusive) |
lim | The maximum tokens that can be minted per transaction | Must be less than maximum supply |
opn | The Unix timestamp which after minting becomes possible | Must be a Unix timestamp in seconds |
To mint a token, anyone can use the following URN:
urn:cft20:{chain-id}@{version};{operation}${param}={value},{param}={value}
The operation values are:
Key | Value | Description |
---|---|---|
chain-id | cosmoshub-4 | The chain ID for the Cosmos Hub |
version | v1 | The current version |
operation | mint | Mint the specified amount to the sender's wallet |
The required parameters are:
Param | Description | Restrictions |
---|---|---|
tic | The token ticker, must be unique across all tokens on the same chain-id | Must be 3-5 characters |
amt | The amount to mint | Must be less than or equal to the token's lim parameter |
To transfer a token, anyone can use the following URN:
urn:cft20:{chain-id}@{version};{operation}${param}={value},{param}={value}
The operation values are:
Key | Value | Description |
---|---|---|
chain-id | cosmoshub-4 | The chain ID for the Cosmos Hub |
version | v1 | The current version |
operation | transfer | Transfer the specified amount to the destination address |
The required parameters are:
Param | Description | Restrictions |
---|---|---|
tic | The token ticker, must be unique across all tokens on the same chain-id | Must be 3-5 characters |
amt | The amount to transfer | Must be less or equal to the sender's balance |
dst | The address to transfer to | Any address on the chain-id, the address is not validated |
Beyond OTC-based swaps, trading tokens is not currently possible. However, we’re actively exploring possibilities to enable it.
Asteroids launched on January 16 around 4 p.m. UTC. Since then, there have already been more than 500 distinct tokens created and 5,000+ pieces of artwork, HTML or text inscribed.
Cosmos Hub, which was processing around 3 transactions per 6-second block before Asteroids, suddenly had blocks with 1,000+ transactions.
That fervor was driven in part by the protocol’s simplicity. With a little bit of ATOM in Keplr, anyone can visit asteroidprotocol.io to inscribe artwork, deploy new tokens or mint pre-existing tokens that haven’t yet been minted out with a few mouse clicks.
Each CFT-20 token that goes live launches as a “free mint.” The deployer can create a token by giving it a graphical logo, name and ticker. They can then set the token’s total supply and a “mint limit” – the maximum number of tokens any one person can mint in a single transaction. To ensure mints are free and open, the mint limit must be 1% or less of the total supply.
To test the protocol, contributors deployed the first CFT-20, an experimental token dubbed Asteroids (ROIDS). With a maximum supply of 100 million tokens, anyone could mint up to 1,000 ROIDS tokens at a time. That means it required at least 100,000 transactions to mint out the total supply (100 million tokens / 1,000 per mint). We expected that process to take several days. Instead, ROIDS minted out within hours.
Contributors plan to re-enable a secondary marketplace for CFT-20s at asteroidprotocol.io soon. Note, though, that the protocol is highly experimental and unaudited. Any secondary trading should be considered extremely risky.
We’re excited by the prospects, though – particularly with the potential synergies between Asteroids and Astroport, the leading AMM on every Cosmos chain where it’s currently deployed (Neutron, Injective, Sei and Terra).
While usage of the Asteroids protocol is fee-free, we have introduced a small (2%) trading fee on the marketplace at asteroidprotocol.io. With each trade, that small fee will be IBC’d to Terra, swapped for $ASTRO and deposited into the $xASTRO staking pool.
It’s a powerful new way to align Astroport contributors with a new ecosystem (Cosmos Hub) and ensure contributors remain incentivized to innovate on Asteroids.
We believe inscriptions are here to stay. And yet, it’s still difficult to swap inscribed tokens with DeFi. That’s because inscribed tokens are invisible to smart contracts and tracked instead by indexers, which only have visibility to on-chain transactions after they’ve been confirmed.
Astroport hopes to change that. Indeed, we’ve sketched out plans to launch a two-way bridge for Asteroid Protocol. This would allow users to migrate CFT-20s from the Hub to another IBC-enabled smart contract chain where they could be deposited directly into Astroport liquidity pools.
Its Cosmic transmutation… users could hypothetically input a CFT-20 on one side of the bridge and receive a token factory equivalent on the other side (or vice versa). Note, though, there is no guarantee that this bridge will be created. It’s purely theoretical right now, but we believe it’s possible, and that could further expand the power of Cosmos Hub.
“(Asteroids) is great example of Chain Abstraction and building apps that abstract over both the hub and neutron,” Zaki Manian – one of the architects who helped complete IBC – wrote on Twitter.
We look forward to seeing how the community utilizes Asteroids. Explore it now and mint your own Asteroids at asteroidprotocol.io.
Remember, Asteroid Protocol is open source, but it’s radically experimental and unaudited! Use at your own risk, and DO NOT consider it an investment. Follow the protocol’s progress on Twitter @Asteroidxyz.