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

[Ryun1]

Might be worth considering how multiple surveys could be submitted at once.

Maybe reuse the governance action anchor? Rather than attaching transaction metadata too.

[Thomas-nada]

For multiple surveys at once I was thinking of something like this:

{
  "674": {
    "0": {
      "msg": [
        "Poll Title: [Insert Short, Human-Readable Title for Poll 0]"
      ],
      "pollDetails": {
        "specVersion": "1.0",
        "type": "[single-choice | multi-select]",
        "question": "[Insert the full, unambiguous poll question here]",
        "description": "[Insert detailed explanation, rationale, or context for the poll (supports markdown).]",
        "options": [
          "[Option 1 Text]",
          "[Option 2 Text]",
          "[Add more options as needed...]"
        ],
        "maxSelections": 1,
        "eligibility": [
          "[Stakeholder | DRep | SPO | CC (or leave empty for 'Stakeholder')]"
        ],
        "voteWeighting": "[StakeBased | CredentialBased]"
      }
    },
    "1": {
      "msg": [
        "Poll Title: [Insert Short, Human-Readable Title for Poll 1]"
      ],
      "pollDetails": {
        "specVersion": "1.0",
        "type": "[single-choice | multi-select]",
        "question": "[Insert the full, unambiguous poll question here]",
        "description": "[Insert detailed explanation, rationale, or context for the poll (supports markdown).]",
        "options": [
          "[Option A Text]",
          "[Option B Text]"
        ],
        "maxSelections": 3,
        "eligibility": [
          "DRep", 
          "SPO"
        ],
        "voteWeighting": "CredentialBased"
      }
    }
  }
}

But agreed, using the anchor is another option worth exploring.

[Ryun1]

Instead of transaction metadata, why not reuse the the anchor within the vote?

[Thomas-nada]

I anchored the poll definition data directly to the transaction metadata (using label 674 and the TxId as the anchor), instead of pushing the data off-chain to IPFS or similar external storage.

I went this route to keep everything purely on-chain and simple, but I know it limits the total size of the poll data.

Thoughts on this trade-off? Is the simplicity of the transaction metadata anchor worth the size limit, or should it use an external anchor?

[thenic95]

Including the metadata in the anchor of the vote txn would also not allow ADA holders to directly participate.

[Thomas-nada]

Including the metadata in the anchor of the vote txn would also not allow ADA holders to directly participate.

Ada holders absolutely can still participate. They can't cast a formal, binding CIP-1694 vote (that's DRep/CC/SPO only), but this CIP is for a community sentiment survey.

Ada holder sends a metadata-only transaction containing their response, which is purely a data collection transaction, not a governance certificate.

[thenic95]

I was actually agreeing with you @Thomas-nada 😄

My comment was directed at @Ryun1, who suggested only leveraging the anchor within the vote txns, this would then exclude the average ada holders, since they cannot submit a vote txn.

[Ryun1]

I feel that using Info action is nice, as you can reuse some of existing protocol governance tooling, but limits you with the governance action deposit and governance action lifetime.

The other option I have considered is a solely transaction metadata standard, similar to CIP-94.

WDYT?

[Thomas-nada]

I think sticking with the Info action approach would be best.
It limits spam, adds functionality to the already existing governance framework set out in CIP-1694 and the Constitution and should require minimum effort to implement for explorers and toolkits.

[Ryun1]

It limits spam,

there is other ways to do this, of course.

and not using Info actions, allows surveys to be ran for different lengths of time
and by people not having to have 100k ada

should require minimum effort to implement for explorers and toolkits.

if tools already need to implement and read a new metadata standard
these surveys being attached to Info actions doesn't make it any easier to implement

[Ryun1]

additionally, for non-stake-based surveys attached to Info actions,
tooling will have to show the stake-based for the Info action and then non-stake-based for the survey

this could be a bit of an annoying conflict to deal with for existing implementations

[Thomas-nada]

I guess I could expand the scope to go beyond just governance and make it more generic.
The initial idea was to add usecase to info actions, but making it more generic will allow for a broader reach and easier entry.

The downside of this is that it can easily become cluttered when something like a CC election becomes mixed up with someone using the same process to survey something for their next NFT drop.

[Thomas-nada]

@Ryun1 You've made some very strong points, and I have given it alot of thoughts. The 100k ada deposit, lifetime limits, and the UI conflict are all potential problems I initially have not given enough focus.

What if we pivot slightly?

Instead of using the Info Action as a carrier, we create a generic, standalone metadata standard for surveys like you mentioned. The key change would be adding an optional field to reference a governance action's transactionId and actionIndex.

This seems to solve a lot:

1. Flexibility: It's cheap, has no deposit, and no time limits.
2. Clean UI: It's clearly a "Survey," not seen as a conflicting governance action.
3. Solves Clutter: We can add a category field (e.g., governance) to categorize polls.
4. Keeps the Link: It still achieves my goal. For example, someone could post a Budge Info Action for a proposed budget, and a separate survey referencing it could immediately launch to gather detailed feedback which would be beneficial ahead of a treasury withdrawal. Tools could then easily find and display that poll alongside the Info Action. DReps votes on the info action as before, but are also able to provide more granular feedback in the survey.

This gives us the broad reach of a generic standard while still allowing us to add context to on-chain governance when needed.

What do you think of that approach?

[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: