Ceramic Points WG

The Ceramic Points Working Group (WG) had its first kickoff meeting on Feb 5, 2024 to discuss the opportunity for points within the Ceramic ecosystem, assign tasks, and discuss next steps. We have modified the notes from that original meeting into this document, which continues to improve with additional community exploration and contribution.

There is now also a Ceramic Points WG Telegram. Comment to be invited.

Collaborators: Sena (3Box Labs, cofounder), Rohhan (3Box Labs, product), Mark (3Box Labs, Partner Engineer), Billy (Intuition, founder), Charles (Orbis, cofounder), Walter (Disco, PM), Yannick (Oamo, CEO), Hira (Plurality, Cofounder), Ludo (Pact Social), Liang (US3R), Eshaan, Sofiane (Newcoin), Donat (Orbis)… list growing 😅.

1. Introduction

Points are like scorecards: one or more values assigned to a subject by an issuer, typically determined by computing an algorithm over various sources of onchain and offchain data.

1.1. Opportunity

Currently, points are being implemented by almost every major web3 project in a trustful, opaque, web2, Postgres way. Not only does this have obvious centralization downsides and risks, but it also makes it impossible for other projects to compose and reuse the points elsewhere, making it impossible for users to have any ownership and agency over their points data.

We believe that points can be the ERC-20 moment for Ceramic and the verifiable web. The opportunity before us is to specify a simple, standard points abstraction that everyone can integrate with and customize for their use case. Ultimately, this will provide the early standardization required to give birth to a new composable web3 data primitive and ecosystem. As a result, we expect the universal points standard (and its implementations) to generate a flurry of developer activity and experimentation using points on Ceramic as the backbone.

1.2. Use Cases

Points are an extremely useful primitive that have applications across a variety of industries and use cases. Here are some of the ones already relevant to Web3. Rohhan is compiling a list of projects and will be reaching out to conduct research and validation.

Loyalty & Marketing

Decentralized Points Implementations: Target existing points developers. Taking all the existing opaque, centralized, Postgres points implementations and get them onto Ceramic, a more verifiable, auditable, and composable system.
Rewarding Contributors: Projects can easily use the points protocol to create allowlists for things such as airdrops, or allocate rewards to contributors.
Cross-Project Engagement, Promotions, Partnerships: For example if we do 5 points on project A, 5 points on projet B, you'll get a multiplier. This is attractive because this is only possbile because the system is trustless/decentralized.
User Targeting: Target users for engagement or acquisition based on their points and events.
Target Customers -> Existing points developers and projects, Rainbow Wallet, Disco

Points vs Traditional Airdrops?
Points are an improvement over the existing system since they enable projects to target more genuine long term users as opposed to short term speculators.

Example: Current implementation of 🌈 Rainbow Points

Composable Reputation

Distribution: Reputation systems can distribute the proprietary outputs produced by their algorithm to other developers and easily integrate the data into other systems by issuing it as points on Ceramic. Points might represent their reputation scores (algo outputs) along with everything needed to verify/replay the results, including their data sources, algorithm, parameters, weights, etc.
Composability: Interestingly, these points can then subsequently be consumed by additional third-party reputation developers, to issue new reputations based on existing reputations.
Target Customers -> Gitcoin Passport, Other Reputation Systems/Providers, Large platforms & marketplaces that need user reputation

Example: 👩‍🚀 Gitcoin Passport as Points

Trust & Safety

Logging & Auditing: Universal verifiable logs, audits (e.g., for offchain actions - can create audit log for dapp.vactions that user or moderator has taken). Track and trace your data supply chain end to end, including all actions take by users.
Full-Stack Verifiability: (verifiability at each layer - e.g., events log, queries, indexers, computation. what pieces of the stack can be made trustless?)
Target Customers -> DAOs & DAO Tools, Analytics Platforms, Data Marketplaces and other Pooling Systems (e.g. Data Unions), Oamo, TODO

1.3. Principles

Protocol design is all about tradeoffs; here's what we strongly considered for UPS. To support the use cases above, we believe that points need to be:

Verifiable, to enable trustless points reuse and composition across contexts.
Scalable, to support use cases with billions+ of points transactions.
Composable, to build open network effects and provide maximum value to society.
Minimal, to be easily understood, used, and integrated into other systems.
Modular, to support a variety of compute systems, algorithms, data sources, etc.
Ossified, so others can trust the standard will not change out from under them – a strong requirement when deciding whether or not it's possible to build valuable things in the ecosystem.

