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.

[rphair]

Suggested change

	All survey-related metadata is encoded under label 0017, chosen as a reference to the Roman census of 17 BC — one of the earliest organized systems for structured population data collection.
	All survey-related metadata is encoded under label `17`, chosen as a reference to the Roman census of 17 BC — one of the earliest organized systems for structured population data collection.

As far as I know, the usage & documentation for these labels isn't zero-padded (and in fact would be padded to the maximum size of 5 digits even if it were) and might cause some inconsistencies in text search unless the (quoted) plain number were used.

[rphair]

Suggested change

	This specification uses metadata label 0017 and defines two payload types:
	`surveyDetails` (definition) and `surveyResponse` (vote).
	This specification uses metadata label `17` and defines two payload types:
	`surveyDetails` (definition) and `surveyResponse` (vote).

1. This is what I was thinking of in the question above about whether there could still be "congestion" in the metadata... would not surveys & responses have different structure, different audiences, different frequency of distribution, etc? (I'm not claiming they are: but it's a review question to consider)
2. In any case, this PR (like others which have added metadata labels in the past) should also included an update to CIP-0010 to add the label itself... but please feel free to settle the question that this would be the only new label before making that change.

cc @Ryun1 @perturbing