Ecosystem-Based DRep Metadata Extension

Important Note:
CIP-148 is currently a placeholder number used for discussion and internal prototyping. It does not represent an official Cardano Improvement Proposal (CIP) and may be merged with or re-numbered as part of an extension to CIP‑119 if consensus emerges.

This document is in a discovery phase. It presents extended metadata fields for Delegated Representatives (dReps) to improve ecosystem mapping and discoverability. The approach described here is based on a proof-of-concept written by Alpine.

Storage and NFT Innovation:

  • While this proposal does not mandate NFT storage, it is designed to leverage innovative NFT techniques (using CIP‑68 with the 721 standard) to overcome typical byte limits.
  • Extended metadata—for example, endorsements—can be issued and stored as separate NFTs and then referenced (or “locked”) into a dRep NFT smart contract. This enables the dRep NFT to appear fully updated without overloading the original data payload.
  • Although off-chain storage (e.g., via IPFS) remains an option, our structure supports on-chain aggregation of metadata by scanning the NFT smart contract address for all associated NFTs.

Community & Ecosystem Integration:
Extended fields are intended to work in harmony with CIP‑119’s minimal structure. Feedback is actively encouraged as we seek an ecosystem-wide solution that is both scalable and backward compatible.


Table of Contents


1. Abstract

CIP‑119 (DRep Registration Metadata) established a minimal structure for dRep self-description. However, CIP‑119 does not address ecosystem-centric data—such as a dRep’s affiliations, endorsements, and activity records—with sufficient granularity.

CIP‑148 proposes an ecosystem-based extension to CIP‑119, enabling dReps to:

  1. Self-report extended affiliations and endorsements.
  2. Provide detailed activity histories (e.g., governance proposals, Catalyst contributions).
  3. Enhance ecosystem mapping by allowing tools to filter and discover dReps based on additional attributes.

Note: This proposal is exploratory. It does not mandate a single storage method. Rather, it supports innovative NFT techniques (such as layering NFTs via CIP‑68 and 721 standard) that overcome typical byte limitations while still enabling off-chain storage when desired.


2. Motivation

  • Enhanced Discoverability:
    Additional metadata enables delegators and developers to identify dReps by specific roles, endorsements, and activity metrics.
  • Ecosystem Transparency:
    A standardized, extended metadata schema helps build interactive maps and aggregators that clarify the relationships and contributions within the governance ecosystem.
  • Scalable Innovation:
    By embracing NFT techniques (e.g., nesting endorsements as separate NFTs), the proposal bypasses traditional byte constraints without forcing a change to the core CIP‑119 structure.
  • Backward Compatibility & Flexibility:
    Extended fields complement CIP‑119. dReps can continue using the minimal core or gradually adopt additional fields as needed. Both on-chain and off-chain storage options remain viable.

3. Specification

3.1 Relationship to CIP‑119

  • Core vs. Extended Data:
    CIP‑119 defines a minimal set of fields (e.g., givenName, paymentAddress, objectives) for dRep metadata.
    CIP‑148 extends this schema by introducing additional fields for ecosystem roles, endorsements, and activity histories.
  • Interoperability:
    Tools can first parse CIP‑119 data and then look for the optional CIP‑148 extensions if present. This ensures backward compatibility and allows for incremental adoption.

3.2 New or Extended Fields

FieldTypeDescriptionRequiredExample
areasOfIntereststring[]Domains where a dRep is active (e.g., “DeFi,” “Voting Tools,” “Community Outreach”).Optional["DeFi", "Voting Tools", "Community Outreach"]
ecosystemRolesEcosystemRole[]Roles or positions held by the dRep in Cardano-related organizations or initiatives.Optionale.g., [{ "projectName": "Malama Ecosystem", "role": "Co-Founder", "since": "2025-01" }]
endorsementsEndorsement[]Recognitions or endorsements from established entities or community leaders.Optionale.g., [{ "organization": "IOG", "statement": "Recognized for CIP-1694 readiness" }]
activityMapActivity[]References to proposals, votes, or Catalyst records that document a dRep’s engagement within the ecosystem.Optionale.g., [{ "activityType": "Vote", "title": "Catalyst Fund 12", "date": "2025-07-01" }]

