In computer programming, a primitive is a basic interface or segment of code that can be used to build more sophisticated program elements or interfaces

Existing Solidity Primitives

• ERC-1238 - Non-transferrable Non-Fungible Tokens (badges)
• ERC-1155 - Multi Token Standard

Emblem Solidity Primitive

v1 primitive

• Borrows many concepts from ERC-1238 and ERC-1155.
  • every Ethereum address is an identity by default
• Polygon Registry contract exposes a “hasBadge(id, address) → address” function
  • id is a BadgeDefinitionId from the subgraph, which refers to:
    • a metric type (number of indexers delegated to, number of allocations opened)
    • a number representing the threshold an account must cross in order to earn the badge
  • the address parameter is the address of the account we’re checking for badge ownership
  • returns the address of the oracle that posted the Merkle root used to unfurl the badge
  • returns 0x0 if account doesn’t have badge
• At a rudimentary level, you can think of this reputation primitive as an immutable, non-transferable statement about a public key made by an issuer (another public key).
  • In our design, the badge issuer is the oracle that posted the Merkle root used to unfurl the badge. This doesn’t need to be the same account that unfurls the badge.
  • The scope of the statement being made is entirely arbitrary with respect to the primitive. We chose to represent the statement as a BadgeDefinitionId to allow for complex meaning to be defined in a subgraph rather than on-chain.
    • Outside Emblem, a badge could be a “statement” from DMV.eth claiming that the owner of an account holds a valid drivers license
    • Emblem awards badges in the Reputation Subgraph, so the scope of statements that can be made using Emblem lay strictly in the land of blockchain determinism. This may seem limiting, but it allows for a transparent oracle service, because data being posted by oracles is easily verifiable.
• We are also actively researching a primitive for representing snapshots of account metadata.
  • For example, account A claims that account B is delegating to 3 indexers, curating on 5 subgraphs, and providing $5532 of liquidity in the GRT/ETH Uniswap pool at block 1000000.

v1 subgraph primitive

"""
BadgeDefinitions are created by the BadgeDefinitionManager smart contract.
Subgraphs may also have genesis BadgeDefinitions that are baked in for retroactive
drops.
"""
type BadgeDefinition @entity {
  "incrementing number"
  id: ID!
  "Name of badge"
  name: String!
  "Description of badge"
  description: String!
  "IPFS URI containing metadata about this BadgeDefinition"
  ipfsURI: String!
  "Metric being tracked"
  metric: BadgeMetric!
  "Value that metric must reach in order for a badge to be awarded"
  threshold: BigInt!
  "Community score given when badge is awarded"
  communityScore: BigInt!
  "Total count of earned badges"
  earnedBadgeCount: Int!
  "Badges awarded with this definition"
  earnedBadges: [EarnedBadge!]! @derivedFrom(field: "definition")
}

v2 primitive

• Subgraph Bridge Generalization
• Account Syncing