RFC for Extending Schema Metadata to include an Reputation Object Model


We propose adding a field to the schema metadata which links to an attestation that describes the representation of reputation within a schema. This is a standard way to describe the representation of reputation, without having to require the schemas themselves to adhere to any specific standard, but which will make interpreting the various reputation attestations much easier for developers.

Problem Statement

There are a growing number of reputation protocols gaining increasing adoption across web3. Use cases vary from proof-of-humanity, to trust scores for dapps and smart contracts, to developer profiles, to web3 user profiles derived from on-chain activity and more. As the space matures and continues to grow, there will be an ever increasing variety of reputation protocols, as well as a wide variety of on-chain representations of reputation derived from web3 sources.

This will represent a challenge to the ecosystem in terms of how we understand and consume these reputation scores and profiles. In its current form, end users struggle to understand the idioms of individual reputation scores (e.g. it might not be obvious that a GitCoin passport score > 20 means your human, or a Trusta Labs Sybil score < 60 means your human). Moreover, there is an overhead for developers that wish to consume reputation scores in understanding how individual scores are structured and how to interpret them.

One of the main motivations for establishing an on-chain attestation registry is to provide a consolidated location on-chain for schemas and attestations in order to make them easier to discover and consume and compose. However, providing a consolidated location on-chain does not go far enough in this regard. There is still fragmentation within the various schemas in the registry, which impedes the developers ability to effectively use the attestations that are based on the schemas within their dapps and protocols.

The root of the problem lies in the fact that the specific context of a reputation score isn’t included alongside the reputation score itself. Furthermore, reputation evolves over time, is utilized within different contexts, and each field within a reputation attestation may have its own data sources and requirements. It is therefore unlikely that a standard format for reputation attestations can be established successfully.

We therefore propose a Reputation Object Mode (Alnemr et al. 2010) as a standardized format for describing reputation schema. This will allow attestations that are based on those schemas to be easily interpreted by observers, without requiring those observers to have any prior knowledge or familiarity with the schema or the attestation issuer, and without requiring attestation issuers to adhere to any specific standard.

Proposed Solution

We propose extending the schema metadata to include reference to a Reputation Object Model, which is a specific attestation that is linked to a schema. The linked attestation is based on a standard Reputation Object Model (ROM) schema, and describes the representation of reputation with the reputation schema.


Portability of reputation

A ROM allows consumers of reputation attestations to understand how to use the attestation, it allows them to understand what the possible values are and what the recommended threshold is, and therefore how they can actually use the attestation in their dapp / protocol. This information is linked directly with the schema and is instantly accessible.

Allows for easier composability of reputation

A ROM allows for composing attestations together to form a narrative or picture of the attestation holder. For example, we could combine a Nomis Score and an Aspecta Builder Profile with a Clique Twitter Followers attestation. It becomes much easier to understand how to consume the various attestations and to calculate a meta-score based on the combination of values from each attestation.

Allows for visualization of reputation attestations

Currently, users are looking at a list of attestations that does’t convery any meaning. A simple visualization will help to understand what their reputation attestation works, and how they can improve their reputation, and what the advantages are of doing this. Giving developers the means to easily visualize reputation attestations is a powerful and transformative primitive that would greatly improve the user experience.

Improves interpretability of reputation attestations

Makes it easier to interpret reputation attestations, and allows observers to more easily understand how attestations are interpreted differently in different domains. The recommendedThreshold parameter gives explicit guidance to consumers of attestations as to how they can use the attestation, e.g. the recommendedThreshold for GitCoin Passport Score is 20. Other dapps may decide to require a greater score, but at least dapps can have a recommended threshold to work with initially.


A Reputation Object Model model, hereafter referred to as a ROM, is a separate document that is linked to from a schema’s ‘context’ property, and its purpose is to describe the representation of reputation in a structured and standardized manner.

A schema’s ROM is composed of the following properties:

struct DecayFunction {
    uint8 base;
    uint8 degree;
    uint256[] coefficients;

struct Criterion {
    string possibleValues;
    string recommendedThreshold;
    DecayFunction decayFunction;

struct ReputationObjectModel {
    Criterion[]: criteraList;
    string collectingAlgorithm;
    string computationAlgorithm;
    string documentation;

An explanation of the properties of the Reputation Object Model is described in the table below:

Property Description
criteraList A collection of Criterion objects. Each criterion has a possibleValues property, which can be either a range, enum, or orderedList.

e.g. range [0,100], or orderedList [“bad”, “average”, “excellent”], or enum [“developer”, “founder”, “researcher”]

Each criterion also has an recommendedThreshold, which is signed integer.

For a range, this is the value which determines whether the attestation is deemed valid, e.g. “20” to indicate that the reputation value should be greater than 20, or “-60”, to indicate the reputation value should be lower than 60.

For an orderedList, the recommendedThreshold is the value after which the attestation is valid.

For an orderedList, the recommendedThreshold is a m-of-n value, e.g. “must have any 3 of the 5 possible values to be regarded as valid”.

The decay function describes how each criterion decays, or diminishes in value over time. It is described as a polynomial which allows for the expression non-linear decay function (perhaps the rate of decay accelerates over time), or linear, whereby a polynomial of mx+b can be described as base: 11, degree: 1, coefficients: [3, 2].
collectingAlgorithm This should be a URI which links to some documentation which outlines where the data upon which the reputation score is calculated is sourced, and how it is collected.
computationAlgorithm This is either a description or a URI (though preferably a URI) which contains information on how the reputation values are calculated. The calculation can be based on any number of reputation algorithms, e.g. collaborative filtering, bayesian models, eigentrust etc. but the information should help developers to understand how reputation scores are calculated.
documentation The value of this property should be a URI, at which is found documentation that helps both users and developers to understand how the reputation attestation can be useful. Crucially this documentation should help users to understand how to improve the value(s) in the reputation attestation.

Relation to Context Property

The existing context property should ideally be embedded in the Reputation Object Model, however, the context property is hugely important for discoverability, and probably needs its own dedicated property within the schema metadata.

The context property should link to a common ontology, which allows for deriving semantic meaning for a schema. This will dapps to query the registry in terms of “give me all attestations of type “https://schema.org/Person” issued to wallet address 0xab27cf…

A common ontology would allow dapps to run queries like: “give me all attestations issued to this address that represent a human”. Dapps won’t need to know schema ids and which issuers issue attestations that prove humanity, they can just search by context.

It is becoming increasingly clear that we need to create our own ontology, and let it grow organically. This work is already underway with several collaborators and is therefore out of scope of this proposal.


Below is an example of how Trusta’s Media Score would be represented by a ROM:

    "criteriaList": [{
        "name": "sybilScore",
        "possibleValues": "range [0,100]",
        "recommendedThreshold": -60,
        "decayFunction": {
            "base": 10,
            "degree" 1,
            "coefficients": 30
    "computationAlgortihm": "https://trusta-labs.gitbook.io/trustalabs/trustgo/media-scoring-methodology",
    "documentation": "https://trusta-labs.gitbook.io/trustalabs/"

Open Questions

  • Can the above ROM be used to reference reputation attestations that are based on schemas that have complex data structures? The name property is used to reference a property in the schema, but is this sufficient in order to reference properties within nested objects?

  • Should we maintain a one-to-one relationship between schemas and ROMs? Should we allow a schema to have multiple ROMs?

  • Is the decay function useful and will it be used? On one hand it allows for dynamically changing reputation values inside of an attestation. On the other hand, perhaps attestation issuers are only interested in issuing static values to avoid ambiguity or misinterpretation.

  • Should we add a property to the Reputation Object Model called intendedUse. This may be useful for attestation issuers that wish to qualify their attestation with a stated indeed use, for example, an issuer of a social account attestation may wish to state “I don’t stand over this to the degree that it can be used to prove a person is over 18”. Conversely, a KYC issuer may wish to say “I stand over this attestation and I fully attest to the fact this is a real person”.

  • Should the possibleValues property by split into possibleValuesType (e.g. “range”, “enum”, “orderedList”) and possibleValuea which is simply an array? Would this make it easier to parse?


The concept of the Reputation Object Model was first described in this paper:

Enabling Reputation Interoperability through Semantic Technologies

Alnemr, Rehab, Adrian Paschke, and Christoph Meinel. “Enabling reputation interoperability through semantic technologies.” Proceedings of the 6th International Conference on Semantic Systems. 2010.

Reputation Objects for Interoperable Reputation Exchange: Implementation and Design Decisions
Alnemr, Rehab, and Christoph Meinel. “Reputation objects for interoperable reputation exchange: Implementation and design decisions.” 8th International Conference on Collaborative Computing: Networking, Applications and Worksharing (CollaborateCom). IEEE, 2012.

From Reputation Models and Systems to Reputation Ontologies
Alnemr, Rehab, and Christoph Meinel. “From reputation models and systems to reputation ontologies.” Trust Management V: 5th IFIP WG 11.11 International Conference, IFIPTM 2011, Copenhagen, Denmark, June 29–July 1, 2011. Proceedings 5. Springer Berlin Heidelberg, 2011.

1 Like

It’s a very comprehensive proposal for ROM. generally agree with the ideas and proposed syntax. One question is do the decay functions (polynomials) suitable for the model? Or can we find a more generic way to define the dynamic calculation here?

That’s a good question @Fubiao . I suspect that the decay function might be over-engineered, and in fact it may never be used, or if it is used, it may just be used as linear decay function. It occurred to me that the decay function might not even be necessary, as if a decay function exists, then it would be calculated as part of the computationAlgortihm, and therefore may not need to be part of each criterion.

@simon.brown I agree. Here we might need some inputs from ROM experts like Trusta or other team. From the flexibility perspective, making the decay functions optional or even as you mentioned making it implicitly in the computationAlgorithm could be a good approach.

Besides that, I like the criteraList definition as it is very abstract and can cover most of the “score” types

We might (opionally) add several thresholds for numerical scores that can be used to be mapped to bad-good scale (or other mentioned in orderedList section).

1 Like

That’s a good suggestion! How would that work in then practice? Would thresholds become a collection of key: value pairs? e.g.

    20: "bad",
    40: "moderate",
    60: "good",
    80: "excellent"
1 Like

Yes, that’s a great idea!

Right now, users on different platforms often don’t get how the ratings work.

What do numbers like -1 or +60 mean? Are they good or bad? We’ve tried to keep things super simple on our platform, with just 10 levels. The first one is the lowest, and 10 is the highest.

We’ve also added a rating system where users can see how their wallet ranks among all others.

For certifications, we’ve set a minimum - level 3. That’s for newbies entering L2.

Users can also see their rank and position in the ratings.

It’s straightforward: users can see where they stand with their rank and level.

It’d be nice to explain all the Ver.ax reputation stuff in an easier way.

We suggest using a system like ours, with levels or ranks, and a simple way to earn and move up.

If every platform explains their rating system clearly, users will get it better.

We think the rating is the best measure, because higher is better.

In our opinion, the rating is the most appropriate criterion, because the higher, the better. You can use a combination with orderedList. In our case, we apply levels [“Level 0”, “Level 1”, …, “Level 10”], but you can use any others, as in the examples above

e.g.range [0,100], or orderedList [“bad”, “average”, “excellent”]

It is also necessary to consider whether this will be publicly available and whether each platform will be able to integrate its solution, or if it will be an individual approach to each platform

Dmihas | RubyScore.io

Yup, KV map looks to be the most versatile solution for the grading.

Hey Simon, great to see the initiative here. And from a practical standpoint, it is of crucial importance for attestation vendors to maintain the maximum information on how certain attestation was designed, generated by users, and what information was collected in what form in the registery so that these attestations can be of maximal usage downstream. This way, other experts can leverage the rich information curated by the registery and design algorithms for proof of humanity freely.

1 Like

@simon.brown Excellent work, Simon!

This proposal precisely addresses a problem that we have been grappling with for quite some time. Within the developer reputation field, we have observed the emergence of various attestations, each with its own criteria and mechanisms. This fragmentation hinders developers from effectively utilizing these attestations to support dApp development, and it also makes it challenging for end users to leverage the attestations across different contexts.

I am particularly excited about the concept of a reputation object mode, as it has the potential to serve as a standardized attestation model that fills the gaps in existing reputation protocols.

Regarding the decay mechanism, have you considered implementing it based on consensus? The value of a reputation attestation is heavily reliant on its credit within the community, but this credit is often not transparent to users. It would be ideal if attestees or third parties could vouch for a criteria/algorithm, allowing for quantified credibility to be reflected in the reputation object modes.

I also want to share a challenge we have been facing. It appears that most reputation protocols lack enthusiasm when it comes to addressing the issues stated in the proposal in practice other than the research level. Despite our efforts to find motivation for these protocols to drive concrete initiatives, progress has been limited. I am eager to connect with other passionate individuals who share our drive and determination to tackle this topic head-on in real product & operation level practice.

I agree that this is a clear and intuitively easy to understand approach. However, I think that not all reputation systems use this approach, for example, GitCoin Passport just issues a single score, as do many other reputation protocols. It’s very difficult to try get everyone to adhere to some standard, but it might work if the various reputation scores can be described in a standard way.

Take the example of a block explorer. How would block explorers render the reputation scores for different wallet addresses in a meaningful way? Currently the only way to to it is to manually research the various reputation scores one by one.

Another example is wallets: if a wallet wanted to represent a reputation score in it’s interface, it faces the same challange, i.e. manually curating and integrating all reputation scores one by one, and making sure to monitor maintain the integrations individually.

This is a good point. Do you suggest then that this should be something like an EIP, rather than simply a VIP? To the best of my knowledge, I haven’t seen a similar proposal out there, but perhaps other platforms could be interested in disucssing this idea. wdyt?