3.2.1 EcosystemRole

"ecosystemRoles": [ { "projectName": "Cardano Governance Working Group", "role": "Advisor", "description": "Guiding new governance tooling", "since": "2023-06", "until": null } ]

3.2.2 Endorsement

"endorsements": [ { "organization": "IOG", "statement": "Recognized for CIP-1694 readiness", "uri": "https://example.org/endorsement-proof" } ]

3.2.3 Activity

"activityMap": [ { "activityType": "GovernanceProposal", "title": "CIP-XYZ", "link": "https://github.com/cardano-foundation/CIPs/pull/xyz", "date": "2024-06-10" } ]

3.2.4 Areas of Interest

The areasOfInterest field is a key element for ecosystem mapping and discoverability. This field:

  • Identifies Domains:
    Specifies the sectors or technical domains (e.g., “DeFi,” “Voting Tools,” “Community Outreach”) in which a dRep is active.
  • Enables Filtering:
    Allows governance tools and aggregators to filter and group dReps based on their focus areas, improving the match between delegators and representatives.
  • Facilitates Ecosystem Mapping:
    Supports visual representations and interactive maps that showcase the diversity of expertise and roles within the governance ecosystem.

This field is intentionally designed as an optional array of strings, providing both flexibility and scalability. It can evolve over time as new domains emerge or as the community identifies additional areas worthy of tracking.


4. Example Usage

Below is an example demonstrating how the extended metadata might be embedded within a 721 format. Notice that the document still includes the core CIP‑119 fields and adds the optional CIP‑148 extensions. Innovative NFT techniques allow for the possibility of storing additional data (such as endorsements) as separate NFTs that are integrated via a smart contract.

