CIP-0148 - On-Chain DRep Credential & Extended Governance NFTs

Table of Contents

• Table of Contents
• 1. Abstract
• 2. Motivation
• 3. Specification
  • 3.1 Relationship to Other CIPs
  • 3.2 DRep and Proposal Identifiers
  • 3.3 Off-Chain Metadata Anchors (CIP-100, CIP-108, CIP-119)
  • 3.4 CIP-68 Datum Format
  • 3.5 CIP-67 Asset Labeling
  • 3.6 NFT Types in CIP-148
    • 3.6.1 DRep Credential
    • 3.6.2 Ballot Note
    • 3.6.3 Endorsement
  • 3.7 CDDL Schemas (Conceptual)
  • 3.8 Usage & Implementation Notes
  • 3.9 Summary of Requirements
• 4. Rationale: How Does This CIP Achieve Its Goals?
• 5. Path to Active
  • Acceptance Criteria
  • Implementation Plan
• 6. Versioning
• 7. Copyright

---

1. Abstract

CIP-148 proposes a flexible on-chain metadata framework that extends Cardano’s CIP-1694 governance era by bridging minimal ledger logic with richer ecosystem insights. Leveraging CIP-68’s datum-based NFTs, this CIP defines three specialized token types:

1. DRep Credential – A self-reported, on-chain “profile” that references CIP-119 data or other extended metadata.
2. Ballot Note – An optional record capturing a dRep’s vote choice and rationale.
3. Endorsement – A third-party NFT enabling verifiable, decentralized “social proof.”

By referencing CIP-119 for large off-chain content, CIP-148 avoids on-chain bloat while supporting dynamic “ecosystem mapping.” These NFTs empower Delegated Representatives (dReps) to share achievements or motivations (DRep Credential), the community to track rationales (Ballot Notes), and supporters to issue endorsements they fully control. The result is a trust-minimized “human sensor network” that enhances governance transparency and fosters advanced analytics for delegators. CIP-148 does not replace CIP-1694’s core governance rules but provides building blocks for deeper insight, letting tools index and map Cardano’s governance landscape more effectively.

---

2. Motivation

Cardano’s CIP-1694 governance framework introduces on-chain voting and delegation, yet delegators often lack reliable data on which dReps are most aligned with their goals. Off-chain forums, social media posts, and unstructured approaches leave critical governance insights fragmented and difficult to verify. This lack of easily discoverable, trustworthy information can lead to suboptimal delegations and reduced community engagement.

CIP-148 addresses these challenges by proposing a structured, on-chain metadata standard that supplements CIP-1694 without altering its core mechanics. It empowers:

• DReps to publish a “credential” NFT linking to their qualifications and off-chain data (via CIP-119 references).
• Delegators to evaluate dReps’ self-reported achievements, voting rationales, and social endorsements all in one place.
• Endorsers (SPOs, DAOs, community members) to mint verifiable tokens of support, creating a decentralized “social proof” layer.

This metadata-rich environment allows Cardano participants to build analytics tools and ecosystem maps that highlight dRep performance and influence. By defining three specialized NFT types—DRep Credential, Ballot Note, and Endorsement—CIP-148 ensures transparency, accountability, and discoverability for the next phase of Cardano governance.

---

3. Specification

This section defines how CIP-148 leverages existing Cardano improvement proposals to introduce three NFT types—DRep Credential, Ballot Note, and Endorsement—under CIP-68. We clarify:

1. DRep and Proposal IDs (from CIP-1694).
2. Off-chain metadata anchors (from CIP-100 family, including CIP-108 for proposals and CIP-119 for DRep metadata).
3. Datum-embedded NFT structures (from CIP-68).
4. Asset name labeling (from CIP-67).

3.1 Relationship to Other CIPs

1. CIP-1694 – On-chain Governance Framework

   • DRep ID: A blake2b-224 hash of the DRep’s key or script credential.
   • Proposal (Governance Action) ID: Composed of the proposal’s transaction hash plus an index within that transaction.
   • CIP-148 must not redefine these terms; it uses them exactly as CIP-1694 describes.

