GreenWill Badging + GIF Analysis

Executive Summary

Green Goods already has the right primitives for a meaningful badge system:

durable contribution records through EAS work attestations
review and trust signals through work approvals
strategic and evaluative depth through assessments
role identity through Hats Protocol
impact assetization through Hypercerts
capital participation through Octant vault flows

What it does not have today is a live badge stack. The repository contains a partial UnlockModule, but Unlock is not wired into the deployed contract graph, the shared app config, the indexer, or the current user-facing flows. The docs also still describe badges as planned.

The strongest near-term move is:

use Unlock Protocol for recognitions and credentials
keep Hats for permissions
keep Hypercerts for impact assets
treat GreenWill as the cross-cutting reputation and badge layer that sits above those systems
launch a recognition-first badge system in the next two weeks
defer governance-weighted badge power until the sybil, fairness, and weighting model is much clearer

The repo is close enough that this can be specified cleanly now, but not close enough that it should be implemented as a single onchain “approve work and mint badge in the same flow” path for V1.

My recommendation is to launch V1 with an asynchronous badge issuer that watches Green Goods data sources and grants Unlock keys automatically. That fits the current architecture better, preserves non-blocking approvals, and gets you to first badges faster.

What This Analysis Covered

Attached strategy and framework documents

Greenpill Impact Framework Development
Greenpill Impact Framework: The Fractal Y2I Architecture
x-daoip-5
House of Alignment
DIVAD-Greenpill Strategic Analysis
Greenpill Strategy & ToC Workshop
GreenPill Garden Evolution
community chat notes from March 17, 2026
product sync notes from March 18, 2026

Repository surfaces reviewed

contracts and deployment registry
EAS resolvers and attestation schemas
assessment and work workflows in shared/client packages
Envio indexer schema and config
docs pages for badges, recognition, Unlock, and roadmap
power registry and Gardens governance primitives

External sources checked

official Unlock Protocol docs
official Octalysis overview

The GIF Lens: What The Badge System Should Actually Do

The attached GIF documents make one thing very clear: Green Goods is not trying to build a generic loyalty program. It is trying to build a regenerative verification and coordination layer.

That means badges should do four jobs:

make contribution visible
make progress felt
make trust portable
make the impact cycle legible

Use the GIF “3s” as the badge logic

The framework repeatedly centers:

Purpose
Practice
Progress

This maps cleanly to badges:

GIF axis	What the badge should recognize	Example badge family
Purpose	alignment, commitment, entry into a season, role acceptance	seasonal commitment, operator stewardship
Practice	actual behavior inside MDR and domain work	first submission, first approval, domain badge
Progress	outcomes, funding, assessments, impact asset creation	assessment author, funder, harvest badges

Use the GIF “4s” as the seasonal design language

The framework’s seasonal structure is one of the strongest opportunities in the whole system:

Soil: strategy and governance
Roots: structure and staking
Growth: work execution and CIDS capture
Harvest: Hypercerts, yield, reporting, retrospective

This should not only be copy or artwork. It should be a real badge grammar:

onboarding and commitment badges can carry Soil
role and support badges can carry Roots
work and domain badges can carry Growth
outcome, funding, and hypercert badges can carry Harvest

That gives the system an internal logic that is much more “Greenpill” than a flat list of achievements.

The notes point to a very specific emotional goal

The March 17, 2026 community notes were especially useful here. The repeated theme was not “how do we maximize token incentives?” It was closer to:

start with a few easy badges
cheer people on
make it feel more like a running app or Duolingo than a grant backend
keep it automatic, not manual
use domain and seasonality, but do not overcomplicate V1

That is the right instinct. Early badges should create a sense of:

“I showed up”
“my work was seen”
“I belong here”
“I’m moving through a real cycle”

Not:

“I gamed the system”
“I farmed points”
“I now have governance power because I spammed uploads”

Current-State Repo Audit

1. The core impact stack is already real

Green Goods already has a coherent contribution pipeline:

WorkResolver validates work submissions through EAS
WorkApprovalResolver validates approvals and keeps Karma GAP integration non-blocking
AssessmentResolver and the client workflow support more strategic garden-level reporting
Hypercerts are already treated as the asset layer
Hats already define role-based permissions
Octant infrastructure already models funder participation and yield routing

The practical implication is important:

you do not need to invent badge triggers from scratch. The protocol already emits the events and attestations that a badge engine wants.

2. Unlock exists in contracts, but not as a live product path

The repo already contains:

packages/contracts/src/modules/Unlock.sol
packages/contracts/src/interfaces/IUnlock.sol
unlock fields in the deployment registry ABI and config surfaces

The current contract model is:

one lock per garden
badge issuance on approved work
non-blocking intent at the module level

That is a useful starting point, but it is not the best topology for the first GreenWill badge system.

Why:

it models badges as garden-local
it is tied mainly to work approval
it does not express badge families, seasons, or cross-garden user reputation
it is not wired into the current deployment and UI stack

3. The deployment and app surfaces still treat Unlock as absent

The deployment registry reserves future fields for:

integrationRouter
unlockFactory
greenWillRegistry

But the test deployment base still writes address(0) for the Unlock-related fields, and the live deployment artifacts do not expose an Unlock module address.

The shared blockchain config exposes:

gardenToken
actionRegistry
workResolver
workApprovalResolver
deploymentRegistry
octantModule
octantFactory
hatsModule
karmaGAPModule

It does not expose an Unlock badge module or GreenWill registry.

4. The indexer boundary matters

The current data architecture is split:

Envio indexes core contract state such as gardens, hats, vaults, and hypercert events
EAS attestations are queried directly from EAS GraphQL

That means badge triggers already span two sources of truth:

EAS for work, approvals, and assessments
Envio for roles, vault participation, and hypercert-adjacent flows

This is a strong argument against a rushed “all badge logic inside one resolver” approach for V1.

5. The docs and models have drift that matters for badging

Domain drift

The public docs describe five action domains, including mutual credit.

The on-chain and shared code currently model only four:

Solar
Agro
Education
Waste

That means:

domain badges can be launched safely for the four coded domains
a mutual-credit badge should not be presented as part of the first canonical badge system unless the domain model is expanded first

Capital-language drift

The public narrative around the 8 forms of capital is conceptually strong, but the labels are not perfectly normalized across all surfaces. That does not block V1 badges, but it does matter if later badges reference capital classes directly in metadata, art, or governance formulas.

Strategic Recommendation

Separate the three layers clearly

Layer	Recommended primitive	What it should do
Permissions	Hats Protocol	who can do what
Recognitions / credentials	Unlock Protocol + GreenWill	what a person or garden has earned
Impact assets / finance	Hypercerts + Octant	what value has been certified or funded

This separation is the cleanest way to avoid turning badges into a muddled mix of:

access control
status theater
governance power
financial claims

Define GreenWill as the reputation layer, not just “some NFTs”

GreenWill should be the policy layer that answers:

which badges exist
what they mean
whether they are permanent or seasonal
which event sources can issue them
whether they are display-only or ever contribute to governance later

Unlock is the credential substrate. GreenWill is the meaning system.

Recommended Badge Taxonomy

1. Starter badges

Purpose:

fast encouragement
onboarding momentum
visible proof of first actions

These should be the first badges people see.

2. Domain badges

Purpose:

recognize real work inside each Green Goods domain
give each domain a visible identity
support domain-specific cadence without flattening everything into one generic streak

3. Role and stewardship badges

Purpose:

acknowledge operators, evaluators, and funders
make care work and coordination visible
give the system social depth beyond work upload counts

4. Seasonal badges

Purpose:

make participation time-bounded and narratively legible
create collectibility without relying on artificial scarcity alone
keep the platform feeling alive across cycles

5. Garden badges

Purpose:

recognize collective achievement
make garden-level identity visible
support healthy inter-garden comparison later

These are useful, but they should come after individual badges are stable.

6. Outcome and harvest badges

Purpose:

connect verified work to the funding and impact layer
recognize successful assessments, hypercert creation, and funder support

These are strategically important, but they should remain smaller in number than work and stewardship badges.

Recommended V1 Badge Set

The two-week launch window starting March 19, 2026 should stay small and legible. I would launch 8-9 badge classes max.

V1 core badge classes