1.4. Design overview

The points stantard consists of the points protocol and an ecosystem of data sources and integrations that can be used by points developers.

Universal Points Standard

This working group recognizes that multiple formats/interfaces for points will exist and aims to support the most common and useful ones. Keep in mind that even if one or two popular points interfaces per format emerge, it's still possible to transform between different schemas using some compute service such as Orbis plugins. The goal though is to have as few interfaces as required.

2. Ceramic-Native Points

Points should be stored on Ceramic as model instance documents that conform to the following model interface:

2.1. GraphQL Schemas (Mark)

Here's a quick example designed using Ceramic GraphQL Models. "Been messing around with building a simple local package using a 'site trigger' as a specific type that would implement a generic point":


interface Point
  @createModel(description: "A point interface") {
  controller: DID! @documentAccount
  recipient: DID! @accountReference
  issuanceDate: DateTime!
}

type SiteTriggerPoint implements Point
  @createModel(accountRelation: LIST, description: "An implementation of a point related to a trigger that occurred on a website")
  @createIndex(fields: [{ path: "issuanceDate" }]) 
  @createIndex(fields: [{ path: "page" }]) 
  {
  controller: DID! @documentAccount
  recipient: DID! @accountReference
  issuanceDate: DateTime!
  page: String! @string(maxLength: 100)
  trigger: SiteTrigger
}

enum SiteTrigger {
  PAGEVIEW
  QUERY
  CONVERSION
}

Then I was thinking it might be nice to have a "context" that could serve as the point of entry (representing an app or something even more granular):

interface Context 
@createModel(description: "A context interface for points")
{
  controller: DID! @documentAccount
  description: String @string(maxLength: 1000)
}

enum SiteTrigger {
  PAGEVIEW
  QUERY
  CONVERSION
}

type SiteContext implements Context
  @createModel(accountRelation: SINGLE, description: "An implementation of a site context for the Ceramic website")
  @createIndex(fields: [{ path: "uri" }]) 
  @createIndex(fields: [{ path: "trigger" }]) 
  {
  controller: DID! @documentAccount
  uri: String! @string(maxLength: 1000)
  description: String @string(maxLength: 1000)
  trigger: SiteTrigger!
}

interface Point
  @createModel(description: "A point interface") {
  controller: DID! @documentAccount
  recipient: DID! @accountReference
  issuanceDate: DateTime!
}

type SitePoint implements Point
  @createModel(accountRelation: LIST, description: "An implementation of a point related to action that occurred on a website")
  @createIndex(fields: [{ path: "issuanceDate" }]) 
  {
  controller: DID! @documentAccount
  recipient: DID! @accountReference
  issuanceDate: DateTime!
  contextId: StreamID! @documentReference(model: "SiteContext")
  context: SiteContext! @relationDocument(property: "contextId")
}

Load the relation back to all points for the context:

type SitePoint @loadModel(id: "$POINT_ID") {
  id: ID!
}

type SiteContext @loadModel(id: "$CONTEXT_ID") {
  points: [SitePoint] @relationFrom(model: "SitePoint", property: "contextId")
}

3. Verifiable Credential Points

3.1. IPSP (Newcoin)

Newcoin has an interesting approach they've been working to specify called Immutable Points Standard Protocol (IPSP) (video) that makes use of verifiable credentials (JSON-LD) to model points that are then stored on Ceramic.

3.1.1. IPSP Point

{
  "@context": "https://www.example.com/ipsp-context.jsonld",
  "templateID": "ipsp:1234567890",
  "issuer": {
    "id": "did:example:issuer123456"
  },
  "issuanceDate": "2023-12-01T02:33:55Z",
   "credentialSubject": {
    "id": "did:example:subject67890",
    "interaction": {
      "targetID": "https://example.com/content/1234",
      "timestamp": "2023-12-01T01:23:45Z"
    }
  },
  "proof": {
    "type": "Ed25519Signature2018",
    "verificationMethod": "did:example:issuer123456#keys-1",
    "signature": "ExampleDigitalSignature123456"
  },
  "provenance": {
    "author": "did:example:author98765",
    "normalizationProcess": "Normalized using standard algorithm XYZ"
  }
}

3.1.2. IPSP Context