2. CIP-100 – Base Governance Metadata Format (JSON-LD)

   • CIP-148 references CIP-100’s anchor (URL+hash) approach to store large metadata off-chain.
   • CIP-100 is extended by CIP-108 (for governance actions) and CIP-119 (for DRep data).

3. CIP-108 – Governance Action Metadata

   • Defines how proposals (governance actions) store off-chain data (e.g. rationale, category).
   • CIP-148’s Ballot Note NFT can point to CIP-108-compliant JSON if it needs detailed proposal context.

4. CIP-119 – DRep Metadata

   • Focuses on DRep off-chain data.
   • CIP-148’s DRep Credential NFT can reference CIP-119 anchors to avoid on-chain bloat.

5. CIP-68 – Datum-Based NFT Metadata Standard

   • CIP-148 uses CIP-68’s #6.121 constructor (the [metadataMap, version, extra] tuple).
   • This ensures wallets and explorers can parse CIP-148 NFTs consistently.

6. CIP-67 – Asset Name Label Registry

   • CIP-148 can define or use a label for its governance NFTs (e.g., (148) or (1694)).
   • The asset name must incorporate a valid CIP-67 label prefix with the correct CRC-8 checksum.

---

3.2 DRep and Proposal Identifiers

1. DRep ID

   • A 28-byte blake2b-224 digest of the DRep’s credential (key or script), per CIP-1694.
   • Everywhere CIP-148 references a DRep, it must store this dRepId exactly.
   • Tools verifying a DRep NFT should confirm the on-chain DRep credential matches the hashed ID.

2. Proposal ID

   • CIP-1694 proposals are identified by (txHash, index).
   • For CIP-148, the simplest approach is to store or hash (txHash || index) to form a single “proposalId” string or bytes.
   • Alternatively, the Ballot Note NFT’s metadata can store the separate components.

Example:

proposalId: "1234abcd...ff (tx hash) + index = 1"

(Implementers should clarify how they combine or encode these fields, but must not conflict with CIP-1694’s official definition.)

---

3.3 Off-Chain Metadata Anchors (CIP-100, CIP-108, CIP-119)

CIP-148 does not store large text or images on-chain. Instead, each NFT can include:

• cip119AnchorUrl and cip119AnchorHash for DRep-related data (CIP-119).
• proposalAnchorUrl and proposalAnchorHash for proposal-related data (CIP-108).
• The anchor must be (url, blake2b-256 hash) so clients can fetch and verify the content.

---

3.4 CIP-68 Datum Format

All CIP-148 NFTs adhere to the three-field CIP-68 structure:

<cip148-datum> = #6.121([
  metadataMap,
  version:int,
  extra:plutus_data
])

1. metadataMap (map) – Contains keys (strings) mapped to data (strings, bytes, lists, or nested maps).
2. version (int) – The CIP-148 schema version (≥ 1).
3. extra (plutus_data) – Typically {} or empty unless implementing custom logic.

CIP-68 Two-Token Model:

• If the platform needs updatable data, it might split into a “reference NFT” locked in a script plus a “user token” (following CIP-68’s recommended pattern).
• CIP-148 does not force two tokens if a single NFT is sufficient.
• Implementers must still ensure the NFT’s datum is recognized as #6.121 in the output holding the CIP-68 reference.

---

3.5 CIP-67 Asset Labeling

All CIP-148 NFTs should use a CIP-67 label in their asset name. For example:

(148)drepCredential-<uniqueEncodedString>
(148)ballotNote-<proposalIDHash>
(148)endorsement-<endorserID>-<drepID>

Where (148) is either a reserved label for CIP-148 governance NFTs or a label you define with the CIP-67 process. The important point:

• The label number is an unsigned 16-bit integer (0–65535).
• It must be combined with the CIP-67’s CRC-8 checksum to produce the final 4-byte prefix.
• CIP-148 can propose a new label or reuse an existing CIP-68 label if appropriate.

Example: If label “148” is assigned, the asset name might begin with 000fa400 (the exact hex depends on the CIP-67 encoding).

---

3.6 NFT Types in CIP-148

