Vellum, extended: from identity to reputation on did:ckb

English CKB Development & Technical Discussion
, ,
1

Following the earlier discussion on services.profile standardisation and @janx’s note that an open standard should ship with at least one application, I want to share where Vellum goes next.

Quick recap

The next chapter: reputation on the same DID

Vellum is going to extend from identity into reputation. The same did:ckb that holds your profile will also hold a queryable record of what you have done in the CKB ecosystem. The intent is to directly answer @janx’s bar: the standard, plus at least one working application that uses it, both shipped together.

Two kinds of data sit against a single DID:

  • Self-declared identity stays where it already is: services.profile, alsoKnownAs, verificationMethods in the DID Document. The holder writes and edits this.
  • Externally-issued claims live as small Cells attached to the same DID. Each Cell is one signed statement from one issuer about one subject. The subject’s lock script controls every claim Cell, so the holder can destroy any specific record at any time and recover its capacity.

Two storage shapes, one DID. The first is what you say about yourself. The second is what others have observed and signed off on. Together they form a portable footprint.

What goes into a claim Cell

A minimal shape:

{
  issuer:    did of who is making the claim
  subject:   did of the builder being claimed about
  schema:    short string naming the claim kind, eg "vellum.github.v1"
  payload:   DAG-CBOR, schema-specific
  issued_at, expires_at?, issuer_signature
}

Schemas are conventions, not contracts. New schemas don’t need a contract upgrade. A few that will ship in v1:

Schema Issuer Carries
vellum.github.v1 Vellum (via OAuth proof) verified handle, recent commit/PR counts
vellum.x.v1, vellum.discord.v1, vellum.bluesky.v1, vellum.telegram.v1 Vellum (via OAuth, bot-issued codes, or post-with-DID proofs) verified handle, basic activity counters, ecosystem-group membership where applicable
vellum.onchain.v1 Vellum (computed from chain) first tx block, tx count, DID age, protocols used
vellum.task.v1 Build on CKB reviewers task id, link, rating, completed_at
vellum.milestone.v1 Fellowship reviewers cohort, admitted/completed timestamps
vellum.score.v1 Vellum (computed snapshot) aggregated overall + breakdown by dimension

Reading: a structured record, not just a number

A reputation read returns a structured object. The default snapshot looks like:

{
  identity: { displayName, avatar, bio, alsoKnownAs, verificationMethods },
  verified_socials: {
    github:   { handle, commits_90d, prs_90d },
    x:        { handle, followers },
    discord:  { handle, server_tenure_days, roles },
    telegram: { handle, ckb_groups, member_since },
    bluesky:  { handle }
  },
  onchain: { first_tx_block, tx_count, did_age_days, protocols },
  recognitions: {
    tasks: [ { task_id, rating, reviewer, date }, ... ],
    milestones: [ { cohort, admitted, completed, outcomes }, ... ]
  },
  computed: {
    overall: 87,
    breakdown: { technical: 92, community: 78, tenure: 65, contribution: 90 },
    trend_30d: "rising",
    last_active: "2026-06-15"
  }
}

Consumers that just want one number can take computed.overall. Consumers that want nuance can use the breakdown. Consumers that want their own algorithm can ignore the score Cell entirely and recompute over the raw fact Cells with their own weights. Same data, three audiences.

Two design calls worth flagging

  1. On chain, not in Vellum’s database. Reading a builder’s reputation does not depend on Vellum being online. The data lives on chain, queryable directly by anyone with a client or a few SDK lines.
  2. The subject owns every claim Cell. The holder controls the lock script on every record about them; they can destroy any specific claim and recover its capacity. Privacy through retention, not visibility. The Cell model makes this a single Type Script.

Sample use cases

Not theatre. Real users with real decisions:

  1. Build on CKB task review. Reviewer sees a submission, looks at the builder’s prior task history and technical dimension at a glance. Score is one input, not the decision.
  2. CKBuilders fellowship admission. Cumulative track record visible per candidate. Trends, tenure, prior task completions on one page.
  3. Sub-DAO voter eligibility. Sub-DAO sets a rule like “voters need overall >= 50 OR at least one fellowship completion”. Reads the on-chain record, gates accordingly.
  4. Sub-committee selection. Pick by dimension. Top 5 by community for the events committee, top 5 by technical for security review. Same data, different slice.
  5. Sybil resistance for future quadratic-funding rounds. Eligibility based on verified socials and minimum CKB activity. Used as a gate, not a vote weight, following the pattern that worked in Optimism RetroPGF and similar systems.
  6. Public builder profile page. Inside Vellum at /profile/<did>. Browse a builder’s full record. Doubles as ecosystem recruitment material.

The first three are Vellum’s day-one consumers. The rest are second-tier consumers needing nothing built; they just read with a few lines of code.

Real-world integration examples

The claim Cell format is open. Any existing CKB platform can plug in as an issuer without changing its core product, by signing a small claim each time it observes something worth recording. Two concrete examples on CKB today:

CKBoost runs several community programs (the task board where Build on CKB tasks live, hackathons, bounties, and other coordinated builder activities) and carries its own identity layer. Three integration paths open up, in increasing order of effort on CKBoost’s side:

  1. Vellum reads, issues itself. Vellum pulls public CKBoost activity (task completions, hackathon participation, bounty outcomes, etc.) and writes claims like vellum.ckboost_task.v1 and vellum.ckboost_hackathon.v1 against the linked DIDs. Lower-trust because Vellum is the signer, but it works with zero coordination from CKBoost.
  2. CKBoost signs its own claims. When a CKBoost user completes a task, finishes a hackathon, or hits any other milestone CKBoost tracks, CKBoost signs a claim against the user’s did:ckb under its own namespace (ckboost.task.v1, ckboost.hackathon.v1, and so on). CKBoost keeps its internal identity system; nothing breaks. Their users gain a portable, strong-trust layer on top.
  3. Deeper integration over time. CKBoost could accept did:ckb sign-in alongside its current identity. Bigger lift; only if the team actively wants it.