{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.com/vocab#",
    "issuerType": 
{"@id": "vocab:issuerType", "@type": "@vocab"},
    "meritType": 
{"@id": "vocab:meritType", "@type": "@vocab"},
    "verifiabilityType": 
{"@id": "vocab:verifiabilityType", "@type": "@vocab"},
    "environment": 
{"@id": "vocab:environment", "@type": "@vocab"},
    "realWorldEnvironment": 
{"@id": "vocab:realWorldEnvironment", "@type": "@vocab"},
    "internetEnvironment": 
{"@id": "vocab:internetEnvironment", "@type": "@vocab"}
  }
}

Issuer Types

{
  "@context": {
    "@vocab": "http://example.com/vocab#",
    "schema": "http://schema.org/"
  },
  "@id": "http://example.com/vocab/IssuerType",
  "@type": "schema:Class",
  "schema:name": "IssuerType",
  "schema:description": "The type of entity that issues the points, which can be a person, organization, mechanism, or algorithm.",
  "subClassOf": {
    "@id": "schema:Thing"
  },
  "properties": {
    "Person": {
      "@id": "schema:Person",
      "@type": "schema:Class"
    },
    "Organization": {
      "@id": "schema:Organization",
      "@type": "schema:Class"
    },
    "Mechanism": {
      "@id": "http://example.com/vocab/Mechanism",
      "@type": "schema:Class"
    },
    "Algorithm": {
      "@id": "http://example.com/vocab/Algorithm",
      "@type": "schema:Class"
    }
  }
}

Person: An individual who has the authority or capacity to issue Points based on observed or measured merits.
Organization: A collective entity, such as a company, institution, or group, that issues Points through established protocols or consensus mechanisms.
Mechanism: An automated or semi-automated process that issues Points, often based on predefined criteria or through the interpretation of data.
Algorithm: A computational process that issues Points by following a set of coded instructions, often used in automated systems for scalability and consistency.

Merit Types

{
  "@context": {
    "@vocab": "http://example.com/vocab#",
    "schema": "http://schema.org/"
  },
  "@id": "http://example.com/vocab/MeritType",
  "@type": "schema:Class",
  "schema:name": "MeritType",
  "schema:description": "The type of merit the credential represents, such as personhood, participation, or knowledge.",
  "subClassOf": {
    "@id": "schema:Thing"
  },
  "properties": {
    "Personhood": {
      "@id": "http://example.com/vocab/Personhood",
      "@type": "schema:Property"
    },
    "Participation": {
      "@id": "http://example.com/vocab/Participation",
      "@type": "schema:Property"
    },
    // Additional properties as needed...
  }
}

Personhood: Recognition of an individual's identity and existence in a community or system, often used to acknowledge participation rights or membership.
Participation: Active involvement in a community or activity, where Points are awarded for engagement or contribution.
Curation: The act of selecting, organizing, or presenting information or content, with Points awarded for contributing to the quality or accessibility of the curated collection.
Knowledge: Acknowledgment of an individual’s expertise or informational contributions, where Points are a measure of intellectual input or educational value.
Influence: The capacity to have an effect on the character, development, or behavior of someone or something within a network or system.
Discernment: The ability to make considered decisions or come to sensible conclusions, with Points awarded for demonstrating judgment or insight.

Verifiability Types

{
  "@context": {
    "@vocab": "http://example.com/vocab#",
    "schema": "http://schema.org/"
  },
  "@id": "http://example.com/vocab/VerifiabilityType",
  "@type": "schema:Class",
  "schema:name": "VerifiabilityType",
  "schema:description": "The nature of the verifiability applied to the credential, including mechanistic, optimistic, or agentic types.",
  "subClassOf": {
    "@id": "schema:Thing"
  },
  "properties": {
    "Mechanistic": {
      "@id": "http://example.com/vocab/Mechanistic",
      "@type": "schema:Property"
    },
    "Optimistic": {
      "@id": "http://example.com/vocab/Optimistic",
      "@type": "schema:Property"
    },
    "Agentic": {
      "@id": "http://example.com/vocab/Agentic",
      "@type": "schema:Property"
    }
  }
}

