CIP-???? | Extended DRep Credentials & Governance NFTs #1007
Conversation
rphair
changed the title
There was a problem hiding this comment.
Mostly editorial and grammatical changes to the structure of the document to bring it inline with the CIP-0001 and CIP-Template standards. Other suggestion is to not be so self-referential by explicit CIP number as a number is only officially assigned once the proposed CIP has passed through the CIP Editors body. So, while CIP-152 may end up becoming the ultimate number for this proposal, it could also be something else. I highly suggest waiting until a number has officially been assigned during a biweekly CIP editors meeting.
From a personal perspective, this CIP seem very thorough and well thought out. There are a couple of points of question for me still not least of which being how much actual adoption will this standard enjoy once it is ready for mainnet but it is certainly an effort worthy of attempting IMO.
|
Thanks @Crypto2099 for hitting every instance of the common points & some matters for individual discussion that I've also commented on... looking forward to continuing review after most of these suggestions are committed. @Alpine-Oracle we first are relying on you to confirm these commits individually:
Two more additional points:
|
|
Thank you for the detailed feedback. I’ll handle the placeholder references, folder rename, and heading adjustments and other changes suggested. I won’t force-push or rename the branch to preserve our review history. Thanks again for your help—I appreciate your guidance in refining this CIP! |
- Remove explicit references to “CIP-152” throughout the document - Replace them with “CIP: ???” or “this CIP,” per reviewer feedback Co-authored-by: Adam Dean <[email protected]>
- Replace occurrences of “dRep” with “DRep” throughout the document - Align with the official CIP-1694 convention Co-authored-by: Adam Dean <[email protected]>
- Remove extraneous '---' lines to match CIP-0001 style - Remove TOC numbers from headers - Address minor Markdown tweaks Co-authored-by: Adam Dean <[email protected]> Co-authored-by: Robert Phair <[email protected]>
- Eliminate the top level table of contents - Align with CIP-0001’s structure and let automated CIP tooling parse the document more reliably Co-authored-by: Adam Dean <[email protected]>
- Renames the directory to remove the placeholder CIP number - Leaving CIP-0152 branch name to keep review and commit history
|
@Alpine-Oracle thanks for the updates for document standardisation & I'm tagging |
rphair
added
the
State: Triage
|
Thanks for all the help so far @rphair and @Crypto2099. I have some changes Ill be pushing in the next couple days to add a bit more clarity. Ill have it ready and pushed and following the current guidelines before the meeting. |
|
@Alpine-Oracle since the editors (most notably myself) have been slow in progress to add a it would help the admissibility of this PR if you would set the |
- Change category to Tokens from Governance. If a governance category is added later, this proposal should fit into it. Until then, Tokens is a good representation.
- update introduction with better insights - improve token descriptions - improve abstract summary
- improve core motivation description - improve token descriptions
- add more detail into spec intro
- add better references to already established CIPs. - remove redundant information about CIPs, directing readers to consult each CIPs original documentation.
- remove code references.
- add more clarity to what is on and off chain in this CIP.
- add placeholder labels
- add Recommended Optional Fields - add Minimal JSON Example - improve Section Structure
- Add Core Fields - Add Optional Fields - Add json Example - update Section Structure - remove old "NFT Types Explained" section
- Add Core Fields - Add Optional Fields - Add json Example - Update Section Structure
- Replace "Practical Implementation Notes" with Implementation Guidelines - add better guidelines for Datum Format, Asset Naming & Labels, Reference Integrity, Spam & Authorization and Extensibility
- remove old rationale - add updated Rationale, with Key Motivations and Key Design Decisions
- add more robust Acceptance Criteria - add more clear Step by Step Implementation plan - add link to current prototype
- add clear information to add CIP version to datum - add clear path for updatability
| 4. **Spam & Authorization** | ||
|
|
||
| - Anyone can mint these tokens; spam or fake endorsements may occur. | ||
| - Governance UIs might validate minter signatures (e.g., does a Ballot Note come from the real DRep stake key?). |
There was a problem hiding this comment.
how can this system know which stake key is controlled by a DRep?
via the Ledger DReps are identified by DRep credentials, it would be preferable to use these
There was a problem hiding this comment.
This is more technical and I am not exactly sure how to answer it but I believe the current system also looks at their wallet adress and says the stake key has to match the wallet adress. This may change with ADA handle stuff though. It may read the ada handle and realize the key is within a group of keys (subhandles) or attached to that handle.
There was a problem hiding this comment.
It may read the ada handle and realize the key is within a group of keys (subhandles) or attached to that handle.
If this is so, then it should be clarified in the proposal
|
|
||
| 2. **Reducing Trust Friction** | ||
|
|
||
| - Delegators frequently rely on fragmented off-chain sources (social media, personal websites). |
There was a problem hiding this comment.
by adding data onchain in NFTs, are we not adding to the fragmentation?
There was a problem hiding this comment.
I think it is consolidating the information into a place where everyone can find how this information is connected. Hence the ecosystem mapping. It's just a big database in that regard for whoever wants to add their data.
There was a problem hiding this comment.
I disagree, this proposal is adding another place where tools will have to index to find all DRep information
| - Delegators frequently rely on fragmented off-chain sources (social media, personal websites). | ||
| - Minting an **official** CIP-68 NFT from a DRep’s stake key reduces confusion about who is _really_ behind a given profile or voting stance. | ||
|
|
||
| 3. **Minimizing Ledger Overhead** |
There was a problem hiding this comment.
would it not be less overhead to use the existing metadata solution which is built into the ledger design?
why is this approach better?
There was a problem hiding this comment.
Yeah I kinda disagree with this one and agree with you @Ryun1. I don't think it makes it more clear who is voting. The purpose is just so we can collectivize. I would say if the DRep collective gets too big and has too much influence and people are only paying attention to how the collective voted overall, then it actually makes things more confusing. Though do note, the collective can only prompt members to vote a certain way if it means preventing a grevious threat or security breach to the blockchain. Other than that, the collective is just trying to essentially unionize.
|
|
||
| 2. **Modular Anchoring** | ||
|
|
||
| - Leveraging **CIP-119** (DRep Profiles) and **CIP-108** (Proposal Metadata) keeps large data off-chain but verifiable. |
There was a problem hiding this comment.
| - Leveraging **CIP-119** (DRep Profiles) and **CIP-108** (Proposal Metadata) keeps large data off-chain but verifiable. | |
| - Leveraging **CIP-119** (DRep Profiles) and **CIP-108** (Governance Action Metadata) keeps large data off-chain but verifiable. |
| By adopting these definitions and guidelines, builders and governance participants can publish data-rich yet concise NFTs that are **compatible** with CIP-1694 governance flows, **verifiable** on-chain, and **extendable** through CIP-119/CIP-108 anchors. | ||
|
|
||
| ## Rationale: How Does This CIP Achieve Its Goals? | ||
|
|
There was a problem hiding this comment.
would be good to add to rationale; how the existing solutions cause problems and how each NFT solves the problems
|
|
||
| This CIP introduces structured **on-chain** metadata standards to enhance transparency, accountability, and effectiveness in Cardano’s governance. Building on **CIP-1694**, it provides new mechanisms for Delegated Representatives (DReps) and delegators to record, discover, and analyze governance data in a standardized way. Leveraging the **CIP-68** datum-based NFT model, it defines three specialized token types: | ||
|
|
||
| 1. **DRep Credential** – An on-chain credential NFT referencing both on- and off-chain metadata (per **CIP-119**), with optional fields (e.g., roles, sectors) for DReps to self-report. |
There was a problem hiding this comment.
might be worth considering this standard for all governance voters, so also SPOs and CC
|
|
||
| 3. **Reference Integrity** | ||
|
|
||
| - Check that `dRepId` and `proposalId` are valid CIP-1694 hashes/IDs. |
There was a problem hiding this comment.
what should tools do IF some of this is not valid?
There was a problem hiding this comment.
Tools can keep operating as it has in the past. This is internal to the collective.
There was a problem hiding this comment.
This is internal to the collective.
okay cool, I would suggest maybe it does not need to be a CIP if this is for internal tooling
| #### 4.2 Ballot Note | ||
|
|
||
| **Minted by:** A DRep publishing a stance on a proposal. | ||
| **Purpose:** |
There was a problem hiding this comment.
what happens if a DRep's Ballot Note doesn't match their vote?
It would be worth describing how tools should handle these situations
There was a problem hiding this comment.
DRep collective voting is internal so if it does not recognize their ballot note, then they lose any rights to rewards/payments distributed through the collective. They would have to update their ballot note to match their vote or explain why their vote changed from the vote within the collective. It would be cool if we could get an explanation as to why their vote changed. This is the kind of data we want to analyze when it comes to how people vote internally vs. externally. How people vote in the collective before the final vote is cast externally on gov.tools.
|
|
||
| - On-chain “vote of confidence,” optionally with a comment or identity proof. | ||
| - May include a **minimum ADA** amount to discourage spam. | ||
| - Optionally allows endorsers to attach **additional** ADA to assist new DReps (e.g., raising the 500 ADA deposit) or provide financial backing. |
There was a problem hiding this comment.
how can you endorse a DRep before theyre a DRep? how would the user know their payment address?
There was a problem hiding this comment.
Maybe with the ADA handles thing. Still working this out.
|
|
||
| - Anyone can mint these tokens; spam or fake endorsements may occur. | ||
| - Governance UIs might validate minter signatures (e.g., does a Ballot Note come from the real DRep stake key?). | ||
| - Endorsements from unknown or low-stake addresses could be flagged by analytics tools. |
There was a problem hiding this comment.
its probably worth describing exactly how tools SHOULD validate these NFTs
| } | ||
| ``` | ||
|
|
||
| #### 4.3 Endorsement |
There was a problem hiding this comment.
Im not sure what the motivation for stake-based endorsement is?
would it not be easier for tools to follow chain and look at the vote delegations from stake accounts to DRep credentials?
There was a problem hiding this comment.
I do not know how to answer this one!
There was a problem hiding this comment.
to rephrase the question
all delegations to DReps are public via the chain, is there a need to track this via NFTs also?
|
Hey @Alpine-Oracle my main comments are around eager to see it develop |
|
|
||
| By adopting these definitions and guidelines, builders and governance participants can publish data-rich yet concise NFTs that are **compatible** with CIP-1694 governance flows, **verifiable** on-chain, and **extendable** through CIP-119/CIP-108 anchors. | ||
|
|
||
| ## Rationale: How Does This CIP Achieve Its Goals? |
There was a problem hiding this comment.
why NFTs over transaction metadata?
|
Might also be worth considering a CIP-88 extension for this standard |
There was a problem hiding this comment.
Hi, thank you for this PR.
The goals as per the abstract of this CIP is,
transparency, accountability, and effectiveness in Cardano’s governance.
But I am missing how the current metadata standard for dreps/proposals and votes does not achieve this? I think that the problem is a bit under presented in this CIP, and the introduction of NFT's is made quickly (not saying this is a bad choice, just want to understand the design constraints).
|
|
||
| ### 4. Governance NFT Types | ||
|
|
||
| All governance NFTs proposed here share a **new CIP-67 label** (placeholder `(1694)`). Example asset names: |
There was a problem hiding this comment.
The CIP 67 prefix is 4 bytes, this leaves 28 bytes for the rest of the asset name. In Section 2 (Identifiers) above, you mention the size of the DRep ID and Proposal ID. These sizes exceed the max token name in this section.
There was a problem hiding this comment.
We are using a hashed form of the drep ID that resolves to drep payment address doesn't exceed the token name size.
|
|
||
| By integrating these elements, this CIP fosters a more transparent, data-driven governance environment—ultimately encouraging broader participation and deeper accountability across Cardano’s evolving governance ecosystem. | ||
|
|
||
| ## Specification |
There was a problem hiding this comment.
This CIP does not motivate why the usage of CIP 67/68. What is the benefit of using it oposed to other methods?
There was a problem hiding this comment.
Using an Nft provides an actual way to track engagement and to measure participation in governance events. It allows opportunities to sign from the drep wallet that holds the credential to transparently inform the community of attendance. It provides a way for Dreps to customize their credentials providing further expression, and it also opens up partnerships in the community that could use this CIP to create endorsement NFTS designated to the Drep.(we are in talks with AdaHandles to use sub-handles as endorsements.) Creating and using a PolicyID for the credential, also provides an easy way to track the involvement of dreps by the movement of the NFT/credential. It also prevents anyone from being able to pollute the metadata key used to record drep information. Rn, a person could update their public facing metadata AFTER the verification TX and go against everything they put on chain, and point to the updated version.
There was a problem hiding this comment.
Using an Nft provides an actual way to track engagement and to measure participation in governance events.
but these governance events/ participation in them are already on-chain and can be tracked, adding an NFT makes tracking this harder for all tools
There was a problem hiding this comment.
I don't think Gov.tools has to do much. I think this will all be done on our website. gov.tools can function as normal and we just have another website for all this data and info tracking on top of it. We ultimately want to function as a union/dao so we need a degree of separation.
There was a problem hiding this comment.
Yeah. This CIP should apply an extension to current standards. Using the NFTs we can reference current standards and bring the governance metadata to the wallet level without changing any infrastructure in current wallets and NFT readers like poolpm. I think if we want to bring awareness to Governance and increase participation, we should make sure its visible in wallet explorers.
There was a problem hiding this comment.
Without confirmation after the last CIP meeting https://hackmd.io/@cip-editors/109 (my apologies for being unable to attend) that this was given "candidate" status (i.e. a number) after triage, this is currently Unconfirmed and likely @Alpine-Oracle you need to respond to the review points above to encourage another discussion of candidacy at an upcoming meeting.
rphair
added
State: Unconfirmed
There was a problem hiding this comment.
@Alpine-Oracle we have a precedent of grouping similar CIPs with a common initial part of the title (like the Wallet extensions, both for CIP-0030 & candidate CIP-0144) and I just noticed we have a common element with this one from @Crypto2099 and @gitmachtl here:
The goal is not to have a bunch of divergent names since eventually we might want to have on-chain registrations for many things that might not exist sufficiently as metadata alone (which I think is the premise of this CIP... perhaps not defended completely in response to @Ryun1's enquires, but in any case still possibility).
@Ryun1 @Crypto2099 I'm relying on you to educate me if necessary about the community understanding of the word Registrations which has multiple meanings in this field as I see it. If it could cause confusion or ambiguity then perhaps that word should not be used.
There was a problem hiding this comment.
p.s. to #1007 (review) - for which GitHub over an Internet glitch ate some of the comment above & all the code changes:
Note the recommended title change is hypothetical & mainly to encourage agreement between editors, the current authors at the community about what constitutes a "Registration" and whether this term might be applied more broadly to other CIPs the same way it's being applied here.
- If it's changed from the discussion below it should also be titled into this PR itself.
|
@rphair thanks for your msg. yeah maybe we should change the title of CIP-0151 to something like: Similar to the title of CIP-0036 for catalyst So the Keyword Calidus can be found easily in the future by Devs and it also directly states that its a transaction metadata format. The Preable |
|
Thank you for all of the review and discussion here! Just finished a sprint on another project that was taking 110% of my time, but I've been keeping up here and really appreciate the discussion. I'm going through everything with the team and will start implementing some of these changes! And I will remove the quotes for real this time 😂 |
We’re Cardano, and if you’ll permit us, we would like to change the world. Co-authored-by: Robert Phair <[email protected]>
rphair
changed the title
There was a problem hiding this comment.
Feedback from review at CIP meeting today; I'll number these to hopefully help address them in future commentary:
1 - Editors have asked @Kronoshus to comment here in the PR with a high-level outline of exactly what the "DRep Collective" is, following up a verbal description presented with some characteristics of a political party or trade union.
2 - There are some nontechnical aspects of the "Collective" which appear to be ultimately facilitated by the methods in this CIP such as:
- arrangements for compensation out of budgeted funds
- coordination about political & legal issues: apparently both in blockchain voting & activities taken in the "real world" (please correct me if I'm wrong).
Therefore we might need to enumerate & discuss these "social governance" characteristics to confirm that they don't need to be part of the CIP itself.... considering that social governance propositions have been decided to be inadmissible as CIPs.
3 - There were some possible side effects also identified which would need to be robustly discussed here and then addressed in the CIP itself somewhere (generally done in the Rationale where the chosen approach is defended vs. other potential alternatives):
3a - The CIP as written might only serve one particular subset of DReps, so we would have to be sure DReps not participating in this (or any) "collective" wouldn't be marginalised by reduced influence compared to an officially funded special interest group... considering that @Kronoshus pointed out compensation would be available from a pool of IOG budgeted funds to be distributed to participating members.
3b - And so as Kevin also pointed out, there could be the potential of "buying votes" through such a mechanism — which is generally catastrophic for governance schemes — so that possibility will need to be addressed in the CIP after being robustly discussed here.
4 - I also mentioned in the meeting that many of these criticisms would be mitigated by rewriting the CIP a bit so that it did not try to encompass the entire "ecosystem" (as @Kronoshus mentioned @benohanlon had been seeking to do) but rather provide a technical organisation framework that any political faction could use.
5 - Considering all points above together: detaching the technical proposition from the foundation of a single "DRep Collective" might actually be essential to properly define it as a "standard" — as well as pre-empt worries that supporting only a single faction through such an officially recognised framework would effectively create a voting monopoly.
6 - More generally going forward, @Alpine-Oracle will have to catch up on responding to @Ryun1's feedback above and please try to stay ahead of it if this CIP is going to progress & evolve into something the community might accept.
Ryun1
added
the
State: Waiting for Author
rphair
removed
the
State: Unconfirmed
Summary
This proposal defines a structured on-chain metadata standard (CIP-0152) to enhance Cardano’s governance framework as outlined in CIP-1694. By introducing three specialized NFT types—DRep Credential, Ballot Note, and Endorsement—it enables verifiable credentials, voting rationales, and community endorsements to be recorded on-chain.
Key Points
Motivation
Delegators currently struggle to evaluate Delegated Representatives (dReps) due to limited, fragmented information. CIP-0152 addresses this gap by standardizing how dReps share qualifications, rationales, and endorsements, thereby fostering more informed delegation choices and broader community participation.
License
This CIP is licensed under CC-BY-4.0, enabling broad reuse and adaptation with proper attribution.
Link to Rendered Version