mirror of https://github.com/status-im/EIPs.git
Modified attributes content in eip-1261 (#1480)
* Create eip-1261 * updated eip 1261 * edited title to remove erc number * Updated to a new standard * Modified eip-1261 to add attributes * modified revoke to forfeit * added eip 1417 * added eip-1425 * modified eip-1261 to add current member count * deleted other eips
This commit is contained in:
Chaitanya Potti
Nick Johnson
parent
ea4e630855
commit
6dde0f2f10
230
EIPS/eip-1261.md
230
EIPS/eip-1261.md
|
|
@ -1,13 +1,13 @@
|
|||
---
|
||||
eip: 1261
|
||||
title: Membership Verification Token (MVT)
|
||||
author: Chaitanya Potti <chaitanya@electus.network>, Partha Bhattacharya <partha@electus.network>
|
||||
author: Chaitanya Potti (@chaitanyapotti), Partha Bhattacharya (@pb25193)
|
||||
type: Standards Track
|
||||
category: ERC
|
||||
status: Draft
|
||||
created: 2018-07-14
|
||||
requires: 165, 173
|
||||
discussions-to: https://github.com/ethereum/EIPs/issues/1261
|
||||
|
||||
---
|
||||
|
||||
## Simple Summary
|
||||
|
|
@ -25,91 +25,185 @@ We considered use cases of MVTs being assigned to individuals which are non-tran
|
|||
- Investor permissioning: Making regulatory compliance a simple on chain process. Tokenization of securities, that are streamlined to flow only to accredited addresses, tracing and certifying on chain addresses for AML purposes.
|
||||
- Software licencing: Software companies like game developers can use the protocol to authorize certain hardware units(consoles) to download and use specific software(games)
|
||||
|
||||
|
||||
In general, an individual can have different memberships in his day to day life. The protocol allows for the creation of software that puts everything all at one place. His identity can be verified instantly. Imagine a world where you don't need to carry a wallet full of identity cards (Passport, gym membership, SSN, Company ID etc) and organizations can easily keep track of all its members. Organizations can easily identify and disallow fake identities.
|
||||
|
||||
Attributes are a huge part of ERC-1261 which help to store identifiable information regarding its members. Polls can make use of attributes to calculate the voterbase.
|
||||
E.g: Users should belong to USA entity and not belong to Washington state attribute to be a part of a poll.
|
||||
|
||||
There will exist a mapping table that maps attribute headers to an array of all possible attributes. This is done in order to subdivide entities into subgroups which are exclusive and exhaustive. For example,
|
||||
header: blood group alphabet
|
||||
Array: [ o, a, b, ab ]
|
||||
header: blood group sign
|
||||
Array: [ +, - ]
|
||||
|
||||
NOT an example of exclusive exhaustive:
|
||||
Header: video subscription
|
||||
Array: [ Netflix, HBO, Amazon ]
|
||||
Because a person is not necessitated to have EXACTLY one of the elements. He or she may have none or more than one.
|
||||
|
||||
## Motivation
|
||||
|
||||
A standard interface allows any user,applications to work with any MVT on Ethereum. We provide for simple ERC-1261 smart contracts. Additional applications are discussed below.
|
||||
|
||||
This standard is inspired from the fact that voting on the blockchain is done with token balance weights. This has been greatly detrimental to the formation of flexible governance systems on the blockchain, despite the tremendous governance potential that blockchains offer. The idea was to create a permissioning system that allows organizations to vet people once into the organization on the blockchain, and then gain immense flexibility in the kind of governance that can be carried out.
|
||||
|
||||
**Trade-off between trustlessness and usability:**
|
||||
To truly understand the value of the protocol, it is important to understand the trade-off we are treading on. The MVT contract allows the creator to revoke the token, and essentially confiscate the membership of the member in question. To some, this might seem like an unacceptable flaw, however this is a design choice, and not a flaw.
|
||||
The choice may seem to place a great amount of trust in the individuals who are managing the entity contract(entity owners). If the interests of the entity owner conflict with the interests of the members, the owner may resort to addition of fake addresses(to dominate consensus) or evicting members(to censor unfavourable decisions). At first glance this appears to be a major shortcomings, because the blockchain space is used to absolute removal of authority in most cases. Even the official definition of a dapp requires the absence of any party that manages the services provided by the application. However, the trust in entity owners is not misplaced, if it can be ensured that the interests of entity owners are aligned with the interests of members.
|
||||
Another criticism of such a system would be that the standard edge of blockchain intermediation - “you cannot bribe the system if you don’t know who to bribe” - no longer holds. It is possible to bribe an entity owner into submission, and get them to censor or fake votes. There are several ways to respond to this argument. First of all, all activities, such as addition of members, and removal of members can be tracked on the blockchain and traces of such activity cannot be removed. It is not difficult to build analytics tools to detect malicious activity(adding 100 fake members suddenly who vote in the direction/sudden removal of a number of members voting in a certain direction). Secondly, the entity owners’ power is limited to the addition and removal of members. This means that they cannot tamper any votes. They can only alter the counting system to include fake voters or remove real voters. Any sensible auditor can identify the malicious/victim addresses and create an open source audit tool to find out the correct results. The biggest loser in this attack will be the entity owner, who has a reputation to lose.
|
||||
Finally, one must understand why we are taking a step away from trustlessness in this trade-off. The answer is usability. Introducing a permissioning system expands the scope of products and services that can be delivered through the blockchain, while leveraging other aspects of the blockchain(cheap, immutable, no red-tape, secure). Consider the example of the driver licence issuing agency using the ERC-1300 standard. This is a service that simply cannot be deployed in a completely trustless environment. The introduction of permissioned systems expanded the scope of services on the blockchain to cover this particular service. Sure, they have the power to revoke a person’s licence for no reason. But will they? Who stands to lose the most, if the agency acts erratically? The agency itself. Now consider the alternative, the way licences(not necessarily only drivers licence, but say shareholder certificates and so on) are issued, the amount of time consumed, the complete lack of transparency. One could argue that if the legacy systems providing these services really wanted to carry out corruption and nepotism in the execution of these services, the present systems make it much easier to do so. Also, they are not transparent, meaning that there is no way to even detect if they act maliciously.
|
||||
All that being said, we are very excited to share our proposal with the community and open up to suggestions in this space.
|
||||
We have also reviewed other Membership EIPs including EIP-725/735 Claim Registry. A significant difference between #735 claims and #1261 MVTs is information ownership. In #735 the Claim Holder owns any claims made about themselves. The problem with this is that there is no way for a Claim Issuer to revoke or alter a claim once it has been issued. While #735 does specify a removeClaim method, a malicious implementation could simply ignore that method call, because they own the claim.
|
||||
|
||||
Imagine that SafeEmploy™, a background checking company, issues a claim about Timmy. The claim states that Timmy has never been convicted of any felonies. Timmy makes some bad decisions, and now that claim is no longer true. SafeEmploy™ executes removeClaim, but Timmy's #735 contract just ignores it, because Timmy wants to stay employed (and is crypto-clever). #1261 MVTs do not have this problem. Ownership of a badge/claim is entirely determined by the contract issuing the badges, not the one receiving them. The issuer is free to remove or change those badges as they see fit.
|
||||
|
||||
**Trade-off between trustlessness and usability:**
|
||||
To truly understand the value of the protocol, it is important to understand the trade-off we are treading on. The MVT contract allows the creator to revoke the token, and essentially confiscate the membership of the member in question. To some, this might seem like an unacceptable flaw, however this is a design choice, and not a flaw.
|
||||
The choice may seem to place a great amount of trust in the individuals who are managing the entity contract(entity owners). If the interests of the entity owner conflict with the interests of the members, the owner may resort to addition of fake addresses(to dominate consensus) or evicting members(to censor unfavourable decisions). At first glance this appears to be a major shortcomings, because the blockchain space is used to absolute removal of authority in most cases. Even the official definition of a dapp requires the absence of any party that manages the services provided by the application. However, the trust in entity owners is not misplaced, if it can be ensured that the interests of entity owners are aligned with the interests of members.
|
||||
Another criticism of such a system would be that the standard edge of blockchain intermediation - “you cannot bribe the system if you don’t know who to bribe” - no longer holds. It is possible to bribe an entity owner into submission, and get them to censor or fake votes. There are several ways to respond to this argument. First of all, all activities, such as addition of members, and removal of members can be tracked on the blockchain and traces of such activity cannot be removed. It is not difficult to build analytics tools to detect malicious activity(adding 100 fake members suddenly who vote in the direction/sudden removal of a number of members voting in a certain direction). Secondly, the entity owners’ power is limited to the addition and removal of members. This means that they cannot tamper any votes. They can only alter the counting system to include fake voters or remove real voters. Any sensible auditor can identify the malicious/victim addresses and create an open source audit tool to find out the correct results. The biggest loser in this attack will be the entity owner, who has a reputation to lose.
|
||||
Finally, one must understand why we are taking a step away from trustlessness in this trade-off. The answer is usability. Introducing a permissioning system expands the scope of products and services that can be delivered through the blockchain, while leveraging other aspects of the blockchain(cheap, immutable, no red-tape, secure). Consider the example of the driver licence issuing agency using the ERC-1300 standard. This is a service that simply cannot be deployed in a completely trustless environment. The introduction of permissioned systems expanded the scope of services on the blockchain to cover this particular service. Sure, they have the power to revoke a person’s licence for no reason. But will they? Who stands to lose the most, if the agency acts erratically? The agency itself. Now consider the alternative, the way licences(not necessarily only drivers licence, but say shareholder certificates and so on) are issued, the amount of time consumed, the complete lack of transparency. One could argue that if the legacy systems providing these services really wanted to carry out corruption and nepotism in the execution of these services, the present systems make it much easier to do so. Also, they are not transparent, meaning that there is no way to even detect if they act maliciously.
|
||||
All that being said, we are very excited to share our proposal with the community and open up to suggestions in this space.
|
||||
|
||||
## Specification
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
|
||||
|
||||
**Every ERC-1261 compliant contract must implement the `ERC1261` interface:
|
||||
**Every ERC-1261 compliant contract must implement the `ERC1261`, `ERC173` and `ERC165` interfaces** (subject to "caveats" below):
|
||||
|
||||
```solidity
|
||||
pragma solidity ^0.4.24;
|
||||
|
||||
/// @title ERC-1261 MVT Standard
|
||||
/// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1261.md
|
||||
interface ERC1261 {
|
||||
/// The constructor should define the attribute set for this MVT.
|
||||
/// Note: the ERC-165 identifier for this interface is 0x1d8362cf.
|
||||
interface IERC1261 /* is ERC173, ERC165 */ {
|
||||
/// @dev This emits when a token is assigned to a member.
|
||||
event Assigned(address _to);
|
||||
event Assigned(address indexed to);
|
||||
|
||||
/// @dev This emits when a membership is revoked
|
||||
event Revoked(address _to);
|
||||
/// @dev This emits when a membership is revoked.
|
||||
event Revoked(address indexed to);
|
||||
|
||||
/// @dev This emits when data of a member is modified.
|
||||
/// Doesn't emit when a new membership is created and data is assigned.
|
||||
event ModifiedData(address indexed to);
|
||||
|
||||
/// @notice Queries whether a member is a current member of the organization.
|
||||
/// @dev MVT's assigned to the zero address are considered invalid, and this
|
||||
/// function throws for queries about the zero address.
|
||||
/// @param _owner An address for whom to query the membership
|
||||
/// @return whether the member owns the token
|
||||
/// @param _to An address for whom to query the membership.
|
||||
/// @return Whether the member owns the token.
|
||||
function isCurrentMember(address _to) external view returns (bool);
|
||||
|
||||
/// @notice Find the member of an MVT
|
||||
/// @dev index starts from zero. Useful to query all addresses (past or present)
|
||||
/// @param _tokenId The index
|
||||
/// @return The address of the owner of the IVM contract
|
||||
function getAddressAtIndex(uint256 _index) external view returns (address);
|
||||
/// @notice Returns the list of all past and present members.
|
||||
/// @dev Use this function along with isCurrentMember to find wasMemberOf() in Js.
|
||||
/// It can be calculated as present in getAllMembers() and !isCurrentMember().
|
||||
/// @return List of addresses who have owned the token and currently own the token.
|
||||
function getAllMembers() external view returns (address[]);
|
||||
|
||||
/// @notice Assigns membership of an MVT from owner address to another address
|
||||
/// @notice Returns the count of all current members.
|
||||
/// @dev Use this function in polls as denominator to get percentage of members voted.
|
||||
/// @return Count of current Members.
|
||||
function getCurrentMemberCount() external view returns (uint);
|
||||
|
||||
/// @notice Returns the list of all attribute names.
|
||||
/// @dev Returns the names of attributes as a bytes32 array.
|
||||
/// AttributeNames are stored in a bytes32 Array.
|
||||
/// Possible values for each attributeName are stored in a mapping(attributeName => attributeValues).
|
||||
/// AttributeName is bytes32 and attributeValues is bytes32[].
|
||||
/// Attributes of a particular user are stored in bytes32[].
|
||||
/// Which has a single attributeValue for each attributeName in an array.
|
||||
/// Use web3.toAscii(data[0]).replace(/\u0000/g, "") to convert to string in JS.
|
||||
/// @return The names of attributes.
|
||||
function getAttributeNames() external view returns (bytes32[]);
|
||||
|
||||
/// @notice Returns the attributes of `_to` address.
|
||||
/// @dev Throws if `_to` is the zero address.
|
||||
/// Use web3.toAscii(data[0]).replace(/\u0000/g, "") to convert to string in JS.
|
||||
/// @param _to The address whose current attributes are to be returned.
|
||||
/// @return The attributes associated with `_to` address.
|
||||
function getAttributes(address _to) external view returns (bytes32[]);
|
||||
|
||||
/// @notice Returns the `attribute` stored against `_to` address.
|
||||
/// @dev Finds the index of the `attribute`.
|
||||
/// Throws if the attribute is not present in the predefined attributes.
|
||||
/// Returns the attributeValue for the specified `attribute`.
|
||||
/// @param _to The address whose attribute is requested.
|
||||
/// @param attribute The attribute name which is required.
|
||||
/// @return The attribute value at the specified name.
|
||||
function getAttributeByName(address _to, bytes32 attribute) external view returns (bytes32);
|
||||
|
||||
/// @notice Adds a new attribute (key, value) pair to the set of pre-existing attributes.
|
||||
/// @dev Adds a new attribute at the end of the array of attributes and maps it to `values`.
|
||||
/// Contract can set a max number of attributes and throw if limit is reached.
|
||||
/// @param _name Name of the attribute which is to be added.
|
||||
/// @param values List of values of the specified attribute.
|
||||
function addAttributeSet(bytes32 _name, bytes32[] values) external;
|
||||
|
||||
/// @notice Modifies the attribute value of a specific attribute for a given `_to` address.
|
||||
/// @dev Use appropriate checks for whether a user/admin can modify the data.
|
||||
/// Best practice is to use onlyOwner modifier from ERC173.
|
||||
/// @param _to The address whose attribute is being modified.
|
||||
/// @param _attributeName The attribute name which is being modified.
|
||||
/// @param _modifiedValueIndex The index of the new value which is being assigned to the user attribute.
|
||||
function modifyAttributeByName(address _to, bytes32 _attributeName, uint _modifiedValueIndex) external;
|
||||
|
||||
/// @notice Requests membership from any address.
|
||||
/// @dev Throws if the `msg.sender` already has the token.
|
||||
/// The individual `msg.sender` can request for a membership and if some exisiting criteria are satisfied.
|
||||
/// The individual `msg.sender` receives the token.
|
||||
/// When the token is assigned, this function emits the Assigned event.
|
||||
/// @param data the attribute data associated with the member.
|
||||
/// This is an array which contains indexes of attributes.
|
||||
function requestMembership(uint[] data) external payable;
|
||||
|
||||
/// @notice User can forfeit his membership.
|
||||
/// @dev Throws if the `msg.sender` already doesn't have the token.
|
||||
/// The individual `msg.sender` can revoke his/her membership.
|
||||
/// When the token is revoked, this function emits the Revoked event.
|
||||
function forfeitMembership() external payable;
|
||||
|
||||
/// @notice Assigns membership of an MVT from owner address to another address.
|
||||
/// @dev Throws if the member already has the token.
|
||||
/// Throws if `_to` is the zero address.
|
||||
/// Throws if the `msg.sender` is not an owner.
|
||||
/// The entity assigns the membership to each individual.
|
||||
/// When transfer is complete, this function emits the Assigned event.
|
||||
/// @param _to The member
|
||||
function assign(address _to) external;
|
||||
/// When the token is assigned, this function emits the Assigned event.
|
||||
/// @param _to The address to which the token is assigned.
|
||||
/// @param data The attribute data associated with the member.
|
||||
/// This is an array which contains indexes of attributes.
|
||||
function assignTo(address _to, uint[] data) external;
|
||||
|
||||
/// @notice Requests membership from any address
|
||||
/// @dev Throws if the `msg.sender` already has the token.
|
||||
/// the individual `msg.sender` can request for a membership and if some exisiting criteria are satisfied,
|
||||
/// the individual `msg.sender` receives the token.
|
||||
/// When transfer is complete, this function emits the Assigned event.
|
||||
function assignTo() external payable;
|
||||
|
||||
/// @notice Revokes the membership
|
||||
/// @notice Only Owner can revoke the membership.
|
||||
/// @dev This removes the membership of the user.
|
||||
/// Throws if the `_from` is not an owner of the token.
|
||||
/// Throws if the `msg.sender` is not an owner.
|
||||
/// Throws if `_from` is the zero address.
|
||||
/// When transaction is complete, this function emits the Revoked event.
|
||||
/// @param _from The current owner of the MVT
|
||||
function revoke(address _from) external;
|
||||
|
||||
/// @notice Revokes membership from any address
|
||||
/// @dev Throws if the `msg.sender` already doesn't have the token.
|
||||
/// the individual `msg.sender` can revoke his/her membership.
|
||||
/// When transfer is complete, this function emits the Revoked event.
|
||||
function revokeFrom() external payable;
|
||||
/// @param _from The current owner of the MVT.
|
||||
function revokeFrom(address _from) external;
|
||||
}
|
||||
|
||||
interface ERC173 /* is ERC165 */ {
|
||||
/// @dev This emits when ownership of a contract changes.
|
||||
event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);
|
||||
|
||||
/// @notice Get the address of the owner
|
||||
/// @return The address of the owner.
|
||||
function owner() view external;
|
||||
|
||||
/// @notice Set the address of the new owner of the contract
|
||||
/// @param _newOwner The address of the new owner of the contract
|
||||
function transferOwnership(address _newOwner) external;
|
||||
}
|
||||
|
||||
interface ERC165 {
|
||||
/// @notice Query if a contract implements an interface
|
||||
/// @param interfaceID The interface identifier, as specified in ERC-165
|
||||
/// @dev Interface identification is specified in ERC-165. This function
|
||||
/// uses less than 30,000 gas.
|
||||
/// @return `true` if the contract implements `interfaceID` and
|
||||
/// `interfaceID` is not 0xffffffff, `false` otherwise
|
||||
function supportsInterface(bytes4 interfaceID) external view returns (bool);
|
||||
}
|
||||
```
|
||||
|
||||
The **metadata extension** is OPTIONAL for ERC-1261 smart contracts (see "caveats", below). This allows your smart contract to be interrogated for its name and for details about the organization which your IVM tokens represent.
|
||||
|
||||
```solidity
|
||||
/// @title ERC-1261 IVM Token Standard, optional metadata extension
|
||||
/// @title ERC-1261 MVT Standard, optional metadata extension
|
||||
/// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1261.md
|
||||
interface ERC1261Metadata /* is ERC1261 */ {
|
||||
/// @notice A descriptive name for a collection of MVTs in this contract
|
||||
|
|
@ -124,18 +218,18 @@ This is the "ERC1261 Metadata JSON Schema" referenced above.
|
|||
|
||||
```json
|
||||
{
|
||||
"title": "Organization Metadata",
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"description": "Identifies the organization to which this MVT represents",
|
||||
},
|
||||
"description": {
|
||||
"type": "string",
|
||||
"description": "Describes the organization to which this MVT represents",
|
||||
}
|
||||
"title": "Organization Metadata",
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"description": "Identifies the organization to which this MVT represents"
|
||||
},
|
||||
"description": {
|
||||
"type": "string",
|
||||
"description": "Describes the organization to which this MVT represents"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -148,7 +242,7 @@ The 0.4.24 Solidity interface grammar is not expressive enough to document the E
|
|||
- Solidity issue #2330: If a function is shown in this specification as `external` then a contract will be compliant if it uses `public` visibility. As a workaround for version 0.4.24, you can edit this interface to switch to `public` before inheriting from your contract.
|
||||
- Solidity issues #3494, #3544: Use of `this.*.selector` is marked as a warning by Solidity, a future version of Solidity will not mark this as an error.
|
||||
|
||||
*If a newer version of Solidity allows the caveats to be expressed in code, then this EIP MAY be updated and the caveats removed, such will be equivalent to the original specification.*
|
||||
_If a newer version of Solidity allows the caveats to be expressed in code, then this EIP MAY be updated and the caveats removed, such will be equivalent to the original specification._
|
||||
|
||||
## Rationale
|
||||
|
||||
|
|
@ -161,6 +255,8 @@ Since the tokens are non transferable and revocable, they function like membersh
|
|||
**Transfer Mechanism**
|
||||
|
||||
MVTs can't be transferred. This is a design choice, and one of the features that distinguishes this protocol.
|
||||
Any member can always ask the issuer to revoke the token from an existing address and assign to a new address.
|
||||
One can think of the set of MVTs as identifying a user, and you cannot split the user into parts and have it be the same user, but you can transfer a user to a new private key.
|
||||
|
||||
**Assign and Revoke mechanism**
|
||||
|
||||
|
|
@ -171,9 +267,21 @@ The assign and revoke functions' documentation only specify conditions when the
|
|||
- **Disallow additional memberships after a certain time is reached** — Sample contract found on Electus Protocol
|
||||
- **Charge a fee to user of a transaction** — require payment when calling `assign` and `revoke` so that condition checks from external sources can be made
|
||||
|
||||
**ERC-173 Interface**
|
||||
|
||||
We chose Standard Interface for Ownership (ERC-173) to manage the ownership of a ERC-1261 contract.
|
||||
|
||||
A future EIP/ Zeppelin may create a multi-ownable implementation for ownership. We strongly support such an EIP and it would allow your ERC-1261 implementation to implement `ERC1261Metadata`, or other interfaces by delegating to a separate contract.
|
||||
|
||||
**ERC-165 Interface**
|
||||
|
||||
We chose Standard Interface Detection (ERC-165) to expose the interfaces that a ERC-1261 smart contract supports.
|
||||
|
||||
A future EIP may create a global registry of interfaces for contracts. We strongly support such an EIP and it would allow your ERC-1261 implementation to implement `ERC1261Metadata`, or other interfaces by delegating to a separate contract.
|
||||
|
||||
**Gas and Complexity** (regarding the enumeration extension)
|
||||
|
||||
This specification contemplates implementations that manage a few and *arbitrarily large* numbers of MVTs. If your application is able to grow then avoid using for/while loops in your code. These indicate your contract may be unable to scale and gas costs will rise over time without bound
|
||||
This specification contemplates implementations that manage a few and _arbitrarily large_ numbers of MVTs. If your application is able to grow then avoid using for/while loops in your code. These indicate your contract may be unable to scale and gas costs will rise over time without bound
|
||||
|
||||
**Privacy**
|
||||
|
||||
|
|
@ -184,13 +292,13 @@ Membership privacy: The protocol by design, makes it public which addresses are/
|
|||
|
||||
We have required `name` and `symbol` functions in the metadata extension. Every token EIP and draft we reviewed (ERC-20, ERC-223, ERC-677, ERC-777, ERC-827) included these functions.
|
||||
|
||||
We remind implementation authors that the empty string is a valid response to `name` and `symbol` if you protest to the usage of this mechanism. We also remind everyone that any smart contract can use the same name and symbol as *your* contract. How a client may determine which ERC-1261 smart contracts are well-known (canonical) is outside the scope of this standard.
|
||||
We remind implementation authors that the empty string is a valid response to `name` and `symbol` if you protest to the usage of this mechanism. We also remind everyone that any smart contract can use the same name and symbol as _your_ contract. How a client may determine which ERC-1261 smart contracts are well-known (canonical) is outside the scope of this standard.
|
||||
|
||||
A mechanism is provided to associate MVTs with URIs. We expect that many implementations will take advantage of this to provide metadata for each MVT system. The URI MAY be mutable (i.e. it changes from time to time). We considered an MVT representing membership of a place, in this case metadata about the organization can naturally change.
|
||||
|
||||
Metadata is returned as a string value. Currently this is only usable as calling from `web3`, not from other contracts. This is acceptable because we have not considered a use case where an on-blockchain application would query such information.
|
||||
|
||||
*Alternatives considered: put all metadata for each asset on the blockchain (too expensive), use URL templates to query metadata parts (URL templates do not work with all URL schemes, especially P2P URLs), multiaddr network address (not mature enough)*
|
||||
_Alternatives considered: put all metadata for each asset on the blockchain (too expensive), use URL templates to query metadata parts (URL templates do not work with all URL schemes, especially P2P URLs), multiaddr network address (not mature enough)_
|
||||
|
||||
**Community Consensus**
|
||||
|
||||
|
|
@ -214,14 +322,16 @@ Electus Protocol ERC1261 -- a reference implementation
|
|||
|
||||
- MIT licensed, so you can freely use it for your projects
|
||||
- Includes test cases
|
||||
- Also available as a npm package - npm i electusprotocol
|
||||
|
||||
## References
|
||||
|
||||
**Standards**
|
||||
|
||||
1. ERC-20 Token Standard. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md
|
||||
1. ERC-165 Standard Interface Detection. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md
|
||||
1. ERC-725/735 Claim Registry https://github.com/ethereum/EIPs/blob/master/EIPS/eip-725.md
|
||||
1. ERC-173 Owned Standard. https://github.com/ethereum/EIPs/issues/173
|
||||
1. Ethereum Name Service (ENS). https://ens.domains
|
||||
1. JSON Schema. http://json-schema.org/
|
||||
1. Multiaddr. https://github.com/multiformats/multiaddr
|
||||
1. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt
|
||||
|
|
|
|||
Loading…
Reference in New Issue