SimpleAssets

document version 17 March 2021

Scope:

1. Introduction
   • Resources
   • Author RAM Payer
   • Token Types
2. Contract actions
3. Data Structures
4. EXAMPLES: how to use Simple Assets in smart contracts
5. AuthorReg
6. ChangeLog

---

Introduction

A simple standard for digital assets on EOSIO blockchains: Non-Fungible Tokens (NFTs), Fungible Tokens (FTs), and Non-Transferable Tokens (NTTs).
by CryptoLions

中文翻译: https://github.com/CryptoLions/SimpleAssets/blob/master/README_ZH.md
한국어 번역: https://github.com/CryptoLions/SimpleAssets/blob/master/README_KR.md
Español: https://github.com/CryptoLions/SimpleAssets/blob/master/README_ES.md

WARNING The minimum dependency on eosio.cdt is now v1.6.3.

---

Use Simple Assets by making calls to the Simple Assets contract. It's like a Dapp for Dapps.

Jungle Testnet: simpleassets

EOS: simpleassets
WAX: simpleassets
MEETONE: smplassets.m
TELOS: simpleassets
PROTON: simpleassets
EUROPECHAIN: simpleassets

Simple Assets is a separate contract which other Dapps can call to manage their digital assets. This serves as an additional guarantee to users of the Dapp that the ownership of assets is managed by a reputable outside authority, and that once created, the Dapp can only manage the asset's mdata. All the ownership-related functionality exists outside the game.

Related: understanding ownership authority.

To post information about your NFTs to third-party marketplaces, use the authorreg action.

Alternatively, dapps can Deploy their own copy of Simple Assets and make modifications to have greater control of functionality, however this may compromise compatibility with wallets and other EOSIO infrastructure. Before deploying, Simple Assets should be modified to prevent anyone from making assets.

---

Resources

web: http://simpleassets.io
Git: https://github.com/CryptoLions/SimpleAssets
Telegram: https://t.me/simpleassets

Intro & Demos: https://medium.com/@cryptolions/introducing-simple-assets-b4e17caafaa4

(important for developers) A detailed description of each action parameter can be found here:
https://github.com/CryptoLions/SimpleAssets/blob/master/include/SimpleAssets.hpp

Events Receiver Example for authors: https://github.com/CryptoLions/SimpleAssets-EventReceiverExample

---

Author RAM Payer

NFT authors can enable Author RAM Payer for some or all of their NFTs, and pay for all the RAM associated with transfers so that users don't have to.

Read more about Author RAM Payer

---

Token Types

Non-Fungible Tokens (FTs)

NFTs are the most common type of digital assets. They are used to express unique tokens.

NFT Structure