Badge class ID	Working display name	Audience	Trigger	Why it belongs in V1
`starter.first_submission`	First Seed	Gardener	first valid work submission attested	instant onboarding reward
`starter.first_approval`	Verified Sprout	Gardener	first approved work	strongest early “my work mattered” signal
`practice.first_assessment`	Reflection Steward	Operator / Evaluator	first assessment authored	ties badges to strategy, not just activity
`support.first_deposit`	Root Capital	Funder	first vault deposit	easy trigger from indexed vault events
`domain.solar.v1`	Solar Steward	Gardener	threshold of approved solar work	gives Solar identity immediately
`domain.agro.v1`	Agro Steward	Gardener	threshold of approved agro work	supports slower ecological work
`domain.edu.v1`	Learning Steward	Gardener	threshold of approved education work	makes Education visible, not secondary
`domain.waste.v1`	Circular Steward	Gardener	threshold of approved waste work	strong fit for visible community action
`role.operator.season`	Season Steward	Operator	active operator for the season with review minimum	acknowledges coordination labor

What I would intentionally leave out of the first launch

ranked comparison views
streak-heavy mechanics
cross-garden rank ladders
badge-based voting power
garden competition mechanics
too many social “engagement” badges

Those can all wait.

Domain Badge Rules: Default Cadence Recommendations

The meeting notes were right to surface cadence differences. Domain badges should not all use the same threshold.

Default V1 rule recommendations

Domain	Default V1 rule	Why
Solar	3 approved actions	generally discrete, repeatable, faster feedback loops
Waste	3 approved actions	discrete, observable, high-frequency work
Education	2 approved actions or one mini-series	education is cyclical but often event-based
Agro	2 approved actions across at least 21 days	slower biological cycles and longer evidence windows

These should be treated as:

initial defaults
stored as offchain config in V1
revisited after gardener survey feedback

The survey idea from the call notes is correct and should happen before Q2 expansion.

Unlock Topology: What Kind Of Locks To Use

Option A: one lock per garden

This is close to the current UnlockModule model.

Pros

matches the current onchain contract concept
works for garden-local credentials or membership
easy to reason about for local access

Cons

weak for cross-garden public reputation
awkward for global badge browsing
duplicates badge meaning across gardens
not ideal for domain families or seasonal collections

Verdict

Useful later for garden-local membership or local credentials, but not the best first public badge system.

Option B: one lock per badge class

Example:

one lock for First Seed
one lock for Verified Sprout
one lock for Solar Steward

Pros

very clean analytics
easy to show on profiles
simple to reason about in UI
badge meaning stays consistent across the network

Cons

recurring seasonal awards are awkward if you want collectible history

Verdict

Best option for permanent badge classes in V1.

Option C: one lock per seasonal badge class per season

Example:

Season Steward - Spring 2026
Solar Steward - Q2 2026

Pros

preserves collectible seasonal history
makes cycles very legible
avoids ambiguous duplicate-award semantics

Cons

more lock management overhead
can become noisy if overused

Verdict

Best option for seasonal badges only.

Recommended hybrid

use one lock per badge class for permanent badges
use one lock per seasonal badge class per season for recurring seasonal badges
do not use one giant all-purpose GreenWill lock

This gives the cleanest mix of:

legibility
portability
manageable lock count
clear historical semantics

Recommended Technical Architecture

V1 architecture: asynchronous issuer

This is the cleanest fit for the repo as it exists today.

Why this is the right V1 choice

it matches the current split between EAS data and Envio data
it keeps work approval non-blocking
it avoids contract rewiring across multiple packages in the first badge launch
it supports automatic badge appearance without manual mint links
it is easier to make idempotent and observable

V1 components

Component	Responsibility
Badge catalog	canonical badge class definitions, names, family, domain, seasonality, rule config, metadata CID
Season config	canonical season IDs, dates, labels, Soil/Roots/Growth/Harvest mapping
Badge engine worker	reads EAS + Envio, evaluates badge rules, prevents duplicate awards
Unlock issuer	grants keys to recipients using lock-manager or key-granter authority
Badge read adapter	reads wallet badge holdings for profile display
UI surfaces	shows earned badges, upcoming badges, and earn moments

V1 data sources

Trigger type	Best source
first work submitted	EAS work attestations
approved work	EAS work approvals
first assessment	EAS assessments
role-based stewardship	Envio Hats events plus EAS review counts
funder receipt	Envio vault deposit events

V1 idempotency rule

For each badge award, the engine should treat the tuple below as canonical:

recipient
badge class ID
season ID if applicable

That avoids duplicate mints when jobs are re-run or data is backfilled.

Why I Would Not Use The Current UnlockModule As-Is For V1

The existing module is useful conceptually, but I would not make it the center of the first release.

Reasons

it assumes garden-centric locks
it is focused mainly on work approval
it is not wired into the deployed app surfaces
the current interface should be revalidated against current Unlock factory guidance before production use
the badge engine needs to combine EAS and Envio state anyway

