EIP-4974: Ratings

I agree with @fulldecent , a token that cannot be transferred is not a token imho. The function transfer is the very essence of tokens. I’d rather define a kudos interface completely unrelated to erc20 or tokens.

1 Like

Read through this spec, as I’m thinking about this kind of token too! I think after reading the spec and all the comments and revisions, I agree with @fulldecent 's original take on this, though. I think a restricted ERC-20 is probably the best way to go about this.

My main reasoning is it seems at this point that the only thing that is really added to the diff between this and ERC-20 (other than mint and burn, which I agree with an earlier commenter that it doesn’t make sense to put that into the spec. Reason being its very likely specific EXP implementations would need different function arguments for those functions, for things like signatures. This is why it’s not in any of the ERC-20 specs or extensions) is the concept of “Participation.”

While I think the intention is good, I don’t think it will achieve what you intend. Assuming the intention is that people won’t randomly be assigned some of these “points” without their consent, it’s easy to follow this spec while still violating this property.

For example, someone could write an implementation that emits the Participation event with true when a mint function is first called for the user, regardless of whether they actually participated. This kind of thing is ultimately always going to be up to the specific implementations of a token, and it’s going to be up to the clients displaying info to end users to counter abuse (as it already is today with token filters and such).

If someone wants to create this opt-in participation in being able to transfer ERC-20s, that’s fine. But the design surface area for the variety of ways to do that is so large, I’m not sure it makes sense to standardize that.



Beyond actual game experience point implementations, we’ve thought of a few potential ones:

  • Reddit-like Karma
  • DAO delegation of authority levels
  • Loyalty points from a business
  • Ratings for contenders in sports or other competitive leagues.
  • Credit scores (Ugh that feels dystopian, but at least it’d be more transparent and trustworthy than current credit scoring systems around the world…)
  • Kudos given for contributions of some sort, i.e. for volunteer hours at a nonprofit

@dadabit also brought up the EXP name question recently. I think experience points is a more vivid description than the others considered, but I’m open to changing it. Happy to discuss dropping “token” language altogether, but at this point I think that’s a bit extreme. The Kudos Standard? Or more verbose, The Experience Points Standard? More synonyms for “kudos”.

From the latest rationale section of the EIP:

EXP Word Choice

EXP, or experience points, are common parlance in the video game industry and generally known among modern internet users. Allocated EXP typically confers to strength and accumulates as one progresses in a game. This serves as a fair analogy to what we aim to achieve with ERC-4974 by encouraging members of a community to have more strength in that community the more they contribute.

Alternatives Considered: Soulbound Tokens, Soulbounds, Fungible Soulbound Tokens, Non-tradable Fungible Tokens, Non-transferrable Fungible Tokens, Karma Points, Reputation Tokens

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:

  1. Only the operator can transfer EXP. Other accounts have no ability to obtain or dispose of EXP.
  2. 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 :sweat_smile:. 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.

1 Like

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.

Maybe this deserves another thread. I’m confused.


Here is my overall guiding principle:

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.

Hi @dtedesco1,

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.

1 Like
  • 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.

Oh, nvm, I see you are talking about being able to burn.

So this is like reputation points on StackOverflow.

1 Like

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.


Thanks for the encouragement, Tim! I will take a fresh look at this soon. Some folks are overdue responses and I’ve got to clean up the PR.

1 Like

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 :slight_smile:

1 Like

I was looking to implement a karma-like system, no update on this?

1 Like

We have gone through several iterations and just completed the Draft stage. Now we are moving the EIP into Review: Update EIP-4974: Move to Review by dtedesco1 · Pull Request #6334 · ethereum/EIPs · GitHub

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?

1 Like

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?

1 Like

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 don’t believe there’s a “need”, as much as a “desire” — “a desire exists for…”.

Maybe Reddit will integrate with ethereum so that you can carry over your social points from their centralized platform.

This might open the door for China to integrate their social points system as well, which might be the motivation / desired purpose?

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?

Layer 1 doesn’t “need” a social credit system.