For CKBoost: users keep their accounts, the platform stays as it is, and the team signs one claim per recorded event. In return, CKBoost activity (tasks, hackathons, bounties, programs) becomes portable across the ecosystem, those events become permanent on-chain records, and CKBoost shows up as the issuer on every builder’s portfolio page. The work CKBoost already coordinates gains broader reach.

CKB-PoP (@RobaireTH’s proof-of-attendance protocol) already runs on CKB, issuing non-transferable badges via QR-based check-in. Several of the open questions in their project review map directly onto what this extension provides:

CKB-PoP open question What this provides
Extending beyond attendance to other verifiable credentials Schemas are conventions; ship ckbpop.attendance.v1 today, add ckbpop.workshop.v1 and others later with no contract upgrade
Paths toward eliminating backend dependency Proofs become Cells signed by the organizer’s DID; verifiers read the chain, not the backend
Cell capacity sponsorship for new users Vellum Sponsor handles this as shared infrastructure
Explorers displaying badges as “unknown assets” A standard Cell shape for claims means explorers can recognize and render them uniformly across issuers

Verification is one signature check against the organizer’s published DID. Subject-controlled Cells also let attendees keep or destroy any specific badge.

The same path is open to any other CKB platform. Spore could issue ownership claims, a future grant DAO could issue grant-completion claims, a wallet provider could issue activity attestations. Be an issuer, get credit, give your users portability.

Onboarding: capacity sponsorship

A new builder coming from AT Protocol, Bluesky, or Nostr who doesn’t yet hold CKB shouldn’t be blocked from claiming a DID. Vellum will provide a sponsored mint path: a Vellum-operated sponsor lock pays for the initial Cell capacity; the holder reclaims sovereignty (and the capacity) once they fund their own wallet. This is the same pattern cb.id and uni.eth use via ENS CCIP-Read on Ethereum. On CKB it fits cleanly into a single Type Script.

What is deliberately NOT in scope

  • Reputation-weighted voting at the protocol level. Lessons from RetroPGF and similar systems point to score-gates plus equal-weight aggregation as the more robust pattern.
  • A single opaque score as the only readable output. The convenience number is there, but the structured breakdown is the substance.
  • ZK proofs without a verifier. Transparency works better at this scale; the prior Haven ZK layer (GitHub - truthixify/haven · GitHub) is deliberately not carried over.
  • Building a competing task platform or governance contract. Vellum is the reputation layer; existing tools like CKBoost own those domains and can plug in as issuers (see worked example above).
  • Cross-chain reputation export. Out of v1 scope; the format is open, so it remains possible later.

Integration surface for other CKB apps

Two SDK calls (planned additions to @ckb-ccc/did-ckb) cover the read and write paths:

import { readClaims, writeClaim } from "@ckb-ccc/did-ckb";

// A sub-DAO checking voter eligibility:
const claims = await readClaims(client, {
  subject: builderDid,
  schemas: ["vellum.score.v1", "vellum.milestone.v1"],
});

// A reviewer issuing a task completion:
await writeClaim(signer, {
  subject: builderDid,
  schema: "vellum.task.v1",
  payload: { task_id: 42, rating: 5, link: "..." },
});

That is the entire surface area for integration. Roughly ten lines to gate a voter set. Twenty lines to issue a recognition. Nothing on the integrator’s end needs to be built or hosted.

Open questions for feedback

A few things I would value input on before the WIP draft:

  1. Should vellum.score.v1 ship with a default weighting, or only the breakdown without an aggregated number? Defaults attract gaming; no defaults raise integration cost.
  2. Proof-of-personhood: integrate Human Passport / World ID via a wrapping claim, or build a CKB-native equivalent? Wrapping is faster; native gives more control.
  3. Are there issuers beyond Build on CKB, the fellowship, CKBoost, and CKB-PoP (per the worked examples) that should be considered for v1?
  4. Any apps actively planning sub-DAO governance that would commit to consuming reputation gates at v1? That commitment is what turns this from “standard with one application” into “standard with several applications”.

Next steps

Vellum’s prior work is in this repo: GitHub - truthixify/vellum: Dashboard for managing did:ckb identities. Your identity, on paper that lasts. · GitHub. The original Haven prototype (the ideas this reputation layer borrows from, minus the ZK layer) is at GitHub - truthixify/haven · GitHub. Both are linked here for reference, not as separate products. The grant funds Vellum’s next chapter, in one piece.

Happy to discuss any of the above, especially the sample use cases. The answer to @janx’s “standard plus at least one application” question depends on which applications actually commit to reading the data, so the more concrete the consumer commitments, the stronger the proposal.

7 Likes
CKB Ecosystem Biweekly Update
[DIS] Vellum: Reputation Extension on did:ckb
2

If the claim cell is owned by subjects, where the capacity originates from?

It’s interesting design to let subjects destroy claim cells on them. The live cells are bidirectionally approved claims, while the dead cells are rejected by subjects but still accessible in the blockchain history.

4 Likes