🌱Alpha Version

A DAO experiment based on Soulbound Tokens

EtherScore Alpha Version is the first step towards experimenting with Soulbound Tokens and their use (starting with DAOs). The scope of the alpha version is deliberately limited to very basic NFT badges, features and benefits. The EtherScore Genesis collection, the first set of EtherScore NFT badges, is a DeSoc experiment designed to curate blockchain users. The goal is to try to identify users that might be considered as reputable, or contributing positively to blockchains ecosystem, to give them benefits (starting with EtherScoreDAO access). The first experiment consists of selecting a small set of users being able to vote on how we should expand the community itself.

EtherScore Genesis DAO

In order to explore how to overcome the limitations of the current 1-token-1-vote paradigm, we will release our DAO and limit the vote access to the addresses having claimed any badge. DAO voting power will be determined based on the amount of badges owned by addresses (i.e. an address having claimed 5 EtherScore badges will have a voting power of 5 in the EtherScore DAO). Later versions of EtherScore will define more specific vote weights on badges, notably when there will be different levels of badges (example: make 5 swaps on Uniswap, 10 swaps, 50 swaps).

The first DAO proposals will consist of helping us to define which badges will be added to the EtherScore Genesis collection to give access to the DAO and further proposals. Proposal creation will be restricted to the core team before having a consequent community, however discussions will take place in our Discord to allow early adopters to give their opinions and suggestions. Next versions will include a process for the community to directly propose badges. The EtherScore community will then grow iteratively by adding new cautiously selected badges. The objective is still the same, targeting specific audiences of users that can be considered as reputable, real humans, blockchain enthusiasts, and trying to favor usage over speculation.

At first, all badges of the EtherScore Genesis Collection will give the same benefits: access to EtherScore DAO, specific EtherScore Discord channels etc. However, such holders will be considered as early adopters and will see a lot of other benefits announced later.

To know how to claim a badge please go to our tutorial page.

Why call it an ‘experiment’?

Because there is still a lot of work to be done to define Web3 reputation and its use cases. The recent publications on Soulbound Tokens [1] [2] have pushed the concept of non-transferable tokens, or NFT badges as we called them, to a certain degree of popularity. It is now quite a common belief that reputation systems will have a place in Web3 but various approaches need to be experimented and the standard of such tokens is still not defined. Each protocol or application has a different perception of what constitutes reputation, which makes it impossible to create one size fits all reputation for everyone. It is crucial for Dapps to have some tools to experiment and iterate with their community to define their own specifications of reputation by themselves.

In addition, we are aware of some limitations:

  • Ability to select a diverse community of early DAO participants: We have to choose who will define the eligibility criterias of EtherScore badges and their benefits. In order to accomplish this, we strive to build a community of Web3 domain experts and users who do not have the same biases or conflicts of interest. People from the same community might favor close friends (or speculation) over other groups, creating inequality instead of building a legitimate community. To try to induce such partiality, we want people with a variety of skills and interests over all categories of Dapps to group them around the objective of building a decentralized reputation system.

  • Ability to limit the cold start problem: We must not create a high entry barrier for newcomers. The challenge is finding criteria that are not dependent on any particular amount of money or cryptocurrency. The last thing we want to create is a system where large capitals are favored over small ones. However, as most uses of blockchains today remain in the DeFi ecosystem, the reputation already gained by users is mainly about this particular purpose (number of swaps, loans, etc). With time, other uses will be democratized and reputation will be more and more sourceable from other categories of Dapps such as social networks, games, etc.

  • The lack of community recovery mechanisms: On-chain reputation must not be transferable but it should be possible to recover it (to get back tokens in case of a compromised address such as a hack, loss of key, etc.). Yet there is no such mechanism widely adopted by users, and to integrate such a mechanism we need mature products that avoid cases of users buying/selling their reputations. In the meantime, EtherScore users will not be able to reissue their badges and will lose their ‘reputation’ in the event of a compromised address (just as it would be with any other asset such as ERC20s and NFTs held by the address).

  • Sybil attacks: It is difficult to be sure that 1 human = 1 address to avoid bots, airdrop farmers, etc. EtherScore will integrate with systems such as proof of personhood protocols and identity aggregators to perform such verification and provide a range of options to badge issuers (Gitcoin passport, Proof of Humanity etc.).

  • Limited capabilities of decentralized datasources: we have limited capabilities to provide blockchain analytics without being a centralized entity. Indeed most pertinent data are not available directly on the chain and must be computed off-chain by performing data indexation, aggregation, and contextualization. But to have a resilient, uncensorship, and unbiased reputation system, EtherScore must not process and maintain the data by itself (or neither use web2 services). Therefore we are relying on data indexers such as The Graph Protocol and Chainlink oracle to get the data, but some tasks such as conditions checking must still be performed by us in the first versions. To replace our centralized component, we are studying several alternatives that will be communicated later.

  • Privacy concerns: While we are aware of dystopias involving SBTs and privacy issues, EtherScore focuses on using data that are already publicly available due to the transparency of blockchains (or which can be deducted from the list of transactions performed by an address). In addition, providing privacy to such tokens enables users to hide specific parts of their profiles including ‘bad reputations’ / negative SBTs which could be used in a lot of use cases. As a result, users may choose what information they want to disclose and lie about their interests, for example.

Last updated