3.6.1 DRep Credential

• Minted By: The DRep.
• Purpose: On-chain “profile” with references to CIP-119 data.
• Keys in metadataMap (minimum):
  • "dRepId": The CIP-1694 hash.
  • "cip119AnchorUrl" / "cip119AnchorHash" (optional, for large DRep data).
  • Additional extended fields ("extendedFields") are allowed.
• Policy: Usually requires the DRep’s key/script. May be mutable or immutable.

3.6.2 Ballot Note

• Minted By: The DRep (same key/script as Credential).
• Purpose: Publish a rationale for a CIP-1694 proposal.
• Keys in metadataMap (minimum):
  • "type": "ballotNote"
  • "dRepId": The CIP-1694 DRep ID.
  • "proposalId": The CIP-1694 (txHash, index) or an equivalent single string/bytes.
  • "voteChoice": e.g. "Yes", "No", "Abstain".
  • "rationale" (optional): short text or IPFS link.
  • "timestamp" (optional): e.g. ISO-8601 date/time.
• Policy: Usually immutable to preserve historical accuracy.

3.6.3 Endorsement

• Minted By: A third-party endorser.
• Purpose: Verifiable “social proof” of support for a dRep.
• Keys in metadataMap (minimum):
  • "type": "endorsement"
  • "endorses": The DRep ID.
  • "endorser": A map with "stakeKey" and optional "identityProof".
  • "comment" (optional): text or link.
• Policy: Owned by the endorser, who may burn or transfer it later.

---

3.7 CDDL Schemas (Conceptual)

Below is a conceptual CDDL schema (since CIP-68 uses CBOR). Each NFT type extends the same base pattern (#6.121([metadataMap, version, extra])).

cip148-datum = #6.121([
  metadata-map,
  version,
  extra
])

metadata-map = {
  * tstr => any
}

version = int
extra   = any   ; typically empty

; CIP-148 minimal for DRep Credential
drep-credential = {
  "dRepId" => bstr / tstr,
  ? "cip119AnchorUrl" => tstr,
  ? "cip119AnchorHash" => bstr,
  ? "extendedFields" => {
    * tstr => any
  }
}

; CIP-148 minimal for Ballot Note
ballot-note = {
  "type" => "ballotNote",
  "dRepId" => bstr / tstr,
  "proposalId" => bstr / tstr,
  "voteChoice" => tstr,
  ? "rationale" => tstr,
  ? "timestamp" => tstr
}

; CIP-148 minimal for Endorsement
endorsement = {
  "type" => "endorsement",
  "endorses" => bstr / tstr,
  "endorser" => {
    "stakeKey" => tstr,
    ? "identityProof" => tstr
  },
  ? "comment" => tstr
}

---

3.8 Usage & Implementation Notes

1. On-Chain vs. Off-Chain

   • Keep large data off-chain, referencing CIP-108 (if it’s proposal-related) or CIP-119 (if it’s DRep-related).
   • Only store essential identifiers and small references on-chain.

2. Proposal ID

   • CIP-148 recommends storing (txHash + index) as "proposalId" exactly, matching CIP-1694’s “governance action ID.”
   • Tools linking Ballot Notes to proposals must parse or decode this consistently.

3. Minting Policies

   • DRep Credential & Ballot Note – A policy requiring the DRep’s signature ensures authenticity.
   • Endorsement – A policy controlled by the endorser. No need for the dRep’s approval.

4. Compliance with CIP-68

   • The NFT’s CBOR must have the #6.121 constructor.
   • The first field is the metadataMap, second is the version, third is the extra.
   • If updatability is desired, follow CIP-68’s recommended two-token model or define a custom validator.

5. Asset Name Labeling

   • Recommended label (148) or (1694) (or another) with the correct CIP-67 hex prefix.
   • E.g.: 000fa400646572657043726564656e7469616c... for (148)drepCredential....

6. Integration with Governance Tools

   • Explorers parse CIP-148 NFTs to show relationships:
     • Which DRep ID? -> Check DRep Credential.
     • Which proposals? -> Check Ballot Notes’ proposalId.
     • Which endorsements? -> Check “endorsement” datums referencing dRepId.
   • This forms a “governance graph,” bridging CIP-1694 voting with CIP-100 off-chain data.