Better use of the current module

Treat the existing module as:

a reference implementation
a future onchain path for garden-local credentials
a candidate for UnlockBadgeModuleV2 after the badge catalog and season model are stable

GreenWill Contract Direction

You asked specifically what the contract path could look like in Solidity. I would phase it.

Phase 1: no new protocol-critical contract required

For the first launch, GreenWill can be mostly:

lock definitions in Unlock
offchain badge catalog and rule config
issuer automation

That is enough to get real badges in user hands.

Phase 2: add an onchain GreenWill registry

The repo already reserves greenWillRegistry in deployment structures. That is the right long-term anchor.

Proposed responsibility of `GreenWillRegistry`

register badge classes
map badge class IDs to lock addresses
map badge classes to family, domain, and seasonality
expose metadata CIDs and current season config
emit canonical badge-class events for indexers and UIs

Example sketch

struct BadgeClass {
    bytes32 classId;
    address lock;
    bytes32 family;
    uint8 domain;      // optional
    uint8 role;        // optional
    bool seasonal;
    bool governanceEligible;
    string metadataCID;
}

function registerBadgeClass(BadgeClass calldata badgeClass) external;
function setSeason(bytes32 seasonId, uint64 start, uint64 end, string calldata metadataCID) external;
function getBadgeClass(bytes32 classId) external view returns (BadgeClass memory);

Phase 3: optional onchain issuer module

Later, if you want tighter contract-native flows, add an UnlockBadgeModuleV2 or GreenWillIssuer that:

is authorized by governance
emits canonical BadgeIssued events
can be called by approved routers or relayers
optionally integrates with the registry

Example event shape

event BadgeIssued(
    address indexed recipient,
    bytes32 indexed classId,
    bytes32 indexed seasonId,
    address garden,
    bytes32 sourceRef
);

That event shape is valuable because it gives the indexer a clean, protocol-owned surface independent of raw Unlock events.

Phase 4: optional governance adapter

The repo’s UnifiedPowerRegistry already supports ERC-721 sources for power calculations. That means GreenWill badges could eventually contribute to governance.

I would explicitly not do that in V1.

Only consider it later if all of the following are true:

sybil resistance is stronger
badge quality rules are stable
the team has decided which badges represent trust and not just participation
fairness across domains has been tested

Unlock-Specific Recommendations

1. Use Unlock as the credential layer, not the rules engine

Unlock is excellent for:

issuing recognizable credentials
wallet-visible badge ownership
manager and granter roles
future token-gated community experiences

It should not be forced to also be:

the entire badge policy engine
the seasonal configuration system
the cross-source data reconciler

2. Keep badge minting automatic

The notes were clear that this should feel more like Discord role assignment than a manual mint claim.

So the user flow should be:

a valid event happens
the badge engine detects it
the issuer grants the key
the app surfaces the badge automatically

No claim links. No “go mint your reward” as the default path.

3. Use static metadata first, dynamic hooks later

Unlock supports hooks, including tokenURI-style customization. That is useful, but it is not necessary for the first launch.

V1 metadata recommendation

pre-generate SVG or PNG assets from a modular template system
upload badge metadata and images to IPFS
attach static metadata per badge class or seasonal badge lock

V2 metadata recommendation

Use hooks only if you later want:

dynamic seasonal visuals
richer token attributes
custom external proof pages

4. Revalidate the factory interface before production wiring

The repo currently models a minimal factory around createLock(bytes,uint16).

Official Unlock docs currently emphasize upgradeable lock deployment paths and current access-control roles. Before deploying any production GreenWill contract that creates locks directly, the factory interface and deployment assumptions should be checked against the current Unlock production docs and target-chain contracts.

Visual System Recommendation

The art discussion in the community notes was one of the strongest parts of the inputs.

The right design constraint is:

build a badge system as a modular language, not a collection of one-off illustrations.

Core badge template layers

Layer	Meaning	Should change often?
Base frame	badge family	no
Background field	domain color or seasonal context	yes
Center glyph	core badge meaning	yes
Role marker	gardener / operator / evaluator / funder / garden	yes
Seasonal ribbon	Soil / Roots / Growth / Harvest or season label	yes
Progress pips	level or tier if used	sometimes
Texture / ornament	rarity or prestige	rarely

Recommended visual grammar

Domain colors

Use the current protocol palette first:

Solar: amber / gold
Agro: green
Education: blue
Waste: orange

Do not invent a fifth mutual-credit badge palette until the domain model is canonical.

Family shapes

Keep family distinction structural:

starter badges: circles or seeds
domain badges: shields or petals
stewardship badges: hexes or pillars
funder badges: rings or roots
seasonal badges: banded tokens with ribbons

Seasonal overlay

Use a consistent seasonal visual marker:

Soil: earth base / darker grounding tone
Roots: line-work, lattice, subterranean pattern
Growth: upward leaves / rays / motion
Harvest: fruiting accent / crown / burst

Badge naming rule

Keep internal IDs stable and poetic names flexible.

For example:

class ID: starter.first_approval
display name: Verified Sprout

That lets you evolve naming and marketing without contract churn.

Metadata Template Recommendation

Every badge metadata object should at minimum include:

{
  "name": "Verified Sprout",
  "description": "Awarded for receiving your first approved work attestation in Green Goods.",
  "image": "ipfs://...",
  "external_url": "https://...",
  "attributes": [
    { "trait_type": "Family", "value": "Starter" },
    { "trait_type": "Domain", "value": "None" },
    { "trait_type": "Role", "value": "Gardener" },
    { "trait_type": "Seasonal", "value": "No" },
    { "trait_type": "Source", "value": "EAS Work Approval" },
    { "trait_type": "Version", "value": "V1" }
  ]
}

Recommended additional fields for GreenWill proof pages

source attestation UID or transaction hash
garden address or garden slug
season ID
issue timestamp
badge class ID
domain
role

Those do not all need to live in the onchain token metadata itself, but they should exist in the proof surface.

UI Surface Recommendation

Badges should not live in a hidden profile tab only.

Highest-value UI surfaces for V1

post-approval success state
work dashboard profile header
garden participant cards
funder profile / funding dashboard
operator and evaluator profile summaries

Best immediate dopamine surface

After a badge is issued, show:

a lightweight earned-badge modal or toast
badge art
one-sentence explanation
optional proof link

That is the product moment the community notes were pointing toward.

Octalysis Guidance For GreenWill

Octalysis is useful here, but only if it is used carefully.

The strongest badge system for Green Goods should emphasize the “white hat” side of motivation:

Epic Meaning & Calling: “This work matters”
Development & Accomplishment: “I am progressing”
Ownership & Possession: “This is part of my impact portfolio”
Social Influence & Relatedness: “My community can see my contribution”

Best fit for Green Goods

Octalysis drive	How it should show up in Green Goods
Meaning	badges tied to regenerative service, not generic gamification
Accomplishment	quick starter wins and visible domain progression
Ownership	portable onchain badge history
Social influence	profile display, garden display, recognition of operators and funders
Creativity / feedback	earned moments tied to real review and reflection

What to avoid

overusing streak pressure
fake scarcity for its own sake
issuing too many badges too early
rewarding raw submission volume over verified quality
turning badges into social comparison before users have basic wins

Green Goods is closer to a trust-and-care system than a casino. Octalysis can help shape motivation, but it should not overpower the regenerative ethos.

Metrics That Matter

If GreenWill launches, I would watch these first:

Metric	Why it matters
first-badge rate	are new users getting early positive feedback?
approval-to-badge latency	does the experience feel immediate enough?
badge display rate	are users actually seeing and sharing badges?
domain badge completion by domain	are thresholds fair across domains?
30-day return after first badge	are badges helping retention?
operator season-badge attainment	are stewardship badges actually reachable?
first-deposit to repeat-deposit rate	do funder badges reinforce support?

Metrics I would not over-index on initially

total badge count minted
ranking density
badge rarity theater

Those can look healthy while the actual system still feels flat or unfair.

Phased Roadmap

Phase 0: V1 launch window

March 19, 2026 to early April 2026

Goal: launch the first real badge system without blocking the rest of v1 beta.

Scope

finalize badge catalog for 8-9 classes
define season object for the current cycle
create Unlock locks for permanent and seasonal V1 badges
ship asynchronous issuer design
expose badge display on at least one core user surface
ship “earned badge” feedback moment

Explicit non-goals

governance weighting
fully generalized GreenWill contract system
garden-level competition
dynamic metadata hooks
mutual-credit badge family

Phase 1: Q2 expansion

April 1, 2026 to June 30, 2026

Goal: make GreenWill feel like a real reputation layer.

Scope

add garden-level badges
add more funder and operator badges
normalize season handling
add better badge browsing and filtering
add Unlock event indexing or a badge cache layer
add GreenWillRegistry if the team wants onchain catalog ownership
test proof pages and badge sharing

Phase 2: post-Q2 maturity

Goal: connect GreenWill to deeper protocol logic carefully.

Scope

potential governance adapter
cross-garden trust weighting experiments
capital-sensitive or impact-sensitive badges
tokenURI or metadata hooks for dynamic traits
partner-facing reputation views for funders and evaluators

Risks And Anti-Patterns

1. Overbadging

If too many badges appear too quickly, none of them feel meaningful.

2. Quantity over quality

If the system rewards uploads more than verified impact, behavior will drift toward spam.

3. Domain unfairness

Agro and Education work often operate on slower cycles than Waste or Solar. Flat thresholds will distort behavior.

4. Permission confusion

If Hats and GreenWill overlap semantically, users will not understand whether a badge is symbolic or authoritative.

5. Governance capture too early

If badges become voting power before the trust model is mature, the system will be easy to game and hard to defend.

6. Model drift

If public docs say five domains but the protocol enforces four, badge claims will confuse users and create edge cases in metadata and UI.

7. Protocol brittleness

If badge issuance sits directly on the critical work approval path too early, unrelated protocol failures will become user-facing friction.

Decisions I Would Make Now

GreenWill V1 is a recognition layer, not a governance layer.
Unlock is the credential substrate.
Hats remains the permission substrate.
Hypercerts remain the impact-asset substrate.
V1 badge issuance is automatic and asynchronous.
V1 launches with starter + domain + one stewardship + one funder badge family.
Seasonal badges are real, but only a small number should ship initially.
Mutual-credit badges wait until the canonical domain model expands.
The art system is template-first and layer-based from day one.

Open Questions

Should seasonal badges be purely commemorative, or should some expire as active credentials?
Do you want any V1 badges to be garden-specific, or should all first badges be network-wide GreenWill badges?
What exact event should count as “first support” for funders: first vault deposit, first hypercert purchase, or both?
Should operators and evaluators share a stewardship visual family, or should they be visually separate from the start?
How much badge proof detail should be public by default: attestation IDs, garden names, timestamps, or only summary views?
Do you want a current-season badge palette that changes every cycle, or a stable palette with seasonal markers?
When the gardener survey goes out, what decision is it meant to inform first: cadence, usefulness, or visible prestige?

Reference Patterns Appendix

The strongest external badge systems fall into a few reusable families:

mastery and progression systems
verifiable credential systems
community reputation systems
seasonal challenge systems
participation receipt systems

GreenWill should not copy any one of them outright. It should combine the right parts of each.

Best-fit analogs

System	Best lesson for GreenWill	What to borrow	What to avoid
Scouting America	structured domain mastery	explicit requirements, sign-off, required vs elective progression	too much bureaucracy
Trailhead	guided progression	easy early badges, paths, ranks, superbadges	over-pointification
Open Badges / Credly	proof and portability	issuer, criteria, evidence, metadata, shareability	sterile enterprise feel
Stack Overflow / Discourse	healthy behavior shaping	onboarding badges, auto-awards, early adopter badges, repeatables where justified	optimizing only for raw counts
GitHub / Google Developer Program	profile controls	favorites, hiding badges, optional visibility, removable membership badges	opaque criteria everywhere
Strava / Garmin	seasonal energy	progress bars, limited-time campaigns, repeatables with caps, non-competitive group goals	ranking-first design
POAP / Galxe	web3 credential intuition	commemorative drops, onchain identity, issuer/verifier thinking, token-gating potential	quest farming

Scouting America

Scouting is still one of the clearest badge models because it combines:

explicit requirements
reviewed completion
elective specialization
a required-core path for major advancement

The most reusable pattern is the structure:

core foundation badges
domain electives
a few higher-trust synthesis badges

That suggests a future GreenWill model with required starter badges, domain paths, and a small number of stewardship badges with stronger review.

Scouting Test Lab

Scouting’s Test Lab is a strong precedent for pilot badges.

GreenWill should adopt that idea directly for:

seasonal pilot badges
garden-specific experiments
social or stewardship badges that need validation before becoming permanent

This is the cleanest way to explore new badge types without pretending the first catalog is final.

Trailhead

Trailhead is the best reference for progression:

small early wins
visible paths
ranks above badges
superbadges for integrated capability

GreenWill should borrow:

starter badges as approachable wins
role or domain badge paths
a very small number of “superbadge” style credentials for operators or evaluators

Open Badges and Credly

If GreenWill is more than decorative art, every meaningful badge should eventually have:

issuer
criteria
evidence
issue date
optional expiration
portable metadata

That is the strongest design rule from Open Badges and Credly. Even if Unlock is the issuance layer, GreenWill should still think like a verifiable credential system.

Stack Overflow and Discourse

These systems show how badges can:

teach the product
encourage positive behavior
reward early adopters
operate automatically from queryable data

That supports the first GreenWill badge classes directly:

first submission
first approval
first assessment
first deposit
beta or genesis participation badges

GitHub and Google Developer Program

These are the clearest precedents for badge display controls.

GreenWill should support:

favorites
hiding individual badges
optional profile display
a distinction between permanent accomplishments and membership-dependent badges

Some GreenWill badges should be historical forever. Others, especially membership badges, may need to disappear if the underlying affiliation ends.

Strava and Garmin

These are the strongest references for seasonal energy.

The most useful patterns are:

time-boxed campaigns
progress bars
earned vs available badge views
limited-time drops
repeatables with caps
group goals that do not require direct competition

This is a better fit for GreenWill than endless streak pressure.

POAP and Galxe

These are useful web3 references, but they should be used carefully.

POAP is great for:

attendance
participation memory
lightweight token-gating

Galxe is useful for:

issuer / verifier / holder mental models
thinking about revocable vs permanent credentials
later-stage identity and reputation design

But GreenWill should avoid becoming a quest-farming system. The regenerative context demands more seriousness than most campaign-driven web3 badge products.

Recommended synthesis

The cleanest shorthand is:

Scouting for mastery
Trailhead for progression
Open Badges for proof
GitHub for profile control
Strava for seasons
POAP for commemorative participation

That combination is much closer to Green Goods than copying any one NFT or gamification product.

Bottom Line

Green Goods is in a strong position to launch a badge system because the platform already produces real evidence, real review, real roles, and real funding traces.

The right V1 is not a maximal system. It is a small, emotionally legible, automatically issued, GIF-aligned credential layer that:

celebrates first contributions
respects domain differences
recognizes stewardship
makes funding support visible
creates a portable portfolio of regenerative trust

If GreenWill starts there, it will feel native to Green Goods and can grow into something much more powerful during Q2 2026 without forcing premature governance or protocol coupling.

Sources

Internal documents

packages/contracts/src/modules/Unlock.sol
packages/contracts/src/interfaces/IUnlock.sol
packages/contracts/src/registries/Deployment.sol
packages/contracts/src/resolvers/WorkApproval.sol
packages/contracts/src/registries/Power.sol
packages/contracts/test/helpers/DeploymentBase.sol
packages/indexer/config.yaml
packages/indexer/schema.graphql
packages/shared/src/config/blockchain.ts
packages/shared/src/types/domain.ts
packages/contracts/config/actions.json
docs/docs/builders/specs/v1-0.mdx
docs/docs/builders/integrations/unlock.mdx
docs/docs/community/gardener-guide/earning-badges.mdx
docs/docs/community/steward-guide/earning-recognition.mdx
docs/docs/community/evaluator-guide/earning-badges.mdx
docs/docs/community/funder-guide/earning-recognition.mdx
docs/docs/community/where-were-headed.mdx
docs/docs/community/welcome.mdx

User-provided strategy docs

Greenpill Impact Framework Development
Greenpill Impact Framework: The Fractal Y2I Architecture
x-daoip-5
House of Alignment
DIVAD-Greenpill Strategic Analysis
Greenpill Strategy & ToC Workshop
GreenPill Garden Evolution
Community Chat - 2026_03_17
Product Sync - 2026_03_18

Executive Summary​

What This Analysis Covered​

Attached strategy and framework documents​

Repository surfaces reviewed​

External sources checked​

The GIF Lens: What The Badge System Should Actually Do​

Use the GIF “3s” as the badge logic​

Use the GIF “4s” as the seasonal design language​

The notes point to a very specific emotional goal​

Current-State Repo Audit​

1. The core impact stack is already real​

2. Unlock exists in contracts, but not as a live product path​

3. The deployment and app surfaces still treat Unlock as absent​

4. The indexer boundary matters​

5. The docs and models have drift that matters for badging​

