Introducing “Simple Assets” (Alpha) digital goods for EOSIO blockchains

中文版 (Chinese Version)
Русская версия (Russian Version)

Simple Assets is a smart contract for the creation and function of digital assets (also called non-fungible tokens) on EOSIO blockchains. We are currently in the Alpha stage, deployed and available in the Jungle Testnet.

Simple Assets Demo

Basics: What is a Digital Asset (aka Non-Fungible Token)?

Most crypto assets which we think about are fungible. They can be interchanged and replaced. Bitcoin and EOS, like dollars, are fungible. It doesn’t matter which one you own, only the quantity.

By contrast, other goods, like theater tickets or deeds to property, are non-fungible. Every one is unique.

In video games, some assets, like in-game resources — wood, gold, vespene gas — are fungible, but some rare, high-level items, perhaps a legendary sword, or a vehicle can be non-fungible.

In the crypto space, there are already non-fungible digital assets. Perhaps the most famous are CryptoKitties. Standards for non-fungible tokens include the Ethereum Based ERC-721 token standard, and the WAX.io blockchain, which was created by the founders of OP Skins.

Simple Assets is a Digital Asset / NFT standard designed for developers in the EOSIO ecosystem.

The Simple Assets Standard

web: https://simpleassets.io
Git: https://github.com/CryptoLions/SimpleAssets

Contract Actions

//basic author actions
create          (author, category, owner, idata, mdata, requireClaim)  
update          (author, owner, assetID, mdata) 

//owner actions
transfer        (from, to , assetID, memo)  
burn            (owner, assetID, memo)  

offer           (owner, newowner, assetID)  
canceloffer     (owner, assetID)  
claim           (claimer, assetID)  

//optional author registration for asset display recommendations
regauthor       (name author, data, stemplate)  
authorupdate    (author, data, stemplate)  

//for lending assets
delegate        (owner, to, assetID)  
undelegate      (owner, from, assetID)

Data Structures

Assets

Most asset information going into the stringified json fields idata and mdata. idata stands for immutable data. It cannot be changed. mdata stands for mutable data, and consists of the fields which the author of the asset can update.

assets {  
   uint64_t id,   // asset id used for transfer and search  
   name owner,    // asset owner (mutable - by owner!!!)  
   name author,   // asset author (game contract, immutable)  
   name category, // asset category, chosen by author immutable  
   string idata,  // immutable assets data
   string mdata	  // mutable assets data, added on creation or asset update by author  
}
// Please include in idata or mdata info about asset name img desc which will be used by Markets

Offers

As an alternative to transferring assets to a new owner, which would allocate the current owner’s memory, users can offer the asset to a new owner and then allow them to claim it. This allocates the recipient’s memory.

offers {  
	uint64_t assetID, 	// asset id offered for claim  
	name owner,  		// asset owner  
	name offeredTo,		// who can claim this asset  
	uint64_t cdate		// offer create date  
}

Authors

Use of the regauthor action which populates this table is optional, but asset creators can choose to post information about themselves and make recommendations how their assets should be displayed.

Wallets, Market Places, and other Asset Explorers then have the option of abiding by the recommendations of the author or not.

authors {  
   name author, // assets author, who will be able to 
                // create and update assets  

   string data,	// author’s data (json) will be used by 
                // markets for better display  

   string stemplate // data (json) schema for markets.
                    // key: state values, where key is key from  

        	   // recommendations for non-text fields: 
                   // url, img, webgl, mp3, video, hide
}

Delegates

This simple table keeps track of lent and borrowed assets. Lending an asset through the delegate action will in fact change the asset’s owner field, but it will create an entry in the delegates table, and certain functionality, like transferring or burning the asset, will be blocked until the asset is returned to the owner who lent it out.

delegates{  
	uint64_t assetID, 	// asset id offered for claim  
	name owner,  		// asset owner  
	name delegatedto,	// who can claim this asset  
	uint64_t cdate		// offer create date  
}

Here is a discussion of these actions and structures.

Key Decision on which we’d love some feedback:

* Basic architecture. We have mutable as well as non-mutable data in the asset. It seems like some other assets only have immutable data, and store the mutable portion inside of their game or application.

* We are NOT indexing on the category field of the asset table. An index would add 128 bytes to each row of the table. So assets are smaller, but finding them is a little bit of extra work. (We decided to take a middle road here. The extremely compact way to implement Simple Assets would have been to put category inside of the stringified json field, idata.)

* Owners (ie, EOS account holders) and NOT the author of the asset have 100% control over transfers, lending/borrowing and burning. The alternative would have been to hook certain functionality through the author, allowing them to blacklist/whitelist recipients of their assets. One consequence of this decision is that games cannot create exclusive marketplaces for their assets. If Simple Assets is used, the asset’s ownership is expressed entirely outside the game or other asset application. Is this the right approach?