---

3.9 Summary of Requirements

• DRep Credential NFT: Must store dRepId (blake2b-224 of the DRep’s credential) and optionally anchor CIP-119 data.
• Ballot Note NFT: Must store dRepId + proposalId that match CIP-1694’s definitions, plus a “voteChoice.”
• Endorsement NFT: Must store endorses referencing a valid dRepId, minted by a different party.
• Datum Compliance: Each NFT’s datum uses CIP-68’s #6.121 pattern with version ≥ 1.
• Asset Label: Must follow CIP-67 for the name prefix, ensuring discoverability by wallets and explorers.
• Off-Chain Metadata: Use CIP-108 for proposals, CIP-119 for DRep data, referencing CIP-100’s anchor structure. Avoid storing large data on-chain.

By adhering to these rules, CIP-148 NFTs will be fully compatible with the Voltaire governance ecosystem, letting dReps, endorsers, and platforms leverage a consistent standard for on-chain representation, off-chain anchors, and synergy with CIP-1694 actions.

---

4. Rationale: How Does This CIP Achieve Its Goals?

CIP-148 aims to enrich Cardano’s on-chain governance data without imposing excessive overhead or altering existing rules. By building directly on top of CIP-1694 (governance framework) and CIP-119 (DRep metadata), CIP-148 leverages their established concepts—like DRep IDs and off-chain anchors—rather than inventing new identifiers or forcing large data onto the ledger. This approach ensures backward compatibility: DReps who only follow CIP-1694 and CIP-119 still remain valid, while those who adopt CIP-148 can offer additional transparency and self-reporting features.

The choice to use CIP-68 stems from its datum-based NFT design, which provides updatability for DReps who wish to refine their credentials and add endorsements over time. CIP-68 also makes metadata Plutus-inspectable, enabling advanced dApps to verify DRep data or endorsements on-chain. Alternative approaches—like embedding all metadata in transaction JSON—were considered but would lack the flexibility and standardization that CIP-68 enforces, potentially causing “metadata spoofing” or bloat.

To keep Cardano’s ledger lean, CIP-148 emphasizes off-chain anchors for large documents. This aligns with CIP-100’s principle of storing only a URL and content hash on-chain, significantly reducing resource consumption. Each NFT’s minimal on-chain fields (e.g., dRepId, proposalId, or endorses) make it straightforward to parse, while references to CIP-108 or CIP-119 let developers fetch richer details from IPFS or other decentralized storage.

Community discussions highlighted the risk of spam endorsements and the challenges of verifying self-reported achievements. CIP-148 addresses these by making endorsements a third-party action (more trust-minimized) and allowing tools to measure endorsement reputation or detect spam patterns. Because CIP-148 does not replace CIP-1694’s core logic, it remains entirely optional—but for those seeking deeper analytics or accountability, these extended NFTs provide a powerful, interoperable foundation.

---

5. Path to Active

Acceptance Criteria