Agentic: Involves a degree of subjective evaluation by either humans or algorithms that may not be readily verifiable by third parties. Points issuance based on agentic verifiability relies on the reputation and perceived trustworthiness of the issuing agent, which may be an individual, a group, or an algorithmic curator. This type of verifiability is typically used in situations where the value of contributions is assessed qualitatively rather than quantitatively.
Optimistic: This verifiability type is rooted in a transparent and auditable process, where Points are issued by a backend system based on verifiable data. The hash of the underlying data, along with the algorithm used for computing Points, is made public, enabling anyone in the network to verify the correctness of the Points awarded. Optimistic verifiability assumes that the issuance is correct unless proven otherwise, with the open availability of the algorithm and data acting as a safeguard against errors or manipulation.
Mechanistic: Points issuance under mechanistic verifiability occurs through an entirely deterministic and automated process, such as a smart contract on a blockchain. This method ensures that Points are awarded strictly according to predefined rules and conditions that are encoded into the smart contract, leaving no room for subjective interpretation or discretion. Mechanistic verifiability is characterized by its high level of reliability and the ability for anyone to independently verify the issuance of Points by observing the contract's execution and outputs.

Environment Types

{
  "@context": {
    "@vocab": "http://example.com/vocab#",
    "schema": "http://schema.org/"
  },
  "@id": "http://example.com/vocab/VerifiabilityType",
  "@type": "schema:Class",
  "schema:name": "VerifiabilityType",
  "schema:description": "The nature of the verifiability applied to the credential, including mechanistic, optimistic, or agentic types.",
  "subClassOf": {
    "@id": "schema:Thing"
  },
  "properties": {
    "Mechanistic": {
      "@id": "http://example.com/vocab/Mechanistic",
      "@type": "schema:Property"
    },
    "Optimistic": {
      "@id": "http://example.com/vocab/Optimistic",
      "@type": "schema:Property"
    },
    "Agentic": {
      "@id": "http://example.com/vocab/Agentic",
      "@type": "schema:Property"
    }
  }
}

{
  "@context": {
    "@vocab": "http://example.com/vocab#",
    "schema": "http://schema.org/"
  },
  "@id": "http://example.com/vocab/InternetEnvironment",
  "@type": "schema:Class",
  "schema:name": "InternetEnvironmentType",
  "schema:description": "Covers various online contexts where the credential may be relevant, such as social networks, e-commerce platforms, or educational sites.",
  "subClassOf": {
    "@id": "schema:Thing"
  },
  "properties": {
    "SocialNetwork": {
      "@id": "http://example.com/vocab/SocialNetwork",
      "@type": "schema:Property"
    },
    "ECommerce": {
      "@id": "http://example.com/vocab/ECommerce",
      "@type": "schema:Property"
    },
    "Educational": {
      "@id": "http://example.com/vocab/Educational",
      "@type": "schema:Property"
    },
    "SearchEngine": {
      "@id": "http://example.com/vocab/SearchEngine",
      "@type": "schema:Property"
    },
    "RLHF": {
      "@id": "http://example.com/vocab/RLHF",
      "@type": "schema:Property"
    },
    "Podcast": {
      "@id": "http://example.com/vocab/Podcast",
      "@type": "schema:Property"
    }
    // Additional internet environment properties can be included here...
  }
}

Real World: Pertains to physical spaces and interactions where Points are used to represent value in tangible settings and activities.
Internet: The digital landscape where Points are used to represent value in online platforms, services, or communities.
- Social Network: Online platforms where individuals interact, share content, and build communities, with Points often reflecting engagement or network growth.
- E-Commerce: Digital marketplaces where Points can represent trustworthiness, customer satisfaction, or transaction history.
- Educational: Platforms or services related to learning and knowledge-sharing, with Points awarded for educational achievements or contributions.
- Search Engine: Online tools that index and retrieve information, where Points could be used to signify content relevance or quality.
- RLHF (Reinforcement Learning from Human Feedback): Systems that learn and adapt from direct human input, with Points awarded based on the value or impact of the feedback provided.
- Podcast: A digital audio platform where Points could represent listener engagement, content quality, or contribution to discussions.

2.2.2. Example (Ludo)

Ludo committed to working on an interface design, I think based on VCs.

4. Ethereum Attestation Service Points

2.3.1. Example (Eshaan)

Eshaan took on the task of thinking through the EAS inplementation.

3. Roles

There are four primary roles: issuer, subject, consumer and verifier.

3.1. Issuers

Points issuers are services that source data, run their algorithm, compute points, and write scores back to Ceramic. Points issuers are in the business of producing points with their algorithm. In order for their algorithm to work, they need to inregrate with data sources, either proprietary or third-party. One big opportunity to explore in this area is automating point generation/creation.