Domain drift​

Capital-language drift​

Strategic Recommendation​

Separate the three layers clearly​

Define GreenWill as the reputation layer, not just “some NFTs”​

Recommended Badge Taxonomy​

1. Starter badges​

2. Domain badges​

3. Role and stewardship badges​

4. Seasonal badges​

5. Garden badges​

6. Outcome and harvest badges​

Recommended V1 Badge Set​

V1 core badge classes​

What I would intentionally leave out of the first launch​

Domain Badge Rules: Default Cadence Recommendations​

Default V1 rule recommendations​

Unlock Topology: What Kind Of Locks To Use​

Option A: one lock per garden​

Pros​

Cons​

Verdict​

Option B: one lock per badge class​

Pros​

Cons​

Verdict​

Option C: one lock per seasonal badge class per season​

Pros​

Cons​

Verdict​

Recommended hybrid​

Recommended Technical Architecture​

V1 architecture: asynchronous issuer​

Why this is the right V1 choice​

V1 components​

V1 data sources​

V1 idempotency rule​

Why I Would Not Use The Current UnlockModule As-Is For V1​

Reasons​

Better use of the current module​

GreenWill Contract Direction​

Phase 1: no new protocol-critical contract required​

Phase 2: add an onchain GreenWill registry​

Proposed responsibility of GreenWillRegistry​

Example sketch​

Phase 3: optional onchain issuer module​

Example event shape​

Phase 4: optional governance adapter​

Unlock-Specific Recommendations​

1. Use Unlock as the credential layer, not the rules engine​

2. Keep badge minting automatic​

3. Use static metadata first, dynamic hooks later​

V1 metadata recommendation​

V2 metadata recommendation​

4. Revalidate the factory interface before production wiring​

Visual System Recommendation​

Core badge template layers​

Recommended visual grammar​

Domain colors​

Family shapes​

Seasonal overlay​

Badge naming rule​

Metadata Template Recommendation​

Recommended additional fields for GreenWill proof pages​

UI Surface Recommendation​

Executive Summary

What This Analysis Covered

Attached strategy and framework documents

Repository surfaces reviewed

External sources checked

The GIF Lens: What The Badge System Should Actually Do

Use the GIF “3s” as the badge logic

Use the GIF “4s” as the seasonal design language

The notes point to a very specific emotional goal

Current-State Repo Audit

1. The core impact stack is already real

2. Unlock exists in contracts, but not as a live product path

3. The deployment and app surfaces still treat Unlock as absent

4. The indexer boundary matters

5. The docs and models have drift that matters for badging

Domain drift

Capital-language drift

Strategic Recommendation

Separate the three layers clearly

Define GreenWill as the reputation layer, not just “some NFTs”

Recommended Badge Taxonomy

1. Starter badges

2. Domain badges

3. Role and stewardship badges

4. Seasonal badges

5. Garden badges

6. Outcome and harvest badges

Recommended V1 Badge Set

V1 core badge classes

What I would intentionally leave out of the first launch

Domain Badge Rules: Default Cadence Recommendations

Default V1 rule recommendations

Unlock Topology: What Kind Of Locks To Use

Option A: one lock per garden

Pros

Cons

Verdict

Option B: one lock per badge class

Pros

Cons

Verdict

Option C: one lock per seasonal badge class per season

Pros

Cons

Verdict

Recommended hybrid

Recommended Technical Architecture

V1 architecture: asynchronous issuer

Why this is the right V1 choice

V1 components

V1 data sources

V1 idempotency rule

Why I Would Not Use The Current UnlockModule As-Is For V1

Reasons

Better use of the current module

GreenWill Contract Direction

Phase 1: no new protocol-critical contract required

Phase 2: add an onchain GreenWill registry

Proposed responsibility of `GreenWillRegistry`

Example sketch

Phase 3: optional onchain issuer module

Example event shape

Phase 4: optional governance adapter

Unlock-Specific Recommendations

1. Use Unlock as the credential layer, not the rules engine

2. Keep badge minting automatic

3. Use static metadata first, dynamic hooks later

V1 metadata recommendation

V2 metadata recommendation

4. Revalidate the factory interface before production wiring

Visual System Recommendation

Core badge template layers

Recommended visual grammar

Domain colors

Family shapes

Seasonal overlay

Badge naming rule

Metadata Template Recommendation

Recommended additional fields for GreenWill proof pages

UI Surface Recommendation