ERC 888: MultiDimensional Token Standard

[troverman]

EIP #888

Multidimensional Token Structure: [address][_id][_value]

Title: Multidimensional Token Standard
Author: Trevor Overman @troverman
Type: Standard Track
Category: ERC
Status: Draft
Created: 2018-02-17

Summary

Proposing a model for multidimensional tokenization, which utilizes identifiers to refer to balances & data.

Abstract
Short (~200 word) description of the technical issue being addressed.

Token data-structures with balances specified by unique identifiers create emergent properties within cryptoeconomic systems that introduce valuable approaches to mechanism design and contract development. Multidimensional tokens involve layers of information and functionality, create interdependent curation markets, and give rise to integrated information across networks.

Specification
The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (cpp-ethereum, go-ethereum, parity, ethereumj, ethereumjs, etc).

Solidity Contract

mapping (address => mapping (string => uint)) balances;

event Transfer(address indexed _from, address indexed _to, string indexed _id, uint256 _value);

function balanceOf(address _owner, string _id) constant returns (uint256 balance) {
     return balances[_owner][_id];
}

function transfer(address _to, string _id, uint256 _value) returns (bool success) {
     if (balances[msg.sender][_id] >= _value && _value > 0) {
          balances[msg.sender][_id] -= _value;
          balances[_to][_id] += _value;
          Transfer(msg.sender, _to, _id, _value);
          return true; 
     }
     else { revert; }
}

function approve, allowance, transferFrom -- mirror ERC20 → with identifier specification
utility contracts → specification based on the protocol implementation;
emergent properties based on identifier-specific logic;
i.e. vT protocol → viewers mint tokens w their address identifier → permission structures

Rationale
The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.

→ you would need to create infinite ERC20 contracts to equate one ERC88 contract -- allows for scalability of tokenized data structures.
→ allows for emergent properties based on identifier-specific logic and utility contracts to shape protocol implementation i.e. permission structures, token supply..

Backwards Compatibility
All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.

One could fork tokens with specified utility contracts
Sudo-code
//multiple fxns here;
//ERC20toERC88 function(ERC20Address, ERC20Amount, ERC88Id, ERC88amount){
//TODO: import contract via ERC20Address
//balances[msg.sender] -= ERC20Amount;
//balances[msg.sender][ERC88Id] += ERC88amount;
//}
//transferERC20toERC88 -- same as ^^ include address _to

Test Cases
Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.

bidio, cre8coin, viewToken

[nateawelch]

This is pretty interesting. It reminds me of this short lived conversation around Divisible NFTs from a couple weeks ago: #864.

The idea around divisible NFTs is to allow partial ownership of assets, which is pretty powerful. Imagine owning .001% of a van Gogh painting. Have you considered expanding this standard to cover both MDTs as well as DNFTs?

What was the rationality of choosing the type string for _id instead of a uint256? If a contract wants to track the MDTs it owns, it would have to store strings, which can be expensive, instead of just storing uint256. My suggestion is changing _id to a uint256 and including the tokenMetadata lookup to get data about the token. This would make it more compatible with also being a standard for DNFTs as well.

[k06a]

A few additions, including mentioned by @flygoing:
https://gist.github.com/k06a/b7677850ebe6d11dc6f3eb174db6dbd6

[milonite]

What's the status of this EIP?

[troverman]

What's the status of this EIP?

Just building practically, there are some modular protocol plugins and interesting language interpolation in the works. Creating a map of interrelationships between the token-string dimensions ie a 'Multidimensional Token Market' is a strong point of interest -- Contracts that play nice with the underlying nested mapping structure and supplemental modular protocol plugins; who define manifold token logic give this design pattern depth.

I'll be laying out how to build governance models and organizational templating within the acceptance of protocol modules. However, I'm not sold on vanella EVM implementations - the concepts are able to stand independent.

However the overall open source based status of this EIP and the related concepts is highly dependent on transparent collaboration.

If you'd like to alpha test &or collaborate I'd like you to register on CRE8.

https://www.cre8.xyz/

Ask questions, albeit I'll update as progress develops.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.