Stardust Upgrade in a Nutshell

Custom Tokens and Smart Contract Anchoring on Layer 1

TL;DR:
The base functionality of every distributed ledger technology (DLT) is sending and receiving tokens. Most DLTs stick to this while enabling additional functionality in layers on top of them (L2, L3, and so on). Stardust is a protocol upgrade that turns the Shimmer and later the IOTA base layer (L1) into multi-asset ledgers, allowing anyone to mint their own tokens or NFTs on L1. It also enables the interaction of Layer 2 smart contract chains with L1, effectively turning the base layer into a trustless bridge between L2 smart contract networks. This article provides an overview of the most important aspects of the Stardust upgrade and is a shortened and simplified version of the detailed technical article introducing Stardust, which will be published tomorrow.

The Web3 revolution will rely on the scalable, frictionless, and secure interchange of digital assets, services, and goods. But how will that be possible? Buckle up as we summarize what awaits you with the launch of Stardust on Shimmer, IOTA's network for validating and hardening new innovations. Shimmer is where the latest features of highly scalable Web3 and DeFi applications will be deployed first. Let's start with why Stardust is necessary.

Why Stardust?

IOTA Smart Contracts, whether EVM-based or not, aren't executed directly on the L1 of IOTA or Shimmer. Instead, Web3 developers create their own blockchains and execute smart contracts in them, with each of those chains matching the capacity of the whole Ethereum network. Theoretically, there could be hundreds of these smart contract chains, allowing for as much capacity as builders need. All of them are anchored to Shimmer or IOTA, using a fraction of these networks’ capacity – just enough to anchor them by publishing information about smart contract executions, as well as the communication between each smart contract chain.

The upcoming Assembly network will enable the creation of such smart contract networks (also known as “utility chains”), all connected through the underlying Shimmer/IOTA networks. Assembly will thus enable the creation of a multi-chain environment, based and connected through a feeless, common L1 network. In other words: there will no longer be any need for costly and complicated “bridges” for smart contract chains to “talk” to each other.

But first, the base layer needs an upgrade, enabling smart contracts to interoperate and exchange value with each other, as well as feelessly mint, hold, manage, melt, and burn assets on L1. This is exactly what Stardust enables.

For IOTA Smart Contracts to be executed in blockchains that rely on and are connected through Shimmer and IOTA, the IOTA Tokenization framework comes into play, defining the tokenization specifications for the Stardust upgrade.

Key features of Stardust

The very first embodiment of Stardust, with its multi-asset ledger and smart contract capability, will be the upcoming Shimmer network. Once validated on Shimmer, the new feature set will be integrated into the IOTA network. The full details of what the Stardust upgrade will enable are available in the technical long read (published tomorrow), but here is a quick rundown of the most important features.

Data cap/byte cost: Before Stardust, the only thing that had to be stored in the ledger was the token balance. But as the ledger’s utility will increase with Stardust, so will the amount of data stored in the ledger. Because total storage space is a finite resource for any distributed ledger, Stardust will introduce a cap on data included in transactions. This cap can be extended with an increase in the number of tokens contained in the transaction.

Put simply, the more tokens attached to a transaction, the more data it will be allowed to contain. This way, the space used in the ledger can be fairly distributed while keeping IOTA and Shimmer feeless and guaranteeing that the ledger size does not grow uncontrollably, as in most blockchains. Instead, the maximum ledger size is limited by the number of tokens in existence. The feature that introduces limits on storing data indefinitely in the ledger, bound to the token value of transactions, is called “byte cost”.

Dust protection: Byte cost also creates yet another feature of the Stardust upgrade: it automatically prevents anyone from bloating the ledger by issuing spam transactions, all of which require space in the ledger. This feature is known as dust protection.

The big advantage with Stardust is that all data secured through a byte cost deposit will become part of the ledger state. This means, that, once propagated through the network, *all* nodes in the IOTA and Shimmer networks will save a copy of the data. The copy will be kept on all nodes and can be accessed from any node. It will not be automatically purged after a set length of time and therefore does not require a Chronicle permanode for a storage solution as in the current Chrysalis version of the IOTA network.

The byte cost is an opportunity cost, locking in tokens for as long as a user wants to retain and persist data in the ledger. When the data is no longer needed, it can be removed and the deposited tokens freed up and refunded to the user. No tokens are consumed, paid, or destroyed to retain data over extended periods - they are only locked into transactions as a deposit to prevent uncontrolled ledger bloat.

In essence, storing data for eternity comes at the price of locking tokens as long as the data persists in the ledger. Spamming and bloating the ledger would only be possible if the attacker is willing to pay for it.

Output unlock condition: The above-described form of dust protection opens up yet another major new feature of Stardust. If you transfer, say, a custom PizzaCoin token, you must send it along with enough native tokens (SMR or IOTA) to support its data storage in the ledger. So either the sender or the receiver needs to provide the native token deposit that enables the storage of the bits and bytes that comprise the PizzaCoin.

To facilitate this, Stardust introduces an output unlock condition: if the sender provides the required token deposit, they can define that the recipient has to release the deposit by replacing it with their own token deposit upon receipt of the PizzaCoin token. Once this is done, the token deposit of the sender is automatically returned.

The sender can also define the timeframe within which the receiver has to replace the sender’s deposit. If the receiver fails to act within the specified timeframe, the tokens or NFTs automatically bounce back to the sender.

The output unlock condition is particularly useful in cases where accepting transactions within a given time span is important. Picture an NFT auction, where multiple participants send their bids to an auction platform. If the bidders set the end of the auction as an unlock condition, all unsuccessful bids are automatically returned to the bidders after the auction ends. Only the winning bid is accepted by the auction platform, without needing to touch or accept the tokens of other bidders.

Another example occurs when interacting with a smart contract. When the sender sets an unlock condition, tokens sent to a smart contract are automatically returned if the smart contract doesn’t execute within the specified timeframe, e.g. if the conditions to execute are not met. In that case, the tokens sent to the smart contract don't change ownership but are simply “bounced back” to the sender. This is particularly useful in preventing tokens from getting lost due to defunct smart contracts. If the smart contract is broken, tokens sent to it could potentially be unreturned and stay in limbo forever, neither accepted nor returned. Setting an unlock condition prevents this, which makes it especially useful for DeFi applications.

IOTA’s biggest utility upgrade… ever!

At the moment, Stardust is being tested internally and the related software prepared, including Hornet nodes, the IOTA Smart Contract nodes, client and wallet libraries, the Firefly wallet, and additional tooling. Once preliminary versions are ready, Stardust will be deployed in the form of a public testnet, followed by the release as the Shimmer network.

By the time the Stardust features have been validated and reach the IOTA network, they will be a thoroughly tested upgrade, and both the infrastructure and user software will be ready.

Stardust contains many more improvements than listed here; it is in fact the biggest utility upgrade the IOTA ecosystem has ever witnessed so far. As a user, you will love the new Firefly version, which over time will feature support for tokenized assets, NFTs, and lots of community projects. If you are a developer delighted by the premise of more utility by an order of magnitude, the detailed Stardust introduction, released tomorrow, is for you.

We know that many of you have been eagerly awaiting more information and waiting to start building. We couldn’t be more curious to see what the community will come up with.

As always, if you have any questions, join us on our Discord in the shimmer-chat channel.