Gems protocol (customizable tokens)

Application and game developers need a protocol to work with their own tokens, issued on a verifiable layer on top of VIZ.

I propose to consider the Gems protocol as a basic mechanism for tokens, both fungible and not-fungible.

Gems - adaptive tokens on the VIZ blockchain.

In the previous publication I’ve mentioned NFT on VIZ, following that post there were questions in public chat and in private: "what about regular tokens?". In fact, the basic features are not much different for the two types of tokens.

Basic Gems Properties

• Fungible - whether the token is divisible (boolean);
• Owner - account, token provider (account);
• Transferable - the ability to pass a token (boolean);
• Trustline - the necessity to trust the provider of the token in order to own it (boolean);
• Agreement - reference to the agreement on the token usage (string);
• Tradable - the ability to open token exchange deal on VIZ (boolean);
• Limit transfer - the ability to limit token transfer for an individual account (boolean);
• Limit trade - the ability to limit token exchange (boolean);
• Removable - the ability of token provider to withdraw tokens from the current owner, analog to removal (boolean).

Fungible Gems - properties of divisible tokens

• Name - token name (string);
• Description - token description, purpose (string);
• Icon - link to the token icon (string);
• Precision - precision (number of decimal places, minimum: 0, maximum: 8);
• Max supply - maximum volume, 0 - no restrictions (integer);
• Issuable - the ability for the provider to issue an asset (boolean);
• Collateral - a requirement to secure the asset with a pledge to the VIZ committee (boolean);
• Collateral issuable - the ability of any participant to issue an asset secured by the pledge to the VIZ committee (boolean);
• Collateral ratio - the token to collateral ratio in percent (integer).

Not-Fungible Gems - Properties of indivisible NFT tokens

• Category - token category (string);
• Name - token name (string);
• Icon - token icon link, optional (string);
• Image - token image link, optional (string);
• Data location - link to the JSON parameters of the token, optional if the provider wants to control the parameters of the asset centrally (string);
• Data - JSON token parameters, required in the absence of data location (array);
• Durability - number of seconds of token validity, by default 0 - not destroyed (integer);
• Limit - the maximum number of tokens of this type, by default 0 (integer);
• Count - the number of issued tokens of this type, used to number each token (integer);
• Collateral - a requirement to secure an asset through a pledge to the VIZ committee (boolean);
• Collateral issuable - the ability of any participant to issue an asset secured by the VIZ committee pledge (boolean);
• Collateral amount - the amount of VIZ required to issue the asset, a number without precision (integer).

Operations for working with VIZ Gems tokens

The Gems protocol (“G” will be used for minimization) can be built on custom operations using the methods:

• Create - Creates an asset by specifying the necessary parameters in the associative array;
• Issue - issue of a new asset (specifying the asset name, quantity and recipient);
• Trustline - an act of trust to the provider with the name of the asset;
• Transfer - transfer of an asset to another account indicating the provider of the asset, name, quantity (additional category in case of transfer of NFT Gems);
• Trade - a request for an exchange for a specific account indicating the provider, the name of the asset, the quantity, the price in VIZ (deferred operation, processing of irreversible blocks);
• Cancel trade - transaction cancellation (delayed operation, irreversible block processing, transfer operations have priority to track completed transactions in the same block);
• Transfer ownership - transfer of asset ownership to another account, change of provider (application);
• Accept ownership - receiving asset management rights from another account (confirmation);
• Remove - withdrawal of the asset from the account by the name of the asset, quantity and purpose.

In order to make asset trading possible, Oracle needs to provide delayed processing of trade and cancel trade methods after accounting for transfer operations. It will allow to exclude a conflict situation, when an asset is purchased in the same block, which contains cancel trade.

To create a VIZ Gems accounting database, the oracle will need to process custom (for internal methods) and transfer operations (to account for the exchange of an asset for VIZ and the release of an asset with the transfer of the collateral to the VIZ committee).

Collateral assets are optional. In this case, the committee acts as a trustee in case of termination of the asset's circulation.

Will gladly accept comments and discussion on the proposed VIZ Gems Protocol. The launch and maintenance of this protocol will enable infrastructural growth for the entire ecosystem of projects launched on VIZ.