Badges & Attestations - clarification & possible directions

[V-Vaal]

Badges & Attestations - clarification & directions

This issue captures a discussion about the role of badges in The Guild, how they relate to attestations, and possible evolutions. Updated after discussion with @joelamouche.

---

Current model

• Badge = a skill label (e.g. "Rust", "Solidity", "Code Review"). Stored in TheGuildBadgeRegistry.
• Attestation = the EAS on-chain act: "A attests that B has badge X, because Y". Schema: bytes32 badgeName, bytes justification.
• They are two facets of the same system, not separate layers.

---

Context

• Badges were initially envisioned as peer-to-peer recognition (people giving badges to others).
• Skill-related badges were also meant to act as a CV / skill discovery surface.
• In practice, engagement with pure P2P badges has been low.
• Most badges today are issued by The Guild and tied to contributions.
• The Guild already relies on EAS on-chain, but the product semantics are not fully clarified yet.
• There is interest in using badges for reputation, participation/gamification, and social sharing.

---

Badge taxonomy

"Badge" as the umbrella term, with qualifiers to distinguish types:

Type	Description	Attested by
Skill badge	A competence label (Rust, Solidity, Code Review...)	A peer
Peer badge	Free-form recognition (trust, appreciation, judgment)	A peer
Guild badge	Aggregated or computed badge derived from multiple signals	The system / The Guild

"Attestation" remains the underlying EAS act for all types.

---

Two complementary kinds of badges (current)

1. Skill badges (fact-based)

• Derived from verifiable signals (PRs, reviews, scopes, labels, activity over time).
• Grounded in real contributions and demonstrated skills.
• Can act as strong reputation signals.

2. Peer badges (social)

• Preserve the original peer-recognition vision.
• Voluntarily given based on trust, judgment, or appreciation.
• Support the social and cooptation aspect of The Guild.

A clear distinction between these two types (UX + semantics) seems important.

---

Possible evolutions (not implemented)

