Since the CryptoKitties craze started in November 2017, the Non Fungible Token (NFTs) ecosystem has evolved from mostly being tech demos into a thriving market. Especially on the Ethereum blockchain, million dollars worth of NFTs are being traded every month, with some assets reaching sale prices of $10,000 or more.
But when we decided to build an NFT based game of our own for the Eosio ecosystem, we quickly realized that the existing asset standards simply wouldn’t work for us. After some consideration, we decided to take things in our hands:
Today, we’re proud to announce the AtomicAssets standard!
The problems we solve
The two main asset standards in use today are SimpleAssets and dGoods. They were both developed more or less simultaneously around one year ago, as the first of their kind in the Eosio space. They were also both published under an open source license without any expectations of monetary gain, which we highly respect, and the contributions that they made provided the basis for AtomicAssets.
That being said, both of these standards have issues that we believe make them less than ideal for more complex dapps. In the next segment, we will take a look at AtomicAsset’s key features, and how these compare to SimpleAssets and dGoods.
We found it important to go a little more in depth in this article.
If all you’re looking for is a short list of our core features and our roadmap, you can go directly to atomicassets.io
RAM Efficiency
Perhaps the biggest advantage that AtomicAssets offers is the RAM efficiency. Our assets are designed to take up as little RAM as possible (without giving up usability).
This starts with the fixed costs for a “blank” asset, which we made sure to keep as low as possible:
- AtomicAssets: 151 Bytes per asset and 112 Bytes per owner
- SimpleAssets: 276 Bytes per asset and 112 Bytes per owner
- dGoods: 269 Bytes per asset and 0 Bytes per owner
It continues with the way data is stored. Both SimpleAssets and dGoods store the asset’s data as JSON strings, which is a simple and human readable way to do it, but it’s very inefficient. Just consider the following very simple format:
{"id": 100, "name": "Tom"}That’s 26 Bytes worth of characters to store an integer and a string of length 3. AtomicAssets on the other hand uses a custom data serialization, inspired by Google’s Protobuf. Before creating your assets, you create a scheme that defines the type of data that you want your assets to contain, so for example:
name: "id", type: "uint64"
name: "name", type: "string"Storing the same data like in the JSON string with this scheme would result in the following byte array (in hex):
[04 64 05 03 54 6F 6D]Without going into too much detail, the same data that was 26 Bytes as a JSON string can now be stored as 6 Bytes. That is made possible firstly because the attribute names don’t have to be redefined for every asset, and secondly because integers are stored as Varints, which means that smaller integers take up less space.
If you’re interested in how the serialization works, check out the docs.
We estimate that our custom serialization will save between 30-70% for the majority of assets compared to JSON strings.
We also introduced a new concept called Presets. In practice, a lot of assets will be very similar to one another. Imagine a Pokémon like game, where each creature is an asset. There might be thousands of Pikachus, each with a different level and a different set of skills, but also each sharing the same name, image and type. These common attributes would traditionally still be saved for each asset individually.
With Presets however, it is possible to group similar assets together and thus only store the common data once. So building on the Pokémon themed example above, you could create a Pikachu preset, where you store all the data that all Pikachus share.
Each Pikachu asset would reference this preset and then only have to store the data unique to it, potentially saving hundreds of kilobytes of RAM.
We estimate that the presets mechanic will save up to 70% more RAM, depending on how many attributes assets share.
At the time of writing this, RAM prices on EOS are at ~$0.30 per kB. Dapps simply can’t afford to be wasteful with their RAM in an environment like this. On other eosio chains like WAX, this currently is less of a problem, because RAM is still relatively cheap. But that’s only a temporary circumstance, not a solution, and the problem will still catch up to dapp developers as these chains continue to grow and as RAM becomes more scarce.
No RAM costs for users
The RAM for all the assets created with AtomicAssets are paid by the creator, and that never changes. This solves two crucial problems:
Firstly, if the only ones using assets are blockchain enthusiasts, you might get away with having them pay for the RAM of their assets. But that doesn’t work if you are aiming to build dapps that tap into the mainstream market. Users have grown to expect that the websites and apps they interact with work seamlessly. If your average, non-techy user now has to first figure out what RAM even is and how to get more before being able to interact with assets, you might as well wave mass adoption goodbye.
Secondly, 3rd party smart contracts that interact with the assets aren’t at risk of having their RAM drained by malicious users.
A good example of what that means in practice is the simplemarket contract, a decentralized exchange built for the SimpleAsset standard. To sell an asset there, the seller transfers his asset to the simplemarket contract, and after the asset is bought, the contract sends an offer to the buyer. This is done in an effort to have the buyer pay for the RAM after he accepts the offer.
But what happens if the buyer just doesn’t accept this offer? Then the simplemarket contract would be stuck with paying the RAM for this offer. Attackers could use this to completely drain the contract’s RAM resources and thus block the contract. With SimpleAssets, there simply is no way to solve this. With AtomicAssets, this isn’t even something that developers have to worry about.
As mentioned above, SimpleAssets does not have a fixed RAM payer for each asset. Instead, after each transfer, either the sender of the recipient pay for the RAM, depending on the actions used. dGoods also always lets the creator for the RAM.
Notifications for Smart Contracts
This is another thing that we believe to be essential for more advanced dapps, especially games. Collection authors will be able to specify accounts that should receive notifications for all relevant actions related to this collection. They will then be notified of a total of 7 different actions, including asset transfers and burns directly on the blockchain using the require_recipient() function. Because the accounts are 100% guaranteed to receive these notifications, dapps can become a lot more dynamic.
For example, imagine a game where each player runs a goal mine, and some assets might give the players bonuses on their production. Because the game contract is guaranteed to receive a notification when this asset is transferred, it can then automatically adjust the production of the previous and new owners.
And this is just a very basic example. The notifications are what will allow game assets to turn from static commodities to dynamic elements with a direct impact on the game world they are a part of.
dGoods doesn’t offer any kind of notifications, and while SimpleAssets does have notifications, they are sent as deferred transactions instead of using require_recipient(). And since deferred transactions don’t offer any guarantees of executing, dapps can’t rely on receiving these notifications and can therefore not build their internal logic on top of them without risking bugs to occur.
It also has to be mentioned that using these require_recipient() notifications, asset creators will be able to make any transactions transferring their assets fail. This doesn’t have to automatically be a bad thing, and there are ways to use this in ways that will benefit the asset collection as a whole.
However, if that’s not something you want to have in your collection, it is possible to set the allow_notify parameter to false when creating the collection, completely disabling notifications.
Two more features
The features we looked at in the section above are what we believe to be absolutely essential for the success of dapps built on top of AtomicAssets. But there are two more features that, although not essential to the core functionality, will allow for for new use cases and a better overall user experience:
Powerful Trade Offers
AtomicAssets features a native implementation of two sided trade offers (similar to Steam or WAX Express Trade). This allows creating and accepting offers with a single action. And this not only is cool for users that can send trade offers the way they are already used to, but it also enables developers to build things like marketplaces that don’t require transferring ownership to the marketplace contract.
Backing assets with Core Tokens
Assets can be backed by the respective core token of their network (e.g. EOS/ WAX). Those tokens can only be freed by burning the asset, thus allowing dapps to give their asset a guaranteed intrinsic value.
We believe that this will enable dapps to build innovative ideas on top of this feature.
The AtomicAssets roadmap
As of the time of publishing this article, the AtomicAssets smart contract is already feature complete and deployed under that “atomicassets” account on the WAX Testnet. We still classify it as a beta version, because we want to do some more testing to make sure that if there are any bugs in the code, we find them before going to version 1.0, and we would also like to still take in any feedback that you might have for us. The contract is open source and available on GitHub here. It also already is well documented.
On top of that, a npm library is already available. It offers easy access to everything within the AtomicAssets contract and also automatically deserializes the asset’s data.
But there’s a lot more to come!
We’re confident that the standard we have created can be a real game changer for NFTs in the eosio ecosystem, and we have ambitious plans for AtomicAssets moving forward. In the coming months, we will be working hard on getting all the tools ready needed for AtomicAssets to become both as user-friendly and as developer-friendly as possible.
Explorer API
We will create an explorer API that will take a little more effort to setup, but then offer more extensive, high-performance queries. We will both release the code under an open source license and also host a public API for easy access.
NFT Creator
With the Explorer API forming our backend, we plan to then build an NFT Creator website where users will be able to create their own assets. We will give them full control over schemes, collections, presets and assets (what’s that?) and provide a simple and intuitive interface.
Trading Interface
One of the features AtomicAssets offers are two sided trade offers. We will build an interface for this functionality, that will allow users to send trade offers to anyone they want, and accept/ decline the offers that they receive.
Marketplace
One of the biggest milestones we’re aiming to reach is to get a marketplace site up and running. On there, users can put their assets for sale, browse assets and buy the assets that are up for sale.
Crucially, we will also offer an API for 3rd party developers that want to integrate our marketplace directly into their dapps, thus also getting access to the liquidity of the market.
Games developed by pink.network
As we stated at the very beginning of the article, the very reason why we first started working on a new NFT standard is because we wanted to develop NFT based games. And once we’re done with creating all the infrastructure for AtomicAssets, we will be able to get back to developing these games.
The first game we have planned will be relatively small in scope, but it is important to us that it won’t just become another tech demo, but a proper game that will be fun to play.
We will use this game as an opportunity for both us and the players to get familiar with how the game flow works with AtomicAssets and the tools surrounding it.
For the mid to long term, we also have plans for bigger games. We don’t want to promise too much right now, but we have very high ambitions and plan to make full use of the opportunities that AtomicAssets has opened up.
That’s it.
We’ve taken a look at the problems that existing asset standards have, how AtomicAssets addresses them, and how it compares with SimpleAssets and dGoods in particular. We’ve also outlined the additional features that AtomicAssets offers, what already is available right now and what we will be working on next.
If you’ve made it this far: Thank you! We are very passionate about this project and are proud of what we have already achieved.
And we’re committed to work hard to turn AtomicAssets into what we know it has the potential to become.
If you want to walk down this road together with us, please join our Telegram group (t.me/atomicassets). There, you will always get all the latest updates and be able to talk directly to the team about anything that interests you.
And especially if you are a developer and you are considering building your dapp on top of AtomicAssets; Get in touch with us! We are very happy to discuss how your dapps could be implemented and also to assist you directly.
And as a small token of appreciation for all those that were there from the beginning, when we move from the beta to 1.0, we will be giving out special assets to all those that joined the Telegram channel before.
We’re not sure what exactly these assets will be, but we promise to do something cool.
If you haven’t already, feel free to also check out our website, atomicassets.io and follow us on Twitter @pinknetworkx.