1. Reference Implementations

   • At least two independent teams produce open-source reference implementations (in Plutus or a high-level library like Lucid).
   • Each reference implementation must demonstrate:
     • Minting a DRep Credential NFT (CIP-68 datum with dRepId).
     • Minting a Ballot Note NFT referencing a CIP-1694 proposalId.
     • Minting an Endorsement NFT referencing a dRepId.
     • Parsing the NFT’s datum fields (e.g., verifying the #6.121 constructor, reading dRepId, proposalId, etc.).
   • Any advanced features (e.g., updatable credentials) should also be demonstrated if the policy allows.

2. Wallet & Explorer Recognition

   • At least one wallet and one block explorer publicly confirm partial or full support for CIP-148 NFTs, specifically:
     • Recognizing CIP-67 labeling for asset names (e.g., (148)drepCredential-xxxx).
     • Displaying CIP-68 datum fields (e.g., “type=endorsement,” “dRepId=...”) in a user-friendly manner.
     • Handling off-chain metadata anchors (if present).

3. Governance Tool Integration

   • At least one governance-focused dashboard (or aggregator) incorporates CIP-148 data to show:
     • DRep Credential details (linked to CIP-119 metadata if present).
     • Ballot Notes with rationale for real or testnet proposals.
     • Endorsements that highlight community support.
   • The tool must validate CIP-1694 dRepId and proposalId references to ensure the data is properly correlated with real dReps and governance actions.

4. Community Consensus & No Unresolved Conflicts

   • A dedicated public review phase (e.g., forum or GitHub discussion) runs for a minimum of four weeks, gathering input from DReps, SPOs, wallet devs, and CIP editors.
   • All major objections or conflicts with CIP-1694, CIP-119, or CIP-68 must be resolved or deemed non-blocking.
   • A majority of participants must indicate that CIP-148 provides tangible benefits and does not introduce contradictory governance assumptions.

When the above conditions are met, the CIP-148 authors can request the CIP Editors to move this proposal from Proposed to Active status under CIP-0001 guidelines.

---

Implementation Plan

1. Phase 1: Reference Scripts & Documentation

   • Publish minimal Plutus scripts (or other minting logic) for each NFT type, including example datums in CIP-68 format.
   • Provide thorough documentation for:
     • CIP-67 labeling (how to form (148)drepCredential-xxxx asset names).
     • CIP-119/CIP-108 anchor usage for large off-chain data.
     • Validation logic (e.g., requiring the DRep’s stake key to sign Ballot Notes).

2. Phase 2: Testnet Deployments

   • Deploy the sample scripts on a Cardano testnet (Preview/Preprod).
   • Mint actual CIP-148 NFTs (DRep Credential, Ballot Note, Endorsement) referencing real CIP-1694 dRep IDs or mock proposals.
   • Demonstrate reading back the on-chain datum (e.g., verifying dRepId, proposalId matches CIP-1694 spec).

3. Phase 3: Wallet & Explorer Collaboration

   • Engage with at least one wallet team to display CIP-148 NFT metadata fields in their UI.
   • Collaborate with at least one explorer to index CIP-148 tokens by type ("ballotNote", "endorsement", etc.), so users can easily search or filter them.

4. Phase 4: Governance Dashboard Integration

   • Partner with a governance aggregator or dashboard developer to parse CIP-148 NFTs:
     • Show a DRep’s CIP-119 anchor data side-by-side with on-chain extended fields.
     • List Ballot Notes for relevant proposals, linking to CIP-108 off-chain metadata if present.
     • Visualize Endorsements in a reputation or “support graph.”

5. Phase 5: Community Review & Finalization

   • Publicly announce the CIP-148 testnet deployment results and invite feedback.
   • Conduct a four-week open discussion period to address any security or conceptual issues.
   • Resolve any remaining conflicts, ensure synergy with CIP-1694, CIP-119, CIP-68.
   • If consensus is achieved, request CIP Editors to transition CIP-148 from Proposed to Active.

By following this plan, CIP-148 implementers and community members can systematically prove the CIP’s viability in real-world settings. Achieving the Acceptance Criteria ensures that CIP-148 is interoperable, well-understood, and beneficial to Cardano’s governance ecosystem, justifying its transition to Active status.

6. Versioning

While this proposal includes a version field in each CIP-68 datum (initialized to 1), future changes MAY increment this field. Any tool parsing CIP-148 NFTs MUST handle unknown fields gracefully and continue to validate known fields as specified. If a breaking change to the datum structure is required, a new CIP or a major version increment of CIP-148 SHOULD be proposed. Existing NFTs with older versions remain valid; updated software SHOULD recognize and process these older versions for backward compatibility.

Special thanks to the numerous dReps, SPOs, wallet developers, and CIP editors who provided insights and feedback in open forums and workshops.

7. Copyright

This work is licensed under the terms of the CC-BY-4.0 license. You are free to share and adapt it for any purpose, provided that appropriate credit is given, and changes are clearly indicated. A copy of this license can be found at https://creativecommons.org/licenses/by/4.0/.