Badges, Tokens and NFTs [2.0]

[n13]

Tokens, Badges, and NFTs

Why

Badges and other digital assets have the potential to provide a very flexible digitally signed data structure for us to use throughout the Seeds ecosystem. They are much more flexible than static tables.

Overview / Considerations

We can use Tokens, Badges, and NFTs as digitally signed assets ... for each use case we consider the following parameters

• who creates them
• who issues new ones
• Is there a limited amount, or unlimited
• Can a user only have 1, or a number
• transferable / non transferable (can be sold)
• expiration date

Badges (DRAFT)

• Badges have a creator which is cryptographically secured (signer)
• Badges have a name and ID (unique ID)
• Badge has a max supply (can be unlimited)
• Badges can be created by anyone, but the interpretation of a badge is up to the interpreter
• Badges can be given to any account
• Badge can be transferable or non-transferable by the holder. Most will be non-transferable.
• An account can have 1 or more badges of the same kind? Yes, but each instance is unique.
• Removal of badges (see comments)
• Have Onperiod to check for expiration

NFT

• transferable
• has creator
• limited supply, e.g. 1, 10, 20 - numbered. Or is it always 1.
• unique ID

Use Cases in Seeds

These help us define what we need from a digital asset contract, what's a token, what's a badge, what's an NFT

Resident status badge

• • Creator: Seeds System
• • Issuer: Issued by contract code
• • Limited: No
• • Max amount a user can own: 1
• • Non transferable
• • Meaning: Validates the fulfillment of resident criteria

Citizen status badge

(same as resident)

Contribution Score Token

Not sure it makes sense to represent points scores as tokens - they're not badges They are added and removed by the system.

• • Creator: Seeds System
• • Issuer: Issued by contract code
• • Limited: No
• • Max amount a user can own: 99
• • Non transferable
• • Meaning: Validates user's contribution score

Reputation Score Token

(same as above just for rep score)

Not convinced it makes sense to have these scores as tokens - it adds complexity to the code, and people can just look up the rep score on the tables...

I think it probably doesn't make sense to have these scores as tokens. They're not really badges either.

[julioholon]

I agree that scores should not be used as Badges (maybe NFTs, see below). You can have fungible things like scores or coins as requisites to earn or lose a badge, coded in smartcontracts. I like to think of badges as markers or milestones, for human readable data analysis. So if you have X planted score, Y contribution score, Z community building score, you earn a AAA badge so everyone else can see you actually "beat that challenge". And you may lose the badge if the points drop below a threshold too.

[julioholon]

They way I was thinking is that badges can be earned in 3 ways:

• Coded as a "trigger" on any smartcontract (like when an ORg receives X CS, they get the Reputable badge)
• Earned as reward from a Quest (you earn coins, and also "Reputation" or "Skill" badges as you complete the quest)
• Earned on any DHO (voted DHO badges) can be freely translated to SEEDS badges, by invoking an ACTION

This is cool because we can have "Nomination" public quests, that pay 0 SEEDS, but give someone a Badge. And we can also have private quests so that one individual can "recognize" another and give them a Badge.

[julioholon]

Regarding losing badges, there's also 3 ways:

• Coded as a "trigger" on any smartcontract, if you reach below a threshold you can lose a badge
• Any Badge can be flagged by users, if the total cumulative flagging power (sum of REP) is greater than the REP power of the issuer(s), the user loses the badge.
• Badges can expire too, and need to be renewed

[julioholon]

An account can have 1 or more badges of the same kind? (NFTs)

Yes, this "kind" is usually called BadgeClass, so if HYPHA tokens were to become NFTs, each token share would then have the same BadgeClass, but still being unique. And you can count how many tokens of that same BadgeClass you own. This can also be seen as Badge "levels", for instance, if you have a "Coding skills" badge awarded to you once, it's level 1, but if you are awarded another badge with the same class, you can be seen as as having "Coding skills" level 2 now.

This is not very efficient for thousands or million of tokens, however, unless you use less tokens but each one has a different value (older ones more worthy, for example).

[julioholon]

For reference, here's how Mozilla OpenBadges are defined:

{
  "@context": "https://w3id.org/openbadges/v2",
  "id": "https://example.org/assertions/123",
  "type": "Assertion",
  "recipient": {
    "type": "email",
    "identity": "alice@example.org"
  },
  "issuedOn": "2016-12-31T23:59:59+00:00",
  "verification": {
    "type": "hosted"
  },
  "badge": {
    "type": "BadgeClass",
    "id": "https://example.org/badges/5",
    "name": "3-D Printmaster",
    "description": "This badge is awarded for passing the 3-D printing knowledge and safety test.",
    "image": "https://example.org/badges/5/image",
    "criteria": {
      "narrative": "Students are tested on knowledge and safety, both through a paper test and a supervised performance evaluation on live equipment"
    },
    "issuer": {
      "id": "https://example.org/issuer",
      "type": "Profile",
      "name": "Example Maker Society",
      "url": "https://example.org",
      "email": "contact@example.org",
      "verification": {
         "allowedOrigins": "example.org"
      }
    }
  }
}

[7flash]

I support the idea to enable users create their own badges within ecosystem and distribute them. For example, some campaigns might give badges for planting trees, making donations, executing quests, etc...

[julioholon]

After they are created only some fields can be changed.

Ways to lose badges:

• The issuer that created it can remove/expire it
• They can expire
• If the account is banned or deleted, what happens to the badges? (Nothing)

Any Resident account can create a badge (they become the issuer), just pay the fee. Contract accounts don't pay the fee.

Have a criteria field (hashmap) to indicate how to earn/lose the badge. For example:, Citizen badge? For quests, it can be the id of the Quest object that gave you that badge.

Badges scoped by user. Sorted by system badges first.

Badges as human readable milestones.

[n13]

Badges Contract

Overview

A generic badges contract

Each badge is defined in the badge_definitions table, has an id, an issuer, and other fields

The value of a badge is determined by who is processing it - seeds badges will be issued by Seeds and have value in the Seeds contracts, other badges can be created by anyone and obviously also interpreted by anyone.

A small fee is required to set up a badge.

Issuance

Anyone paying the fee can issue a badge - they are the issuer

Updates

Some fields can be updated by issuer, name, description, expiry, etc - everything except id and issuer. Updating a badge is not allowed if there is any active assignments!

Assignment

The issuer has the right to assign a badge to a user

No one else has the right

In the future we may consider giving other authorities the right to issue badges on behalf of the issuer (multisig).

Generic - icity

Token used to pay is configurable Amount for creating and maintaining is configurable Max expiry is configurable per call - so we can update it from our contracts

Cost examples

Cost: Creating a badge costs [333] Seeds Runtime: Maintain the badge costs [333] Seeds per year

Even system contracts have to pay the costs

Seeds used to create badges are burned when the badge is created.

Tables

sponsors ?

badge_definition (class)

• id
• issuer (account)
• revoker (optional, defaults to issuer)
• name (String)
• description (String, describes the eventual powers and perks you earn by having the badge)
• criteria (String, the criteria to earn/lose the badge)
• image (string, URI)
• levels (number os levels the badge has, defaults to 0)
• max_issues (max number of assignments, defaults to 0)
• expiration (max [N] moon cycles, defaults from a setting)

badge_assignments

• id (unique index)
• recipient (account)
• badge_id (index)
• evidence (string, memo of event that created this assignment, maybe a quest id, or URI, or 1 line reason)
• timestamp (datetime)
• level (current badge level, defaults to 0)
• expiration (defaults to badge expiration, can be less, not more)
• revoked (bool)
• revocation_reason (string, 1 line to explain why it was revoked)

Actions

Create Badge Update Badge Renew Badge

Assign Badge Revoke Badge Reinstate Badge (unrevoke) Renew Assignment

Besides the issuer, the recipient can always revoke the badge.

Only a Resident and above can create badges, and if they lose enough Rep so that they are no longer a Resident, all their badges are considered expired.

If a badge expires and is not renewed, all assignments that still exist, it will be considered expired thus now showing on any query.

Examples

Examples

issuer could be dho.hypha dho.seeds or any region that has a DHO, etc

[n13]

@juliolrmonteiro check out the badges definitions up there