The standard itself doesn’t really need to describe how to “mint” a token. You can take a look at ERC20, ERC721 for reference. But implementations of the standard will contain that function. Ideally people don’t implement directly the standard but extend from an existing implementation (like the ones of OpenZeppelin). I made an implementation myself: Non-Tradable-Token/contracts at master · OmarAflak/Non-Tradable-Token · GitHub
Without EIP-4671, you’d need to run this computation each time you needed to check if the EOA is synthetic. This is relatively gas-expensive and gas-variable because you may need to cycle through a few values of r and run ecrecover multiple times. Not great.
With EIP-4671, a NTT could be created that checks if an account is synthetic, then issues the EOA a token identifying it as such. Now any smart contract wishing to identify synthetic EOAs and coded to assume the presence (or absence) of this NTT can simply check the address in question for the NTT.
Synthetic-ness can now be checked w/o the digest and “c”
Less gas usage
Predictable gas usage
As I said before, the uses cases for this EIP will be myriad and impactful. IMO, it should be finalized and adopted ASAP.
I think there are no situations where the token should not be revokable. A certificate can always be delivered by mistake, and the authority who delivers should be able to revoke it. Although the record should show that you once owned a token from that contract, so it must not “disappear”.
This is why each token has a isValid(tokenId) returns (bool) property. But I didn’t specify how the token should be invalidated (or revoked) because it seems as an implementation detail. It’s more general to have a boolean that states if the token is valid or not. Different implementation could choose how exactly to invalidate the token, e.g. based on an expiry date as you suggested, or anything else.
Yes sorry- I envision both self-mints and airdrops being relevant use cases. So I’m just curious if there’s an expectation to assign a token that can’t be traded, but maybe can be burned. For example, maybe a professor assigns a NTT to a student. The student can’t sell/trade it, but can burn.
I feel that it depends how you see these NTT in general.
If you want to burn a token it means you’re not happy that it’s been assigned to you publicly. For instance if it’s a criminal record (even though I don’t think this would ever be on the blockchain). There is no good solution:
1- If you allow people to burn tokens, then it doesn’t fit the use-case of the criminal record example or any other where you’re labeled against your will (which is a good thing I think, we don’t want to end up with a social score on the blockchain…).
2- If you don’t allow to burn tokens, you can be assigned tokens from random contracts you might not want to be associated with.
I think the way to see this is that non-tradable tokens are not meant to represent anything too sensitive that you don’t want to expose. They’re only a proof of (good) achievement(s). Something that you’re willing to display publicly. And the importance tied to a NTT should come from the authority that delivered it. If some random guy gives you a jail-token, it shouldn’t matter because that person is nobody. Also, this is why the standard outlines a NTT Store, which is a way for you to expose in one place a subset (possibly all) of our tokens, and share them with an external service.
The Non-Tradable Token standard has been merged as a draft!
I’m planning on changing a few things. Mainly:
Currently the NTT Store allows you to make a display/collection of NTTs coming from different contracts but that only belong to one address. I think in practice people will have their tokens delivered to different addresses. So I want to make it possible to build that collection from multiple sources addresses.
I want to add a hash of the data associated to tokenURI
(to be discussed) I want to add a key/value store to a token contract. The hash could be one of the keys…
I think it’d be better if EIP-4671 referenced ERC721’s and implemented its interface. I also gave soulbound tokens a shot, and I think that’s the better approach as it’d allow ERC721 wallets to be instantly compatible with Non-tradable tokens.
What is being defined in ERC-4671 is beyond the scope of what a standardized Solidity interface can guarantee. For me, I’d have no issue just standardizing the “Non-Tradable Token” as defined in the “Specification” section.
However, I think most of the extension code isn’t useful to have in an EIP. Ultimately, we’d like machines to be able to rely on an interface that doesn’t change and where we can safely expect a reasonable behavior implemented below. For E.g. it’d be outrageous if ERC20's transfer function would do something else but transfer tokens. However, with e.g. IERC4671Consensus I doubt every other implementer is capable of replicating a compatible behavior or usefulness from this interface definition.
My suggestion is simply to standardize the first “Non-Tradable Token” section.
Untradable and absolutely bound to the wallet is based on the assumption that one person, one wallet. In fact, wallets will be changed for various reasons, such as private key leaks, and I think it should be transferable, limited to non-exchangeable tokens, and better only to be sent. But this led to a new problem, the private key was leaked and my “graduate certificate” was transferred.
To simulate a graduation certificate, can we change our thinking, keep the graduation certificate information on the contract address, and use it to prove that it belongs to me by binding the query word or query code. Or use the connection wallet address to query.In this way, even if my private key is leaked, the tokens in it can be transferred while keeping “my diploma”. The graduation certificate should contain all relevant information, such as name and ID card. Key privacy information such as ID card number can be verified by password. The password is similar to the private key and needs to be recorded by the owner.
Hi guys! @omaraflak, thkx for great work on this EIP.
I am seeing potential in this and find this great point to jump in this magical forum to join the conversation
Proposal for this standard:
Replace isValid/hasValid and revoke() with burn()
Structure is similar to ERC721Burnable without transfer methods, meaning less adaption friction for the standard.
Checking ownership of the token becomes easier (checking side can just make sure that token is not listed in enumeration).
Token standard heads toward Non-Tradability, however one should not put limitations on ability to non-tradable transfer scenario. Which burn is - I assume it is true.
Revoking and re-issuing token takes form mint-burn-mint which is convenient approach which many developers use already today
More secure. Token could be flash-toggled and contracts relying on this must assume that state of the token can toggle multiple times over a block. Resulting tradability of token state. In Mint/Burn scenario checking token ownership by id allows to rely on that state can change only once - to burn.
Also what is purpose use of holdersCount/emittedCount and why Enumerable does not has totalSupply() interface?
Thats my first post on the forum, if this discussion fits more in github or elsewhere just let me know,