{ "721": { "somePolicyId": { "myDRepNFT": { "@context": "https://schema.org", "@type": "EcosystemDRepMetadata", "body": { // CIP‑119 core fields "givenName": "Alpine", "paymentAddress": "addr1xyz...", "objectives": "Enhance governance transparency", "motivations": "Cardano's decentralized mission resonates with me", "qualifications": "5+ years in blockchain governance research", // CIP‑148 extended fields "areasOfInterest": ["DeFi", "Community Outreach"], "ecosystemRoles": [ { "projectName": "Malama Ecosystem", "role": "Co-Founder", "description": "Empowering grassroots initiatives", "since": "2025-01", }, ], "endorsements": [ { "organization": "IOG", "statement": "Recognized for CIP-1694 readiness", "uri": "https://example.org/endorsement", }, ], "activityMap": [ { "activityType": "Vote", "title": "Catalyst Fund 12", "date": "2025-07-01", }, ], }, }, }, }, }

Smart Contract Integration:

  • The design supports the concept of “NFTs within NFTs” using CIP‑68 and 721, meaning that extended data (such as endorsements) can be stored separately as NFTs and then referenced by the primary dRep NFT.
  • This method overcomes byte limitations and allows for dynamic updating: a smart contract can lock and aggregate the latest NFTs for a fully updated dRep profile.
  • Although off-chain storage (e.g., via IPFS) remains an option, this approach enables on-chain discovery by scanning the NFT smart contract address for associated NFTs.

5. On‑Chain vs. Off‑Chain Considerations

  • Storage Flexibility:
    This proposal does not mandate a single storage method. dReps can choose between on-chain solutions (using innovative NFT techniques) or off-chain storage (e.g., IPFS) referenced by CIP‑100 anchors.
  • Embracing NFT Innovation:
    With CIP‑68 and the 721 standard, extended metadata can be layered—endorsing data can be issued as separate NFTs that are integrated into a dRep’s main NFT profile without exceeding byte limits. This offers robust on-chain verification and aggregation capabilities.

6. Rationale

  • Machine-Readable Ecosystem Data:
    Structured arrays and objects allow developers to build interactive maps and dashboards that reflect the relationships and activities of dReps.
  • Backward Compatibility:
    By extending rather than replacing CIP‑119, the proposed metadata remains optional and fully backward compatible with existing tools.
  • Scalable and Innovative:
    Leveraging advanced NFT techniques (via CIP‑68/721) enables the addition of extended metadata without traditional storage constraints, supporting a dynamic and scalable governance ecosystem.
  • Community-Driven Evolution:
    Feedback is actively encouraged. This proposal is part of a broader discussion aimed at converging on an ecosystem-wide solution that meets the needs of dReps and governance platforms.

7. Future Considerations and Open Discussion

The extended fields presented in this proposal are not set in stone. They have been chosen as a starting point to improve ecosystem mapping and discoverability based on current needs and feedback. However, we recognize that:

  • Additional Fields:
    Other metadata points might further enrich dRep profiles. For instance, fields related to geographical location, social engagement, or specialized skill sets could be valuable.
  • Rationale Behind the Chosen Fields:
    The current selection focuses on:
    • Areas of Interest: Identifying sectors in which a dRep is active.
    • Ecosystem Roles: Documenting positions within projects or organizations.
    • Endorsements: Validating reputation through third-party recognition.
    • Activity Map: Tracking engagement and historical contributions.
  • Open Questions for Discussion:
    • Are there other fields or data points that could further enhance dRep profiles?
    • What are the trade-offs between on-chain NFT innovations and off-chain storage approaches?
    • How can additional fields be designed to remain scalable and interoperable with CIP‑119?

We invite the community to discuss these points, propose new ideas, and help refine this schema. Your feedback is crucial for determining the final structure of this metadata extension.


8. Path to Active

  1. Community Review:
    Engage developers, dRep collectives, and governance tool builders for feedback on the extended fields and the innovative storage methods.
  2. Reference Implementations:
    Develop prototypes and aggregators that leverage the extended metadata and NFT-based integration to demonstrate scalability and discoverability.
  3. Convergence with CIP‑119:
    Based on community consensus, the extended fields may be integrated as part of CIP‑119 or maintained as a compatible extension.

9. Frequently Asked Questions & Concerns

9.1 “Why not just extend CIP‑119?”

CIP‑119 was designed to be minimal. The extended fields proposed here enrich ecosystem data without disrupting the core functionality. If consensus emerges, these extensions may be merged into CIP‑119.

9.2 “Is this about NFTs?”

Not exclusively. Although NFTs (via 721 standard) are one storage option, the proposal is about defining an extended metadata schema. Our approach supports innovative NFT techniques—such as storing additional endorsements as separate NFTs integrated via smart contracts—while remaining agnostic about storage.

9.3 “Won’t this create conflicting solutions?”

The goal is to maintain backward compatibility. Extended fields are optional, and our approach is designed to be integrated with the broader CIP‑119 process, avoiding parallel, conflicting standards.

9.4 “How is data authenticity ensured?”

As with CIP‑119, data is self-reported. Verification via endorsements, digital signatures, or cryptographic proofs is encouraged to maintain trust and authenticity.


10. Security Considerations

  1. Data Authenticity:
    Extended metadata remains self-reported. Verification mechanisms (e.g., endorsements with cryptographic proofs) are recommended to ensure data integrity.
  2. Privacy:
    dReps control the extent of information disclosed. Sensitive data can be omitted or referenced indirectly.
  3. Storage Costs & Scalability:
    On-chain storage can be optimized through innovative NFT techniques, ensuring that byte limitations do not hinder extended metadata. Off-chain solutions (with CIP‑100 references) remain available as alternatives.

11. References


This document is part of an ongoing effort to enhance dRep metadata for the Cardano ecosystem. Feedback from the community and CIP Editors is actively sought to ensure that the extended metadata fields are practical, scalable, and ultimately serve the needs of dReps and the broader governance infrastructure.


© 2025 DRep Collective. All rights reserved.