Thanks for this feedback. I’m also agreed that mint and burn are not sensible here. You brought up two other major topics:
EIP-4974 versus existing token standards
Participation is definitely critical, but from my understanding there are two core, unique components of the 4974:
Only the operator can transfer EXP. Other accounts have no ability to obtain or dispose of EXP.
An account must set themselves as participating before any tokens can be received.
Implementing ERC-20 or ERC-721 to allow for these two components is simply not implementing ERC-20 or ERC-721. I think that’s the crux of @fulldecent 's post above, but please correct me if I’m wrong.
Potential loopholes
We can’t control if someone writes a smart contract claiming to follow a standard while quietly not following the standard, but you’re right we should be clear in the spec about what clients should expect and test for.
Thanks for pointing this out. Simply emitting a Participation event in this way shouldn’t have any impact on the operator’s ability to transfer to an address, but it would certainly be confusing. I’ll add a clause to make this explicit for each of the events, like so for Participation:
/// This event MUST ONLY be emitted by setParticipation.
I’m keen to examine more examples like this. Do you see any other logical holes for implementers to abuse the spec?
Right, but like I explained in my post, you can’t really enforce that with a specification. I think this is more appropriate as a token protocol (ie. tokens created from a base contract that can actually enforce these rules) than an EIP, in my opinion. Then, it’s easy for clients and smart contracts to trust the child tokens, because it can be easily verified that Participation is enforced at the code level!
I think you misunderstood what he is saying, actually. He’s saying that what you describe fits as a subset of the ERC-20 standard, so you can just go ahead and implement it without needing a new spec.
Neither of those two points goes against the ERC-20 spec. The ERC-20 spec does not specify how tokens can be minted or burned. And as for restricted transfers, everyone considers USDC an ERC-20, and that has a blacklist for interactions. This is no different! I’d say go with @fulldecent 's recommendation and just go for it, no need for an EIP!
Well what I’m saying is, abusers don’t tend to follow the rules . My point is, you can specify all the rules you want, the nature of smart contracts being self-sovereign and EIPs simply being agreed-on guidelines means they aren’t really too useful for preventing abuse. If someone creates a token meant to harm people, clients with filters tend to hide them pretty quick, regardless of what EIPs they follow. I’m not sure this adds enough to warrant an EIP, for that reason.
Thanks for these comments @carlosdp, and I really appreciate the discussion you and @TimDaub had in the thread on EIP-4973.
On @fulldecent’s weekly community service hour livestream, I asked about EIPs. We didn’t discuss his comment above specifically, but I’m now convinced that your interpretation is right and mine was wrong. I was probably swept up in confirmation bias and excitement about my new idea.
I don’t want to create a standard that’s meaningless and no one will use. I’m genuinely unclear about what’s useful, though.
Where’s the line? How reductionist should we be?
At one extreme, we can argue every EIP should rather just be an optional extension to some other, more fundamental one. At the other extreme, I can envision every fly-by-night pet project getting its own ERC.
First build something. Then standardize it. And the “something” should include some producer and some consumer of information.
And a second one:
The purpose of standardizing something is to invite more people to play in your sandbox. The best way to get more people in your sandbox is to already have some friends in the sandbox.
ERC-721 is an example of something that was build–including multiple producers and consumers–before standardizing. The producer is the NFT contract, like some token that represents artwork or identity on-chain. The consumer is something that wants to query that information like Etherscan or MetaMask. Only by considering the needs of people on BOTH sides of that producer/consumer fence were we able to make the biggest impact. The end result is Etherscan fully supports ERC-721 and MetaMask finally started (barely) supporting most of it four years later and after every newspaper on earth was talking about this technical standard on its front page [citation needed] at some point. You might say MetaMask was brought along kicking and screaming.
Compare that to my recent experience in Estonia last week at NFT Tallinn. There were at least 5 companies focused on creating an NFT/fungible token for tracking carbon credits. (This is typical for an NFT event.) Few, if any, people are actually using their products. Standardizing any of that now would be a disaster. Four years from now barely anybody will have been attracted to connect onto their sandbox. And when they start connecting, they will learn some important thing they wish they know at the time of standardization. And the result will be… fragmentation with a new standard. That is the worst-case outcome for a standard.
Just as a tiny note, the standard could simply state exactly what happens if you call the disabled ERC-20 functions, and add a new ERC-165 interface for wallets to query to check if a token is an EXP.
Edit: hm, actually you’d probably want a whole new interface that defines ERC-20 compatible functions, but not advertise ERC-165 support for the ERC-20 interface.
I like the idea of a reputation token standard and have been thinking about it as well.
Here are some of my thoughts:
Reputation tokens are hard to earn, but easy to burn.
Reputation tokens cannot be transferred (period), but can be minted and staked.
Reputation token supply is inflationary. Total supply of reputation tokens is constant increasing so that reputation loses value over time and must be continuously earned for an owner to maintain their share of reputation tokens.
There are lots of things to work out, but a real-world example has helped me think about this. I started life as a physicist, but switched to finance ages ago. My first job in asset management had an interesting flat culture. The management team rotated every year. My office was next to the founder’s grandson and was the same modest size. No corner offices. Also, everyone in the investment team bent over backwards to help me. It was great. The way it was explained to me, everyone was enthusiastic about helping me because the sooner I got up to speed, the sooner I could help them. Sounded great. But when my first annual review came around, I learned there was a more pragmatic reason why everyone was trying so hard to help me. I received an odd email saying that I had 10 points that I could allocate to colleagues with a maximum of 5 points to any one person and could allocate to at most 10 people (1 pt each). I didn’t have to allocate any if I didn’t want to. The basis for allocation? We were to allocate points to colleagues who we felt had helped us do our jobs better the previous year. Bonuses were largely influenced by how many points you received. I always thought that was a great was to incentivize a helpful culture. Now, it seems like a total no-brainer to tokenize this concept.
With this in mind, I am thinking that once someone has achieved a certain level of reputation, e.g. maybe owning 1 reputation token, they are periodically, e.g. once a month, allowed to mint (not transfer) a limited number of tokens to others who they feel have helped them or helped the project.
The natural use case for reputation tokens would be DAO governance as means to combat the current plutocracy of purchased governance tokens. Rather than buying votes, you earn votes via reputation and you vote on initiatives by staking your reputation on them. The amount you can stake is tracked similarly to how allowance is currently tracked in ERC-20.
Need to think about Sybil attacks. Maybe some kind of modified quadratic voting?
Edit: Btw, if there is a non-transferrable token standard, I think it should also contain a consent mechanism, e.g.
Reputation tokens cannot be transferred (period), but can be … staked.
This is contradictory. Staking implies transferring. Or more specifically, staking means not being able to transfer something that you were previously able to transfer.
As I regularly get approached by people about Soulbound tokens, and especially now at devcon, I’ve pointed people here a couple of times already. I think the idea of fungible but non-transferrable points, aka experience points, resonated with many people. I’d encourage you to pursue this @dtedesco1 further.
Hey, just wanted to add that I’m using this EIP as a starting point for social tokens that can actually be redeemed for prizes. This is for an NFT project who has a “points” system for people who buy an NFT from the collection, or buy physical art from the artist behind the project. The social points are then used to redeem prizes (like 10% off) on the artist’s shop and burned. The concept of having an operator (the artist in this case) and non-transferable (between individuals), non-valued tokens is a perfect fit for what we’re wanting to experiment with.
I’ll come back to post my implementation once I have it done, but just wanted to say that I really appreciate the thought put into this EIP, which gave me a much-needed starting point for this project. I look forward to seeing where it ends up!
EDIT: Wanted to post what I’ve put together in case anyone is curious to see a non-perfect implementation
In addition to what @0xThresh is working on, it’d be great to have more implementations during the Review stage. Do you want to share what your working on @donnoh and we can see if it’s a good fit?
I’m trying to implement a DAO model focused on education where a teacher (or coordinator) gives access to others via non-fungible SBTs (credentials) and can grant voting rights using fungible SBTs (karma points) based on course votes or other virtuous behavior. The teacher has a fixed amount of karma (like 50% initially) so the DAO tends to decentralize over time. I already implemented non-fungible SBTs following ERC-5192 which is compatible with EIP-712, so I thought it would make sense to also have fungible SBTs to be compatible to ERC-20, what do you think?
This use case sounds compatible. EIP-4974 ratings are similar to fungible SBTs, but–unlike ERC-20-like tokens–ratings can be negative, in case you need to identify malicious or low reputation accounts. This may be useful in a highly decentralized environment. Happy to discuss more over DM/call, and even help write some code, if you want to try implementing. Let me know.
I’m sure the normies will love getting pegged with unwanted titles they didn’t ask for. Especially ones that come from authorities they don’t necessarily wish to associate with.
“Daddy government, I paid the bribe and served the time, can you please remove that title from my universal identity account?”
Maybe someone else is who you don’t want the title from, and whom refuses to remove it. In that case does the target user demand to speak with the Ethereum department manager, or should they call you directly to complain about the ruining of Ethereum?
It’s important to consider potential nefarious use cases of any potential standard. The issues you raise are noted in the Drawbacks section of the latest version of this EIP:
Drawbacks
One potential drawback of using this standard is that ratings are subjective and may not always accurately reflect the true value or quality of a contract or wallet. However, the standard provides mechanisms for updating and removing ratings, allowing for flexibility and evolution over time.
Users identified in the motivation section have a strong need to identify how a contract or community evaluates another. While some users may be proud of ratings they receive, others may rightly or wrongly receive negative ratings from certain contracts. Negative ratings may allow for nefarious activities such as bullying and discrimination. We implore all implementers to be mindful of the consequences of any ratings systems they create with this standard.
As it’s is still in review, feel free to make suggestions on how to improve this section or other parts of the EIP.
. My point is, you can specify all the rules you want, the nature of smart contracts being self-sovereign and EIPs simply being agreed-on guidelines means they aren’t really too useful for preventing abuse. If someone creates a token meant to harm people, clients with filters tend to hide them pretty quick, regardless of what EIPs they follow. I’m not sure this adds enough to warrant an EIP, for that reason.