Points Algorithms

Points algorithms are essentially reputation algorithms that have parameters/weights assigned to various data sources. In this protocol, the aim is to have points algorithms be configurable. Not all points issuers need to make their algorithm public, so this is completely up to each implementer.

Language: What language are these algorithms written in? How are they written?
DX: How do developer users apply different algorithms to data?
Anti-Sybil: Is this the proper place to consider where to specify anti-sybil methods utilized by the algo? Or should anti-sybil be specified separate from the algo but on the points implementation?

Issuer Reputation

A fairly large open question in this area is the role of reputation for points issuers…

Issuer Examples

Gitcoin Passport can issue points for stamps and scores
Newcoin/Newgraph: Algorithmic points
Oamo can issue points for Ethereum, Arbirtrum, etc network activities
Plurality Network: Identity verification points?
3Box Labs can issue points for Ceramic community activity
Galxe/Guild can issue points for each guild's activities

3.2. Consumers

Consumers are entities that consume points data.

3.3. Verifiers

Points consumers are often required perform extra verification beyond signature verification when considering how to evaluate the merits of a point. In many cases, consumers need to consider additional metadata about the issuer such as identity and reputation.

Theoretically, consumers can be their own point verifier; this is likely true in only the most simplistic cases. Most verifications will be performed by specialized verifiers (reputation services) who provide additional context. Additional reputation-based verification methods are out of band of the core protocol. However, the existence of one or more verifier/issuer identity/reputation services would certainly be useful to the overall protocol. In the most basic sense, these could be delivered as an API, SDK, plugin, dataset, etc that expose additional issuer and verification metadata that complements and augments the original points dataset.

4. Integrations

In order to have a maximally useful points protocol, we should ensure that there are a large variety of data sources and integrations available for points developers to use. Points developers may use one or more data sources at a time.

4.1. Source 1: Verifiable Event Dataset on Ceramic

This option describes integrating with the Verifiable Event dataset on Ceramic. This dataset allows Ceramic to function as a universal data integration layer and middleware, enabling all kinds of indirect data integrations.

Many different kinds of data sources can be used by points algorithms: some verifiable and some not, some onchain and some offchain, some served by web2 API, etc… which presents a challenge. How can I prepare an/my input data source/dataset for maximum integration with as many points systems as possible?

On Ceramic we need to collectively generate a new dataset, defined by the following model interface, which stores verifiable events using Ceramic as a data warehouse – an intermediate step for later computing these events into points.

`Verifiable Event` Interface

Can we create a simple schema/interface for events that is universal so that all new builds can work from a used standard (similar to ERC20/ERC721)? One approach could be storing all input datasets as events in a larger, global Verifiable Event Dataset on Ceramic. Ceramic as a decentralized, verifiable event warehouse. In this model, points issuers would consume their data from Ceramic in the form of a universal verifiable event. Can we design a model interface that can provide the required information for a historical event such that a third party can trustlessly take it and use it?

Specify the universal event interface

How do you/can you make events verifiable?
Should it be a verifiable credential interface? Something else?
How do you add context to events?

Use Cases

Onchain Data: Create events for onchain data and turn it into Ceramic data. Requires preparation, normalization, etc. This is like integrating on-chain EAS or Verax attestations
Offchain Data: Write your data events, stamps, credentials, actions, etc to Ceramic as a middle layer, where they can super easily be consumed by the points protocols.

Although it would be nice for everything to be intermediately stored on Ceramic as a middle transformation layer, that's unlikely. Let's continue to explore other options for integrating data sources into your points algorithm.

4.2. Source 2. Miscellaneous Datasets on Ceramic

Technically all Ceramic data is already fully-verifiable so can be considered a legitimate data source for use by points developers. Since the data already exists on the network but is not part of the Verifiable Event dataset, devs will have to do more manual work when gathering the dataset, applying content and meaning, and computing over it, since schemas could differ.

4.3. Source 3. Onchain Data

Onchain data is already strongly verifiable, so as long as you can easily query the onchain dataset(s) you need for your point algorithm, there's no explicit need to store data intermediately as an event on Ceramic. For onchain data, developers will usually consume data directly from chain or some index of the chain, such as The Graph's subgraphs.

