Add ERC: Security token interface for confidentiality and legal status transparency to crypto security tokens #143
Conversation
…orge/ERCs into add-erc-security-token-gesact-ext
File
|
eip-review-bot
changed the title
eip-review-bot
changed the title
itinance
changed the title
|
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR 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. |
This comment was marked as spam.
This comment was marked as spam.
There was a problem hiding this comment.
You'll need to address all the issues found by eipw as well: https://github.com/ethereum/ERCs/actions/runs/7112458879/job/19362450600
| --- | ||
| number: 7570 | ||
| title: Security token interface for confidentiality and legal status transparency to crypto security tokens | ||
| description: Smart contract interface standard to additionally offer confidentiality and legal status transparency to crypto securities according to the German Electronic Security Act ([eWpG](https://www.gesetze-im-internet.de/ewpg/index.html)) |
There was a problem hiding this comment.
You cannot include markdown in the header fields. They must be plain text. Additionally, we discourage the word "standard" in titles and descriptions.
| description: Smart contract interface standard to additionally offer confidentiality and legal status transparency to crypto securities according to the German Electronic Security Act ([eWpG](https://www.gesetze-im-internet.de/ewpg/index.html)) | |
| description: Confidentiality and legal status transparency for crypto securities according to the German Electronic Security Act |
| --- | ||
|
|
||
| ## Abstract | ||
| This standard is an extension of [ERC-7551](https://github.com/ethereum/ERCs/pull/85). While ERC-7551 defines a compliant transfer, freezing of securities, enforced transfers by operators and machine readable properties of the issuance itself, this standard addresses the additional regulatory requirements according to the German Electronic Security Act ([eWpG](https://www.gesetze-im-internet.de/ewpg/index.html)) in terms of confidentiality and transparency of the legal status of a security. |
There was a problem hiding this comment.
We don't currently allow links to www.gesetze-im-internet.de. While I don't expect the German government to disappear and stop publishing their laws, there is a particularly important consideration with this EIP in particular.
Imagine ERC-7570 has made it through the standardization process, and has moved to the Final status. At some point after that, the eWpG is amended to include new requirements. Someone coming to read ERC-7570 at that point might mistakenly think that ERC-7570 has been updated to work with the new law, even though Final documents cannot be edited and any new implementations wouldn't be compliant.
For this reason, we have some strict requirements on external links. You can see the process for approving new sources in EIP-5757.
I don't speak German, so unfortunately I can't help you find a permalink to a particular version of the law. If such links exist, there's a good chance we could approve www.gesetze-im-internet.de.
| type: Standards Track | ||
| category: ERC | ||
| created: 2023-11-30 | ||
| --- |
There was a problem hiding this comment.
| --- | |
| requires: 20, 1155, 7551 | |
| --- |
Including ERC-20 because you're borrowing the allowances concept.
| ## Abstract | ||
| This standard is an extension of [ERC-7551](https://github.com/ethereum/ERCs/pull/85). While ERC-7551 defines a compliant transfer, freezing of securities, enforced transfers by operators and machine readable properties of the issuance itself, this standard addresses the additional regulatory requirements according to the German Electronic Security Act ([eWpG](https://www.gesetze-im-internet.de/ewpg/index.html)) in terms of confidentiality and transparency of the legal status of a security. | ||
|
|
||
| As no current approved standard is supporting the full set of demanded functionality, this standard shall, as an extension of ERC-7551, enable the industry to build applications relying on a fully compliant On-Chain register for securities. |
There was a problem hiding this comment.
| As no current approved standard is supporting the full set of demanded functionality, this standard shall, as an extension of ERC-7551, enable the industry to build applications relying on a fully compliant On-Chain register for securities. | |
| This standard shall, as an extension of ERC-7551, enable the industry to build applications relying on a fully compliant On-Chain register for securities. |
| The smart contract must provide a full set of properties along with the Balance as ruled out in the law. | ||
|
|
||
| ### Support of different legal statuses of a security | ||
| The smart contract must support different statuses of a security and enable transfer restrictions according to certain statuses. This is done by an approach based on ERC-1155. |
There was a problem hiding this comment.
| The smart contract must support different statuses of a security and enable transfer restrictions according to certain statuses. This is done by an approach based on ERC-1155. | |
| The smart contract must support different statuses of a security and enable transfer restrictions according to certain statuses. This is done by an approach based on [ERC-1155](./eip-1155.md). |
| Therefore, this EIP only makes sense on a customized EVM blockchain that permits the hiding of transactions from the public, while also providing access to execute methods on a Smart Contract. This approach ensures that complete control over token management is solely handled via the underlying Smart Contract(s). | ||
|
|
||
| ## Specifications | ||
| As we have explained above, none of the current ERC token standards are capable of meeting the requirements of the German Electronic Securities Act (eWpG) regarding registration details and confidentiality. A standard is needed that conceptually integrates this regulation. |
There was a problem hiding this comment.
No need to repeat yourself.
| As we have explained above, none of the current ERC token standards are capable of meeting the requirements of the German Electronic Securities Act (eWpG) regarding registration details and confidentiality. A standard is needed that conceptually integrates this regulation. |
| ## Specifications | ||
| As we have explained above, none of the current ERC token standards are capable of meeting the requirements of the German Electronic Securities Act (eWpG) regarding registration details and confidentiality. A standard is needed that conceptually integrates this regulation. | ||
|
|
||
| Therefore, we suggest abandoning the compatibility with ERC-20 and instead introduce compatibility with the ERC-1155 standard. The ERC-1155 is a token standard that allows for the creation and management of multiple types of tokens within a single Smart-Contract. This is in contrast to earlier token standards like ERC-20 and ERC-721, which support only one type of token per Smart-Contract. |
There was a problem hiding this comment.
| Therefore, we suggest abandoning the compatibility with ERC-20 and instead introduce compatibility with the ERC-1155 standard. The ERC-1155 is a token standard that allows for the creation and management of multiple types of tokens within a single Smart-Contract. This is in contrast to earlier token standards like ERC-20 and ERC-721, which support only one type of token per Smart-Contract. | |
| Therefore, we suggest abandoning the compatibility with ERC-20 and instead introduce compatibility with the ERC-1155 standard. The ERC-1155 is a token standard that allows for the creation and management of multiple types of tokens within a single smart contract. This is in contrast to earlier token standards like ERC-20 and ERC-721, which support only one type of token per smart contract. |
Please be consistent with "smart contract" throughout the document.
|
|
||
| With ERC-1155, various token types, including fungible tokens (e.g., cryptocurrencies, securities, assets) and non-fungible tokens (e.g., collectibles, artwork, other unique items), can be created in a single Smart-Contract instance. This also allows for more efficient token management and reduces transaction costs, as multiple tokens can be transferred in a single transaction. | ||
|
|
||
| This standard, in conjunction with the underlying ERC-7551, will modify the ERC-1155 to ensure legal compliance. By default, the 'balanceOf' method will always return 0 (indicating zero balance) to fulfill data protection requirements. To facilitate compatibility with secondary markets, DEXes, and similar platforms, any token holder will be allowed to define the quantity of tokens they wish to be displayed by the 'balanceOf' method. This is provided that the displayed balance remains within the range of 0 <= displayed balance <= actual balance. |
There was a problem hiding this comment.
| This standard, in conjunction with the underlying ERC-7551, will modify the ERC-1155 to ensure legal compliance. By default, the 'balanceOf' method will always return 0 (indicating zero balance) to fulfill data protection requirements. To facilitate compatibility with secondary markets, DEXes, and similar platforms, any token holder will be allowed to define the quantity of tokens they wish to be displayed by the 'balanceOf' method. This is provided that the displayed balance remains within the range of 0 <= displayed balance <= actual balance. | |
| This standard, in conjunction with the underlying ERC-7551, will modify the ERC-1155 to ensure legal compliance. By default, the `balanceOf` method will always return 0 (indicating zero balance) to fulfill data protection requirements. To facilitate compatibility with secondary markets, decentralized exchanges (DEXs), and similar platforms, any token holder will be allowed to define the quantity of tokens they wish to be displayed by the `balanceOf` method. This is provided that the displayed balance remains within the range of 0 <= displayed balance <= actual balance. |
Use backticks (`) when including inline code snippets. Also, please expand abbreviations the first time they are used.
| function denomination() external view returns (string memory); | ||
| ``` | ||
|
|
||
| #### authorizeRepresentative |
There was a problem hiding this comment.
| #### authorizeRepresentative | |
| #### `authorizeRepresentative` |
Please also make this change for the remaining headers.
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via CC0. |
There was a problem hiding this comment.
Please use the exact waiver from the template.
eip-review-bot
changed the title
|
The commit 644afcc (as a parent of 86244c9) contains errors. |
|
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR 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. |
|
This pull request 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. |
This PR suggests a Smart contract interface standard to additionally offer confidentiality and legal status transparency to crypto securities according to the German Electronic Security Act (eWpG)