mirror of
https://github.com/status-im/EIPs.git
synced 2025-01-14 00:45:05 +00:00
Automatically merged updates to draft EIP(s) 1155
Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing
This commit is contained in:
parent
643ed3fc00
commit
7c67108653
144
EIPS/eip-1155.md
144
EIPS/eip-1155.md
@ -366,134 +366,7 @@ fr.json:
|
||||
|
||||
## Approval
|
||||
|
||||
The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. To permit approval on a subset of tokens, standardized scoped approval is available as an extension. More complex approval schemes will require the use of an external contract enforcing custom rules.
|
||||
|
||||
### Scoped Approval Extension
|
||||
|
||||
This extension enables restrictions on approval's reach using a standardized method. When considering a smart contract
|
||||
managing tokens from multiple different domains, it makes sense to limit approvals to those domains. Scoped approval is a
|
||||
generalization of this idea. ERC-1155 implementors can define scopes as needed.
|
||||
|
||||
<details>
|
||||
<summary>Interface</summary>
|
||||
|
||||
```solidity
|
||||
pragma solidity ^0.5.2;
|
||||
|
||||
/**
|
||||
Note: The ERC-165 identifier for this interface is 0x30168307.
|
||||
*/
|
||||
interface ERC1155ScopedApproval {
|
||||
/**
|
||||
@dev MUST emit when approval changes for scope.
|
||||
*/
|
||||
event ApprovalForScope(address indexed _owner, address indexed _operator, bytes32 indexed _scope, bool _approved);
|
||||
|
||||
/**
|
||||
@dev MUST emit when the token IDs are added to the scope.
|
||||
By default, IDs are in no scope.
|
||||
The range is inclusive: _idStart, _idEnd, and all IDs in between have been added to the scope.
|
||||
_idStart must be lower than or equal to _idEnd.
|
||||
*/
|
||||
event AddIdsToScope(uint256 indexed _idStart, uint256 indexed _idEnd, bytes32 indexed _scope);
|
||||
|
||||
/**
|
||||
@dev MUST emit when the token IDs are removed from the scope.
|
||||
The range is inclusive: _idStart, _idEnd, and all IDs in between have been removed from the scope.
|
||||
_idStart must be lower than or equal to _idEnd.
|
||||
*/
|
||||
event RemoveIdsFromScope(uint256 indexed _idStart, uint256 indexed _idEnd, bytes32 indexed _scope);
|
||||
|
||||
/** @dev MUST emit when a scope URI is set or changes.
|
||||
URIs are defined in RFC 3986.
|
||||
The URI MUST point a JSON file that conforms to the "Scope Metadata JSON Schema".
|
||||
*/
|
||||
event ScopeURI(string _value, bytes32 indexed _scope);
|
||||
|
||||
/**
|
||||
@notice Returns the number of scopes that contain _id.
|
||||
@param _id The token ID
|
||||
@return The number of scopes containing the ID
|
||||
*/
|
||||
function scopeCountForId(uint256 _id) public view returns (uint32);
|
||||
|
||||
/**
|
||||
@notice Returns a scope that contains _id.
|
||||
@param _id The token ID
|
||||
@param _scopeIndex The scope index to query (valid values are 0 to scopeCountForId(_id)-1)
|
||||
@return The Nth scope containing the ID
|
||||
*/
|
||||
function scopeForId(uint256 _id, uint32 _scopeIndex) public view returns (bytes32);
|
||||
|
||||
/**
|
||||
@notice Returns a URI that can be queried to get scope metadata. This URI should return a JSON document containing, at least the scope name and description. Although supplying a URI for every scope is recommended, returning an empty string "" is accepted for scopes without a URI.
|
||||
@param _scope The queried scope
|
||||
@return The URI describing this scope.
|
||||
*/
|
||||
function scopeUri(bytes32 _scope) public view returns (string memory);
|
||||
|
||||
/**
|
||||
@notice Enable or disable approval for a third party ("operator") to manage the caller's tokens in the specified scope.
|
||||
@dev MUST emit the ApprovalForScope event on success.
|
||||
@param _operator Address to add to the set of authorized operators
|
||||
@param _scope Approval scope (can be identified by calling scopeForId)
|
||||
@param _approved True if the operator is approved, false to revoke approval
|
||||
*/
|
||||
function setApprovalForScope(address _operator, bytes32 _scope, bool _approved) external;
|
||||
|
||||
/**
|
||||
@notice Queries the approval status of an operator for a given owner, within the specified scope.
|
||||
@param _owner The owner of the Tokens
|
||||
@param _operator Address of authorized operator
|
||||
@param _scope Scope to test for approval (can be identified by calling scopeForId)
|
||||
@return True if the operator is approved, false otherwise
|
||||
*/
|
||||
function isApprovedForScope(address _owner, address _operator, bytes32 _scope) public view returns (bool);
|
||||
}
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Scope Metadata JSON Schema</summary>
|
||||
|
||||
This shema is similar to the token metadata schema and also allows localization. `{id}` and `{locale}` should be replaced with the proper values.
|
||||
|
||||
```json
|
||||
{
|
||||
"title": "Scope Metadata",
|
||||
"type": "object",
|
||||
"required": ["name"],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"description": "Identifies the scope in a human-readable way.",
|
||||
},
|
||||
"description": {
|
||||
"type": "string",
|
||||
"description": "Describes the scope to allow users to make informed approval decisions.",
|
||||
},
|
||||
"localization": {
|
||||
"type": "object",
|
||||
"required": ["uri", "default", "locales"],
|
||||
"properties": {
|
||||
"uri": {
|
||||
"type": "string",
|
||||
"description": "The URI pattern to fetch localized data from. This URI should contain the substring `{locale}` which will be replaced with the appropriate locale value before sending the request."
|
||||
},
|
||||
"default": {
|
||||
"type": "string",
|
||||
"description": "The locale of the default data within the base JSON"
|
||||
},
|
||||
"locales": {
|
||||
"type": "array",
|
||||
"description": "The list of locales for which data is available. These locales should conform to those defined in the Unicode Common Locale Data Repository (http://cldr.unicode.org/)."
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</details>
|
||||
The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. To permit approval of a subset of token IDs, an interface such as [ERC-1761 Scoped Approval Interface](https://github.com/ethereum/EIPs/issues/1761) is suggested.
|
||||
|
||||
## Rationale
|
||||
|
||||
@ -545,19 +418,9 @@ Approval</summary>
|
||||
|
||||
### Approval
|
||||
|
||||
The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. It
|
||||
enables frictionless interaction with exchange and trade contracts. However, it may be desired to restrict approval in
|
||||
some applications. Restricted approval can prevent losses in cases where users do not audit the contracts they're
|
||||
approving. No standard API is supplied to manage scopes as this is implementation specific. Some implementations may
|
||||
opt to offer a fixed number of scopes, or assign a specific set of scopes to certain types. Other implementations may
|
||||
open up scope configuration to its users and offer methods to create scopes and assign IDs to them.
|
||||
The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. It enables frictionless interaction with exchange and trade contracts.
|
||||
|
||||
Sample use cases for scopes:
|
||||
|
||||
* A company may represent it's fleet of vehicles on the blockchain and it could create a scope for each regional office.
|
||||
* Game developers could share an ERC-1155 contract where each developer manages tokens under a specified scope.
|
||||
* Tokens of different value magnitude could be split in separate scopes. 0.01Ξ tokens would be kept separate from
|
||||
10,000.00Ξ tokens.
|
||||
Restricting approval to a certain set of Token IDs, quantities or other rules may be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested [ERC-1761 Scoped Approval Interface](https://github.com/ethereum/EIPs/issues/1761) which is compatible with ERC-1155.
|
||||
|
||||
</details>
|
||||
|
||||
@ -630,6 +493,7 @@ balanceOf(baseToken + index, msg.sender); // Get balance of the Non-Fungible tok
|
||||
- [ERC-1155 Reference Implementation](https://github.com/enjin/erc-1155)
|
||||
- [Horizon Games - Multi-Token Standard](https://github.com/horizon-games/multi-token-standard)
|
||||
- [Enjin Coin](https://enjincoin.io) ([github](https://github.com/enjin))
|
||||
- [The Sandbox - Dual ERC-1155/721 Contract](https://github.com/pixowl/thesandbox-contracts/tree/master/src/Asset)
|
||||
|
||||
**Articles & Discussions**
|
||||
- [Github - Original Discussion Thread](https://github.com/ethereum/EIPs/issues/1155)
|
||||
|
Loading…
x
Reference in New Issue
Block a user