Simple Asset NFTs are divided into mdata (data which the author can update at any time, regardless of ownership), and idata (data which is set upon the NFT's creation and can never be updated).

Both are stringified JSONs. For example: {\"key1\":\"some-string\", \"key2\":5}

Category is an optional field that lets you group your NFTs for convenience. Category names must be less than or equal to 12 characters (a-z, 1-5).

Offer/Claim versus Transfer - If you transfer an NFT, the sender pays for RAM. As an alternative, you can simply offer the NFT, and the user claiming will pay for their RAM. (Note: We've deployed an Author RAM Payer feature that allows NFT authors to pay for all the RAM of their NFTs.)

RAM usage

RAM usage for NFTs depends on how much data is stored in the idata and mdata fields. If they both empty, each NFT takes up 276 bytes.

Each symbol in idata and mdata is +1 byte.

Fungible Tokens (FTs)

Dapps which need Fungible tokens should decide between using the standard eosio.token contract, and the Simple Assets contract. Here are the differences:

In Simple Assets,

• Scope is Author instead of Symbol
• Stat table includes also additional data about each FT (see Currency Stats below)
• For transfers you need to use transferf action from SA contract.
• If author sets authorcontrol flag, the author can transfers/burn/etc user's FTs independent of user's consent.
• The table which tracks FTs includes the author's account name, allowing different dapps to have FTs with the same name. (Example: https://bloks.io/contract?tab=Tables&table=accounts&account=simpleassets&scope=bohdanbohdan&limit=100)

(Note: Fungible Tokens also have offer/claim functionality as an alternative to transfers. For FTs, the only time the sender would pay for RAM would be if the receiver never before held those FTs. It uses approximately 300 bytes to create the FT table.)

Non-Transferrable Tokens (NTTs)

The two most likely use cases for NTTs are

• licenses which can be granted to an account, but not transfered.
• prizes and awards given to a particular account.

The reasons for using NTTs are:

• the NTTs appearing in third party asset explorers.
• some functionality is handled by Simple Assets.

More on NTTs: https://medium.com/@cryptolions/introducing-non-transferable-tokens-ntts-2f1a532bf170

---

Contract actions

A description of each parameter can be found here:
https://github.com/CryptoLions/SimpleAssets/blob/master/include/SimpleAssets.hpp

authorreg		( name author, string dappinfo, string fieldtypes, string priorityimg )
authorupdate		( name author, string dappinfo, string fieldtypes, string priorityimg )
setarampayer		( name author, name category, bool usearam ) 


 # -- For Non-Fungible Tokens (NFTs)---
 
 create			(author, category, owner, idata, mdata, requireсlaim)  
 update			(author, owner, assetid, mdata)  
 transfer		(from, to , [assetid1,..,assetidn], memo)  
 burn			(owner, [assetid1,..,assetidn], memo)  
 
 offer			(owner, newowner, [assetid1,..,assetidn], memo)  
 canceloffer		(owner, [assetid1,..,assetidn])  
 claim			(claimer, [assetid1,..,assetidn])  
  
 delegate		(owner, to, [assetid1,..,assetidn], period, redelegate, memo)  
 undelegate		(owner, [assetid1,..,assetidn])  
 delegatemore		(owner, assetid, period)  
 
 attach			(owner, assetidc, [assetid1,..,assetidn])
 detach			(owner, assetidc, [assetid1,..,assetidn])
 
 attachf		(owner, author, quantity, assetidc)
 detachf		(owner, author, quantity, assetidc)
 
 mdadd			(author, data)
 mdupdate		(id, author, data) 
 mdremove		(id)
 mdaddlog		(id, author, data)

 # -- For Fungible Tokens (FTs) ---
 
 createf		(author, maximum_supply, authorctrl, data)
 updatef		(author, sym, data)
 issuef			(to, author, quantity, memo)
 transferf		(from, to, author, quantity, memo)
 burnf			(from, author, quantity, memo)

 offerf			(owner, newowner, author, quantity, memo)
 cancelofferf		(owner, [ftofferid1,...,ftofferidn])
 claimf			(claimer, [ftofferid1,...,ftofferidn])

 openf			(owner, author, symbol, ram_payer)
 closef			(owner, author, symbol)
 
 # -- For Non-Transferable Tokens (NTTs) ---

 createntt		(author, category, owner, idata, mdata, requireсlaim)  
 updatentt		(author, owner, assetid, mdata)  
 burnntt		(owner, [assetid1,..,assetidn], memo)  
 claimntt		(claimer, [assetid1,..,assetidn])  

Data Structures

Assets

sasset {  
	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. Can be stringified JSON (recommended) 
					// or just sha256 string;  
	string		mdata;		// mutable assets data, added on creation or asset update by author. Can be  
					// stringified JSON (recommended) or just sha256 string;  
					// using a format other than stringified JSON will not interfere with 
					// simple asset functionality, but will harm compatibility with third party
					// explorers attempting to diplay the asset

	sasset[]	container;	// other NFTs attached to this asset
	account[]	containerf;	// FTs attached to this asset
}  

To help third party asset explorers, we recommend including the following fields in idata or mdata: name (text) img (url to image file)

Offers

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

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

        string  dappinfo;               // stringified JSON. Recommendations to include:
                                        // name - name of the application
                                        // company - name of the company
                                        // logo - url to image
                                        // url - url to the game's websites
                                        // info - short description of application
                                        // defaultfee - 100x the % fee you'd like to collect from marketplaces. (for 2%, 200)

        string  fieldtypes;             // data (json) schema to tell third-party markets how to display each NFT field.