CIP-???? | On-Chain Surveys and Polls

[Thomas-nada]

This is a new Metadata CIP proposing a standard for on-chain surveys and community sentiment polling.

The goal is to provide a single, standardized, transparent, and reliable way for any entity (Foundations, DReps, projects, or community members) to conduct simple, structured consultations directly on-chain — without requiring deposits or governance actions.

This proposal defines two minimal CIP-0068 (label 674) metadata payloads:

• Survey Definition Payload: Specifies the survey question, available options, eligibility criteria, and vote aggregation method (StakeBased or CredentialBased). It may optionally reference a governance action by transaction ID and action index.
• Survey Response Payload: Enables any eligible stakeholder to submit their response, immutably linked to the originating survey transaction ID.

This standard provides a lightweight, interoperable foundation for ecosystem-wide sentiment gathering — allowing explorers, wallets, and dApps to discover, display, and aggregate survey results in a consistent, transparent way.

---

(rendered latest proposal version)

[Ryun1]

thanks for the proposal @Thomas-nada
I agree on the problem space
keen to see this one develop

[thenic95]

I understand that a governance body's vote transaction is linked to the underlying info governance action, but for the ADA holder, I don't see how the vote metadata is tied to the info action. Here, I would suggest following the same methodology as CIP-0094, which includes a hash of the entire question.

[thenic95]

Thanks for sharing this idea on how to improve the capability of the info governance action type.

One thing that immediately comes to mind is how the metadata file for the actual info governance action should be structured to avoid a situation where the questions in the governance action metadata contradict the question posed in the transaction metadata.

It seems wise to me to also establish a standard for the governance action metadata body, perhaps even leaving it blank or using a template that will always generate the same metadata anchor URL and metadata anchor hash, so tools can easily verify this as well.

[Thomas-nada]

Thats a valid question.

The way I envisioned it is the Info action acting as a vessel for the extended function.
The Info action itself contains no question, it only details the poll attached to it.
A specific mention that the votes being casted on the info action itself will not be taken into account could be a solution as we cannot "shut off" the ability to vote yes/no/abstain

[Thomas-nada]

Following the earlier discussion, this proposal has been refactored into a generic, standalone metadata standard for on-chain surveys.

• Surveys are now defined directly through CIP-0068 (label 674) metadata, without using a governance Info Action as a carrier.
• An optional referenceAction field (transactionId, actionIndex) allows a survey to link to a governance action when relevant.
• This approach removes deposits and lifetime limits while preserving contextual linkage to on-chain governance data.

Feedback on this direction is very welcome. 🙏

[rphair]

@Thomas-nada this is a whole new document! I'm encouraged to see the "new direction" seems to accommodate the feedback so far & provide a less disputable approach. Below are only more general corrections before the technical review begins again:

[rphair]

@Thomas-nada we weren't able to confirm this at the CIP meeting today because of some technical uncertainty: especially concern over metadata overpopulation & congestion in the 674 metadata label. Please continue to address that & other posted issues (@Ryun1 I think maybe #1107 (comment) has been resolved so please double-check and mark resolved if possible).

[Thomas-nada]

"especially concern over metadata overpopulation & congestion in the 674"

I have been thinking about this myself. I am leaning towards shifting to a unique tag to avoid conflict with other transactions. Should be an easy enough fix.

[rphair]

@Thomas-nada my apologies for missing the notification about 449e320 (in which the metadata tag question was cleared up) with all that has happened in the last week or two.

@Ryun1 @perturbing I can't be sure from my own technical level if moving all such activity to the new metadata tag in fact clears up the "metadata congestion" that we highlighted at the last meeting. If you can confirm that it would be, please post as such & we'll get this back onto the Review agenda to re-assess this as a CIP candidate.

[Thomas-nada]

@Thomas-nada my apologies for missing the notification about 449e320 (in which the metadata tag question was cleared up) with all that has happened in the last week or two.

@Ryun1 @perturbing I can't be sure from my own technical level if moving all such activity to the new metadata tag in fact clears up the "metadata congestion" that we highlighted at the last meeting. If you can confirm that it would be, please post as such & we'll get this back onto the Review agenda to re-assess this as a CIP candidate.

I’ve now updated the metadata label from “0017” to “17” as recommended.
In addition, I have opened [Pull Request #1119](#1119) to formally register label 17 in the CIP-10 registry, in line with the guidance provided.

[rphair]

@Thomas-nada yes indeed the "guidance" (#1107 (comment)) required a CIP-0010 update... but in this PR 😅 since this change will be considered atomically with the CIP itself (so we have to close #1119).

(for an idea of how this PR will look afterwards, you can check https://github.com/cardano-foundation/CIPs/pull/1113/files)