* Similarly, we removed functionality which would allow an author to pause or stop transfers of their assets.

* Right now, undelegating an asset (ie. an owner taking back an asset which has been lent) happens instantly. We are considering adding a delay to mitigate against potential trolling, which may come in the form an owner taking back their asset as a critical moment in a game. What would be a good delay?

Should we add an Owner’s memo?

* Lastly and MOST IMPORTANTLY, we’ve tentatively decided against an owner’s memo field in the asset to which the owner can write, though the idea continues to intrigue us. Certainly, any game or asset application can create logic by which owners can add a memo to the mdata field, but we thought of providing a field that allows direct interaction with the asset owner, independent of the author. One use case might be to allow owner to write a note which would be displayed in market places where the asset is being sold, however market places could create this functionality too outside the simple asset protocol. We decided to save RAM and not include this field, but we’re still debating it. Perhaps an owner memo field might allow some sort of dynamic skins functionality, where a game might query the owner-memo and display the asset accordingly.

We’d love to know what you think. Please hop into our telegram channel and let us know your thoughts: https://t.me/CryptoLions_io .

A Simple Marketplace for Simple Assets

We’ve deployed a simple Marketplace that integrates with Simple Assets. It’s very basic without any auction functionality.

Anybody can build a marketplace on Simple Assets.

One idea we have to request asset authors specify their desired % of every sale when they regauthor / authorupdate, and then marketplaces have the option of sending this percentage as a courtesy to the author. But as discussed earlier, we decided to give owners 100% control over transfers of ownership, so observing this recommendation would be optional.

Create your own asset today!

Note: These instructions are dated. Please see our github for the latest standards and examples.

1. If you haven’t already, create an account in the jungle testnet, and connect Scatter:

2. Using CLEOS, send a create action to the Alpha Version of the contract, which is called simpl1assets.

create (author, category, owner, idata, mdata, requireClaim)

Example:

asset='{"author": "youreosaccount",
        "category": "weapon",
        "owner": "recipientaccount",
        "idata": "{\"power\": 10, \"speed\": 2.2, \"name\": \"Magic Sword\" }",
        "mdata": "{\"color\": \"bluegold\", \"level\": 3, \"stamina\": 5, \"img\": \"https://bit.ly/2MYh8EA\" }",
        "requireClaim" : 0
       }'

./cleos.sh push action simpl1assets create "$asset" -p youreosaccount

3. Go to alpha.simplemarket.io and sign in with Scatter to see your assets, sell them, or buy assets created by others.

Kolobok! A simple game using Simple Assets.

We’ve deployed a simple game in the Jungle Testnet which demonstrates all the basic functionality of Simple Assets.

http://jungle.kolobok.cryptolions.io

Simple Assets Governance

On the Mainnet, CryptoLions plans to curate Simple Assets through it launch and initial testing, and then create a DAC which controls the smart contract and makes decisions on further development. Other blockchains are welcome to deploy Simple Assets under their own standards of governance. It is completely free and open source.

Should Simple Assets find a user base, one likely additional feature will be building and deploying inter-blockchain communication for assets.

Comparing Simple Assets to dGoods v0.1

We were fairly deep into Simple Assets when we heard Mythical Games was developing dGoods. We think they’re going to be major players in the EOS gaming scene, and we hold their work and their opinions in high regard. They announced an early version of their standard last week: Digital Goods Token Spec v0.1, and asked for community feedback.

The important similarity between dGoods and Simple Assets, is a common philosophical approach and purpose. Both strive to be completely free and open source standards for digital assets on EOS.

Key design differences are discussed here:

Closing

Please let us know what you think by joining our Telegram channel.

https://simpleassets.io/

???

CryptoLions is an EOS Block Producer based in Ukraine. We strive to make EOS more valuable by building projects that improve the ecosystem, by setting the standard for transparency and accountability, and by popularizing EOS all over the world.

website: http://cryptolions.io/
github: https://github.com/CryptoLions
telegram: https://t.me/CryptoLions_io
steemit: https://steemit.com/@cryptolions
twitter: https://twitter.com/EOS_CryptoLions
medium: https://medium.com/@cryptolions/
youtube: https://www.youtube.com/channel/UCB7F-KO0mmZ1yVBCq0_1gtA

Russian/Ukrainian:
steemit: https://steemit.com/@cryptolions-ua
youtube: https://www.youtube.com/channel/UCnVu47FZ09XX9EvrqqgS6uQ
twitter: https://twitter.com/EOSnews_ru