dGoods is an open source and free standard for handling the virtual representation of items, both digital and physical, on the EOS blockchain led by Mythical Games. Fungible and non-fungible tokens are represented in this standard, as well as what we term semi-fungible tokens. These are nft's that share many properties but have at minimum a unique serial number. Things like tickets, luxury goods, or even fractionalized ownership are well suited to this classification and therefore, a major focus of this standard.
Three most important properties of dGoods which differentiate from other token standards
1) hierarchical naming structure of category:name for each token or set of tokens, enabling filtering and organization of tokens
2) focus on semi-fungible tokens -- that is, tokens that are 1 of n with a serial number or slightly different metadata
3) opensource metadata types and standardization for each type with localization, eg 3dGameAsset
, Ticket
, etc
Instead of a sale lasting a default of one week, it is now configurable and exposed as a parameter
in listsalenft
.
sell_by_days
is 0, sale is treated as indefinitesell_by_days
> 0, the sale will be valid for sell_by_days
number of daysNote that a sale will still need to be closed after expiration has passed. This can be done by
anyone if the sale is expired by calling closesalenft
.
The main feature added in v1.1 is the ability to mint tokens in a time limited fashion instead of
supply limited. To do this, one sets the available window time in days and sets max_supply
to 0.
This enables tokens to be minted until the window has elapsed. Once the window has elapsed, or if
the contract owner wants to end it early the freezemaxsup()
action may be called. This will set
the window time to 0 and the current supply will become the max supply, ensuring no more tokens may
be minted. To mint as before, just set max_issue_days
to 0 in the create
call. Alternatively,
one may set both a max issue time and max supply.
available_primary_key()
)Many changes have occured since v0.4 that made it into the 1.0 release. Some of these changes are not backwards compatible since changes were made to multiple tables' structure. It is recommended to start from a fresh contract rather than try and migrate data to the new version.
We have a basic usage tutorial
General
issue
function made batchAdded Features
listsalenft
now batch as well
buynft
by setting memo to "deposit"DEX in a token (simple marketplace functionality)
listsalenft
: callable ownly by owner; creates a sale listing in the token contract valid
for 1 week, transfers ownership to token contractclosesalenft
: callable by seller if listing hasn't expired, or anyone if the listing is expired;
will remove listing and return nft to sellerbuynft
: called when a user sends EOS to the dgood contract with a memo of "dgood_id,to_account"Metadata URI changes
metadata_uri
is now formed from a base_uri
+ either the dgood_id
or relative_uri
if it
existscreate
now takes a base_uri
stringissue
has a relative_uri
parameter, but it is now optional (enter empty string)relative_uri
is specified on a given token, the metadata should be accessed by taking
base_uri
+ dgood_id
relative_uri
exists, the metadata is base_uri
+ relative_uri
Table Changes
tokenstats
-> dgoodstats
tokeninfo
-> dgood
tokeninfo_id
-> dgood_id
Misc
_self
with get_self()
for future proofingft
appended (ex burn -> burnft)dgood_id
during issuance to aid in matching transaction with actionToken config
symbolinfo
table to tokenconfigs
setconfig
to set the symbol and versionAsset / Quantities
Issuance
issue
now takes a metadata_typetokeninfo
table adds metadata_type onto the token instead of just in the metadata itselfTransfer
Token Stats Table
issued_supply
to keep track of serial_number
when a token has been burned (ie current_supply
is decreased but issued_supply
never decreases)Metadata Templates
lang
key that specifies the language