One highly relevant onchain dataset is EAS attestations. In this case, I'm not referring to the attestations stored on Ceramic; I'm referring to the ones stored onchain.

4.4. Source 4. Offchain Data

Offchain data is all the data generated and/or used by applications that does not exist on a public blockchain network. Can offchain data be quantified in a standard format to be used as input for points? (e.g., interests). In these cases, it might be easier to use Ceramic's Verifiable Event dataset to facilitate these integrations.

Web2 Databases (e.g. Postgres):
Web2 APIs:

5. Implementations

5.1. MVP

It might be a good idea to dogfood the MVP ourselves, by logging offchain interactions with the Ceramic Docs site, so that we can give points to our top engagers. In my mind, it could be extremely simple andd straightforward to create an MVP to serve this use case with the following components:

Points Interface: Described above.
OrbisDB Points Plugin: A Points Plugin could be created for OrbisDB that allows Orbis developers to build with points (issue, query, verify).
Verifiable Event Logger: The verifiable event logger could be a product that consists of two components: a server to log verifiable events to Ceramic, and an SDK to trigger events from the application. The SDK would work similar to Segment.io. It would allow applications to log actions taken throughout their product. One immediate use case would be to record actions taken on the Ceramic developer documentation site.

5.2. Additional Implementation Ideas

Onchain Data

Oamo could add their credentials publicly to the Verifiable Event dataset
Oamo could add their credentials privately encrypted to the Verifiable Event dataset, and enable decryption using something like an OrbisDB plugin

6. Additional Info

6.1. Privacy Considerations

Public & Private Points: Builders choose if their individual points systems are private or not. Users choose if they want to share private points with 3rd-parties.
Consent is Key. Users are okay with some things being public, but for other things they may want to opt into it being public vs private.
Public Onchain Data Sources: Onchain data sources will already be public.
Private Data Sources: Data sources may or may not be encrypted. Algorithms should be able to support both.

6.2. Possible Value Flows

What are the business models enabled by this standard? How can an ecosystem of valuable businesses develop? What are the possible incentives?

Issuers: Earn for originating points; Pay for recomposing points
Subjects: Earn for granting access
Consumers: Pay for accessing points; pay for verifying points (extra)
Verifiers: Earn for verifying points

7. Next Steps

Broaden the WG
~~- Follow up with Newforum and invite to this WG. New foundation is working on: IPSP (immutable point system). (Hira)~~
Perform rapid discovery to quickly validate needs and idea
- Help track down USE CASES + CUSTOMERS (Walter) and validate them to inform protocol design
- Input on DATA REQUIREMENTS (Billy)
- Follow up with Gitcoin to see if there are any learnings from their PoH / sybil learnings (Charles)
Define the system
- Define the system architecture (e.g., log events, schemas) (Charles, Yannick)
- Define the Points Interface (Ludo)
- Define how to do SCHEMA DISCOVERY and the INDEXING layers (for someone else to compute on) (Charles, Yannick
- Explore how are we sybil resistant. (Ludo)
- Define the VERIFIABLE EVENT SCHEMA for how offchain events are stored/represented on Ceramic (Hira)
- Input into attestation perspective and design (Eshaan)
Define simple, valuable MVP(s)
Finalize and share this document with the community
Build!

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`	在筆記中貼入程式碼
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.

Ceramic Points WG

1. Introduction

1.1. Opportunity

1.2. Use Cases

1.3. Principles

1.4. Design overview

2. Ceramic-Native Points

2.1. GraphQL Schemas (Mark)

3. Verifiable Credential Points

3.1. IPSP (Newcoin)

3.1.1. IPSP Point

3.1.2. IPSP Context

2.2.2. Example (Ludo)

4. Ethereum Attestation Service Points

2.3.1. Example (Eshaan)

3. Roles

3.1. Issuers

Points Algorithms

Issuer Reputation

Issuer Examples

3.2. Consumers

3.3. Verifiers

4. Integrations

4.1. Source 1: Verifiable Event Dataset on Ceramic

Verifiable Event Interface

Use Cases

4.2. Source 2. Miscellaneous Datasets on Ceramic

4.3. Source 3. Onchain Data

4.4. Source 4. Offchain Data

5. Implementations

5.1. MVP

5.2. Additional Implementation Ideas

6. Additional Info

6.1. Privacy Considerations

6.2. Possible Value Flows

7. Next Steps

`Verifiable Event` Interface