Badge hierarchy — knowledge graph (#118)

Badges could point to other badges, creating a knowledge tree/graph.
Example: rust-chapter1 → rustbook → rust
This structures the badge space itself. See #118.

Individual levels — attestation-count thresholds

A person's mastery on a given badge could be expressed as a level derived from how many peer attestations they've received for it (e.g. 3 = beginner, 10 = intermediate, 25 = expert).
This is complementary to badge hierarchy: one structures the badge space, the other measures individual progression within a badge.
Also complementary to the upvoting system (#122), which evaluates badge relevance (meta-level).

Guild badges — aggregated / system-attested

A badge derived from multiple peer attestations across different skills.
Examples:

• "Web3 Full-stack Developer": unlocked when a member has received N peer attestations on each of Rust, Solidity, and React.
• "Active Contributor": attested by the system after X attestations received across all skills over a given period.

These would be attested by the system (not a peer), introducing a new attestation source type.

External contributions

External contributions (PRs merged on external repos, published audits, conference talks, technical articles) could be imported as evidence, but would only become Guild signals once recognized and attested within the Guild framework — for instance by a maintainer, a vote mechanism, or a system validator.
Today the contracts don't enforce who can attest, so a trust layer would need to be built.

---

Open questions

• Badge hierarchy: Do we want a knowledge graph between badges? What governance for pointers? (see Badge enhancements #118)
• Individual levels: Do we want attestation-count thresholds? Off-chain (indexer) vs on-chain?
• Guild badges: Do we want system-attested badges derived from multiple peer attestations?
• External contributions: What trust layer for validating external evidence? Maintainer? Vote? System?
• TCR: Starting with upvotes (Badge TCR/Vote ranking: Smart Contract #122) and maintainer oversight — move to TCR only if volume/abuse justifies it?
• Sources of truth: GitHub signals as a pragmatic starting point.
• Product direction: How badges should support participation, learning, reputation, and sharing.

---

Related Issues (non-exhaustive)

Attestations: #48, #47, #130, #32
Badges: #69, #122, #58, #64
Architecture / tokens: #55, #72
Profiles & discovery: #49, #98
Analysis: #126

[joelamouche]

Some questions:

• "External contributions
  Probably shouldn’t be excluded, but shouldn’t be automatically included either.
  What matters is whether they are recognized and attested within The Guild." What do you mean by this? @V-Vaal Could you tell me more?
• What do we think about badge hierarchy and TCR, as framed in Badge enhancements #118 ?

[V-Vaal]

Updated after discussing - corrections and clarifications on my initial response.

On external contributions:
They shouldn't be excluded, but they shouldn't be automatic Guild reputation signals either.
Concretely: a PR merged on an external open-source repo, a published audit, a conference talk, a technical article — these exist as verifiable facts. To become a Guild signal, a maintainer (or a system — vote, other mechanism?) would need to create an attestation within The Guild that references the external evidence.
Today the contracts don't enforce who can attest, so this trust layer would need to be built.

On badge hierarchy (#118):
#118 is about a knowledge graph between badges (badge A points to badge B: rust-chapter1 → rustbook → rust). That's about structuring the badge space itself.
What I initially proposed (threshold-based levels) is a separate concept: individual progression within a given badge, derived from attestation counts (e.g. 5 attestations on Rust = intermediate). Complementary to hierarchy, not the same thing. Also complementary to the upvoting system built in #122 — upvotes evaluate badge relevance (meta), thresholds evaluate individual mastery.

On badges vs attestations — terminology:
In the current model: badge = skill, attestation = the EAS act (A attests B has badge X). Same system, not two layers.
Following your suggestion, clearer taxonomy:

• Skill badge: competence label, attested by a peer
• Peer badge: free-form recognition, attested by a peer
• Guild badge: aggregated/computed badge, attested by the system

"Attestation" stays the EAS act. "Badge" as umbrella with qualifiers.

Guild badge examples (not implemented):

• "Web3 Full-stack Developer": unlocked when a member has N peer attestations on each of Rust, Solidity, and React. Attested by the system.
• "Active Contributor": attested by the system after X attestations received across all skills over a given period.

On TCR:
A scalability tool, not a prerequisite. Current upvote-based ranking (#122) is a good starting point — move toward TCR only if volume, conflicts, or abuse justify it.

I've updated the issue body to reflect all of this.

[joelamouche]

Alright so following this discussion I would like to move forward and make a proposal for "Badges V2".

Here are some of the thoughts that led to this decision:

• Most of the badges right now come from the Guild and are based on contributions, almost no peer issued badges
• It seems a lot of Guild members are looking to learn, practice skills, gain experience
• We should guide users with a clearer learning path by providing event and aggregated skill badges
• I heard OSS contributors like leaderboards so maybe we should gamify the Guild experience more.
• We have low engagement on badge creation and curation

We will introduce 4 types of badges:

• Peer badge: competence label, attested by a peer (so what we had before basically)
• Guild Contribution badge: This badge is on a per PR/issue basis and represents contribution to the Guild, issued by The Guild
• Guild Skill badge: aggregated/computed badge, attested by the system. So for example 1 PR with rust gives you Rust lvl1 badge and 3 PRs give you Rust lvl 2 and FE contrib+BE contrib+Smart contract contrib gives you Web3 Full Stack dev badge.
• Guild Event badges: Guild issued, time based badge. Such as "Number 1 contributor February 2026" or even better if we can organize Hackathons.

What I think we shouldn't include in V2:

I think we should postpone introducing external contributions into the system formally because if we do then we decide to figure out how to incentivize members to review those. For now if there are any they should be handled by the Peer badges.

I think we should also postpone the implementation of Badge hierachy/knowledge tree because we have seen little engagement by members on badge creation so far and it seems a Guild led knowledge structure is preferable at this point.

In the same spirit, TCR on badge names should be defered because we have low engagement on badge creation and curation.

[V-Vaal]

Thanks for putting this together.
I think this is a very healthy move.

I agree with the overall direction: We need something more structured and contribution-driven if we want badges to actually matter in practice.

Clarification

You mention introducing 5 types of badges, but I currently see 4 listed:

• Peer badge
• Guild Contribution badge
• Guild Skill badge
• Guild Event badge

Am I missing one, or was the fifth related to external contributions?

Structured Recap

If I try to summarize, that gives:

1. Social layer

Peer badge: human-to-human recognition (trust, appreciation, competence signal)

2. Contribution layer (atomic / factual)

Guild Contribution badge: per PR/issue attestation (low-level factual signal)

3. Aggregation layer (derived signals)

Guild Skill badge: derived from contribution attestations
Guild Event badge: derived from time/context-based activity

At the EAS level, these are all attestations.
Badge is the product-level interpretation we expose on top of them.

This preserves extensibility if we later want to introduce hierarchy, levels, or external evidence.

On Postponed Elements

I agree with the elements you defined.
This feels like the right level of pragmatism at this stage.

The main thing now might be defining: What is the minimal V2 we want to ship? What remains experimental?

Happy to help structure that into a concrete spec if useful.

---

Implementation suggested

Implementation-wise, the main levers for V2 seem to be:

1. Guild Contribution badges

Define who emits them, when, and how: Relayer/bot or on-chain trigger (e.g., PR merge) ?
Dedicated EAS schema so that the indexer can distinguish these attestations

2. Guild Skill badges

A rules engine (in the indexer or potentially in contract logic) that:

1. Consumes contribution attestations
2. Emits higher-level skill attestations when thresholds are met

3. Guild Event badges

Same attestation primitive, but scoped by a time window or manually emitted depending on the event semantics (leaderboards, hackathons, etc.)

---

Suggested Execution Structure

For each badge type, we probably need a small sub-issue focused on:

• The EAS schema (what data it carries)
• The emission path (who/what emits it)
• The minimal rules for V2 (thresholds, time windows, etc.)

If you open one sub-issue per badge type (Peer, Guild Contribution, Guild Skill, Guild Event), we can iterate on schema + emission logic independently and keep the scope of V2 well scoped.

Does that fit your thinking?

[joelamouche]

Am I missing one, or was the fifth related to external contributions?

No this is just a typo. As per explained, external contributions will be handled by peer badges atm