Introducing “Simple Assets” digital goods for Telos - By Crypto Lions
In the crypto space, there are already non-fungible digital assets. Perhaps the most famous is CryptoKitties. Standards for non-fungible tokens include the Ethereum Based ERC-721 token standard.
Simple Assets is a Digital Asset / NFT standard designed for developers in the EOSIO ecosystem.
The Simple Assets Standard
web: http://telos.simpleassets.io
Git: https://github.com/CryptoLions/SimpleAssets
Contract Actions
//basic author actionscreate (author, category, owner, idata, mdata, requireClaim) update (author, owner, assetID, mdata) //owner actionstransfer (from, to , assetID, memo) burn (owner, assetID, memo) offer (owner, newowner, assetID) canceloffer (owner, assetID) claim (claimer, assetID) //optional author registration for asset display recommendationsregauthor (name author, data, stemplate) authorupdate (author, data, stemplate) //for lending assetsdelegate (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, Telos 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.