Soliciting feedback for ERC-1404 .
The repository to check out is here .
Use of the standard lends to writing small, reusable smart contracts that are responsible for enforcing a single transfer restriction pattern.
Tokens implementing the standard are best constructed by composing said restrictions through multiple contract inheritance.
The examples in the above repo demonstrate several of these individual restriction implementations.
Would love to see criticism of the utility of these examples, their source code, and the standard itself!
1 Like
Hello @youfoundron and other potential people interested,
I have also posted on the Github issue but I post also here since this is the official place to discuss about ERC.
I wanted to ask about the current status of ERC-1404. Is there any plan to move it toward a finalized version or coordinate with the Ethereum Foundation to make it an official ERC standard?
There may be potential improvements (e.g., using uint256 instead of uint8 for restriction codes), but these could also be addressed in a different ERC since this ERC is already used as is for a long time
For context, I am one of the maintainer of CMTAT and we are using ERC-1404 in the CMTAT security token framework: CMTAT ( CMTA · GitHub )
ERC-1404 is still used today by other projects such as Centrifuge, blockdaemon
It would be great to hear any updates or thoughts on the standard’s next steps.
Hello everybody,
Following a discussion with @SamWilsn , I have opened a PR with an adapted version of the ERC-1404 content in the issue.
Let me know in this thread if you have any comments on the updated version!
master ← rya-sge:erc-1404
opened 08:24AM - 22 Apr 26 UTC
One of the standards which often appear in tokenization report and also used by … Centrifuge, CMTAT and TokenSoft is ERC-1404.
ERC-1404 is one of the oldest tokenization standard on Ethereum (2018) developed by Tokensoft to detect ERC-20 transfer restrictions with clear, human-readable error messages.
Unfortunately, it is still in draft stage and does not even appear on the Ethereum website.
It is only available as an issue on GitHub: [ERC-1404: Simple Restricted Token Standard · Issue #1404 · ethereum/EIPs · GitHub](https://github.com/ethereum/EIPs/issues/1404)
The author agrees that the standard is finalized and has been used in production for several years., I don’t think we should update the standard: [ERC-1404: Simple Restricted Token Standard · Issue #1404 · ethereum/EIPs · GitHub](https://github.com/ethereum/EIPs/issues/1404#issuecomment-4028208746).
Improvement could be done in another new related standards.
I have also contact on X one of the initial co-author on X to move the standard further: [2031248107292520609](https://x.com/masonic_tweets/status/2031248107292520609)
# ERC-1404 Changelog
Change compared to the original issue
## Changes Applied
1. Regional wording made jurisdiction-agnostic in Simple Summary.
- Before: "relevant US regulatory bodies"
- After: "relevant regulatory bodies across jurisdictions"
2. Normative language capitalized in Abstract.
- Before: "They must not only ... but must also ..."
- After: "They MUST not only ... but MUST also ..."
3. Normative language capitalized in Specification requirement.
- Before: "detectTransferRestriction must be evaluated ..."
- After: "detectTransferRestriction MUST be evaluated ..."
4. Normative language capitalized in revert guidance.
- Before: "the transaction should be reverted"
- After: "the transaction SHOULD be reverted"
5. Normative language capitalized in Rationale.
- Before: "execution of such logic should be initiated"
- After: "execution of such logic SHOULD be initiated"
6. Backward compatibility wording made more precise.
- Before: "By design ERC-1404 is fully backwards compatible with ERC-20."
- After: "By design ERC-1404 is interface-compatible with ERC-20, while transfer restrictions may introduce behavioral differences."
7. Grammar and clarity improvement.
- Before: "will highly convenience the exchanges, wallets, and issuers of the future"
- After: "will greatly benefit exchanges, wallets, and issuers"
8. Optional ERC-165 support clarification (normative level: `MAY`).
- Change note: Implementations MAY add ERC-165 interface detection for ERC-1404.
- Rationale: `MAY` is used instead of `SHOULD` or `MUST` because ERC-1404 is an older standard and ERC-165 was not mentioned in the original version.
_Implementations MAY add ERC-165 interface detection support for ERC-1404. The ERC-165 interface identifier for ERC-1404 is `0xab84a5c8`._
## Additional Changes Applied (eipw validation + content clarifications)
1. Title changed to satisfy lint rule.
- Before: `Simple Restricted Token Standard`
- After: `Simple Restricted Token`
- Reason: `preamble-re-title` rejects titles containing words like "standard".
2. Added missing preamble `description`.
- Before: no `description` header.
- After: `description: A token interface extension for enforcing transfer restrictions with machine-readable status codes.`
- Reason: required by `preamble-req`.
3. Removed top-level `#` heading.
- Before: `# Simple Restricted Token Standard` directly below preamble.
- After: removed.
- Reason: EIP/ERC docs use `##` section structure; avoids redundant heading and keeps structure clean for lints.
4. Removed `## Simple Summary`.
- Before: file contained a `Simple Summary` section.
- After: section removed.
- Reason: repo `config/eipw.toml` `markdown-order-section` allows only:
`Abstract`, `Motivation`, `Specification`, `Rationale`, `Backwards Compatibility`, `Test Cases`, `Reference Implementation`, `Security Considerations`, `Copyright`.
5. Linked first mentions of proposal references.
- Before: several first mentions of `ERC-20`, `ERC-1404`, `ERC-165` were plain text.
- After: first mentions use markdown links.
- Reason: satisfy `markdown-link-first`.
6. Removed non-relative body links.
- Before: external GitHub links in body and CC0 external URL.
- After: external body links removed; copyright link uses `../LICENSE.md`.
- Reason: satisfy `markdown-rel-links` policy in this repo.
7. Replaced non-standard section with canonical sections.
- Before: `## Test Cases & Implementation`.
- After: `## Test Cases` and `## Reference Implementation`.
- Reason: satisfy `markdown-order-section`.
8. Added missing `## Security Considerations`.
- Before: section absent.
- After: section added.
- Reason: required by `markdown-req-section`.
9. Updated transfer failure semantics to match ERC-20 behavior.
- Before: restriction failure text implied revert-only behavior.
- After: text states failure MAY return `false`, with revert RECOMMENDED.
- Reason: align with ERC-20 note that callers must handle `false`, while preserving strong recommendation to revert.
10. Updated test expectations for failure behavior.
- Before: test bullets required revert on restricted transfer.
- After: test bullets accept both revert and `false`, with revert preferred.
- Reason: reflect ERC-20-compatible implementations and current spec text.
11. Adjusted ERC-165 note in Security Considerations for historical compatibility.
- Before: generic "if ERC-165 is exposed, signaling must remain consistent" guidance.
- After: explicit note that original ERC-1404 did not require ERC-165 signaling, so older implementations may implement ERC-1404 while not returning `true` for `0xab84a5c8`.
- Reason: improve historical precision and avoid over-constraining legacy implementations.
12. Removed redundant motivation sentence.
- Before: `A widely adopted standard for detecting restrictions and messaging errors within token transfers will greatly benefit exchanges, wallets, and issuers.`
- After: removed.
- Reason: streamline prose; sentence repeated already established motivation.
13 Rationale intro wording made less conversational.
- Before: `The standard proposes two functions on top of the [ERC-20](./eip-20.md) standard. Let's discuss the rationale for each.`
- After: `The standard proposes two functions on top of the [ERC-20](./erc-20.md) standard. The rationale for each is described below.`
- Reason: align tone with modern ERC style (formal/spec-oriented wording).
14. Motivation wording simplified.
- Before: `A few emergent examples:`
- After: `A few examples:`
- Reason: remove unnecessary wording and improve readability.
15. Neutralized subjective phrasing.
- Before: `Additionally, we see fit to provide a pattern ...`
- After: `Additionally, this standard provides a pattern ...`
- Reason: align style with formal ERC specification tone.
16. Rationale lead-in wording formalized.
- Before: conversational phrasing (`Let's discuss the rationale for each.`)
- After: neutral phrasing (`The rationale for each is described below.`)
- Reason: align with modern ERC editorial style.
17. Security note added on restriction code space.
- Added: using `uint8` for restriction codes limits available values to 256 (`0`-`255`), with guidance to manage code allocation carefully.
- Reason: make implementation constraints explicit for interoperability and maintainability.
---
eip: 1404
title: Simple Restricted Token
description: A token interface extension for enforcing transfer restrictions with machine-readable status codes.
author: Ron Gierlach (@rongierlach), James Poole (@pooleja), Mason Borda (@masonicgit), Lawson Baker (@lwsnbaker), Ryan Sauge (@rya-sge)
discussions-to: https://ethereum-magicians.org/t/erc-1404-simple-restricted-token-standard/1405
status: Draft
type: Standards Track
category: ERC
created: 2018-07-27
requires: 20
---
## Abstract
Current token standards have provided the community with a platform on which to develop a decentralized economy that is focused on building Ethereum applications for the real world. As these applications mature and face consumer adoption, they begin to interface with corporate governance requirements as well as regulations. They MUST not only be able to meet corporate and regulatory requirements but MUST also be able to integrate with technology platforms underpinning their associated businesses. What follows is a simple and extendable standard that seeks to ease the burden of integration for wallets, exchanges, and issuers.
## Motivation
Token issuers need a way to restrict transfers of [ERC-20](./eip-20.md) tokens to be compliant with securities laws and other contractual obligations. Current implementations do not address these requirements.
show original