-
Notifications
You must be signed in to change notification settings - Fork 371
CIP-???? | On-Chain Surveys and Polls #1107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
6a29713
52293a7
8cfc59d
9fe1c4c
317318f
a779f07
d56af24
3927fba
743e4d2
85f0c0b
04ef1cc
e07b0a9
339e1e6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,207 @@ | ||
| --- | ||
| CIP: XXXX | ||
| Title: On-Chain Surveys and Polls | ||
| Category: Metadata | ||
| Status: Proposed | ||
| Authors: | ||
| - Thomas Lindseth <[email protected]> | ||
| Implementors: [] | ||
| Discussions: | ||
| - https://github.com/cardano-foundation/CIPs/pull/1107 | ||
| Created: 2025-10-28 | ||
| License: CC-BY-4.0 | ||
| --- | ||
|
|
||
| ## Abstract | ||
|
|
||
| This proposal defines a **generic, standardized metadata structure** for creating and responding to on-chain surveys and polls. It uses the **CIP-0068** metadata standard (via the **674** label) to allow any entity to publish a survey in a machine-readable format without requiring governance deposits or formal registration. | ||
|
|
||
| The specification provides a minimal, interoperable format for survey definition and response — enabling wallets, explorers, and dApps across the Cardano ecosystem to reliably create, display, and aggregate poll data. | ||
|
|
||
| Optionally, a survey may **reference a governance action** by transaction ID and action index, allowing it to be contextually linked to an on-chain proposal while remaining independent. | ||
|
|
||
| ## Motivation: why is this CIP necessary? | ||
|
|
||
| Formal Cardano governance actions are intentionally restrictive and structured, but this rigidity limits the ability to gather **informal or exploratory community sentiment**. Off-chain tools (e.g., Google Forms, Typeform) have been used for this purpose, but they fragment data and trust. | ||
|
|
||
| This CIP proposes a **unified, lightweight survey metadata format** that can be used by anyone to: | ||
| - Collect feedback. | ||
| - Gauge sentiment. | ||
| - Display aggregated results. | ||
|
|
||
| By allowing an **optional reference to a governance action**, this model supports both: | ||
| - **Standalone surveys** (e.g., community temperature checks). | ||
| - **Governance-linked surveys** (e.g., feedback on a specific proposal or Info Action). | ||
|
|
||
| This separation of concerns provides: | ||
| - **Clarity:** Surveys are not mistaken for governance actions. | ||
| - **Flexibility:** No deposits, time limits, or procedural constraints. | ||
| - **Discoverability:** Metadata is consistent, indexed, and linkable. | ||
|
|
||
| ## Specification | ||
|
|
||
| This specification uses **CIP-0068** label **674** and defines two payload types: | ||
| `surveyDetails` (definition) and `surveyResponse` (vote). | ||
|
|
||
| ### Survey Definition Payload | ||
|
|
||
| This metadata is included in any transaction that defines a survey. | ||
| It can be completely independent or optionally reference an existing governance action. | ||
|
|
||
| ```json | ||
| { | ||
| "674": { | ||
| "msg": ["<Short, human-readable title of the survey>"], | ||
| "surveyDetails": { | ||
| "specVersion": "1.0", | ||
| "type": "single-choice", | ||
| "question": "<The full question to be displayed to respondents>", | ||
| "description": "<A detailed explanation of the survey (supports markdown)>", | ||
| "options": [ | ||
| "<Option 1 text>", | ||
| "<Option 2 text>", | ||
| "<Option N text>" | ||
| ], | ||
| "maxSelections": 1, | ||
| "eligibility": [ | ||
| "Stakeholder" | ||
| ], | ||
| "voteWeighting": "StakeBased", | ||
| "referenceAction": { | ||
| "transactionId": "<optional governance action TxId>", | ||
| "actionIndex": 0 | ||
| } | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| | Key | Type | Required | Description | | ||
| | :--- | :--- | :--- | :--- | | ||
| | `specVersion` | String | Yes | Version of this survey specification. **MUST** be `"1.0"`. | | ||
| | `type` | String | Yes | `"single-choice"` or `"multi-select"`. | | ||
| | `question` | String | Yes | The main survey question. | | ||
| | `description` | String | Yes | A detailed description or rationale (supports markdown). | | ||
| | `options` | Array of Strings | Yes | Ordered list of possible responses (min 2). | | ||
| | `maxSelections` | Positive Integer | Yes | Max number of options selectable per respondent. | | ||
| | `eligibility` | Array of Strings | No | Who can respond. Valid options: `"DRep"`, `"SPO"`, `"CC"`, `"Stakeholder"`. | | ||
| | `voteWeighting` | String | No | `"StakeBased"` (default) or `"CredentialBased"`. | | ||
| | `referenceAction` | Object | No | Optional link to a governance action. Contains `transactionId` (hex string) and `actionIndex` (integer). | | ||
|
|
||
| ### Survey Response Payload | ||
|
|
||
| This metadata is included in the transaction a user submits to cast a response. | ||
|
|
||
| ```json | ||
| { | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Instead of transaction metadata, why not reuse the the anchor within the vote?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Including the metadata in the anchor of the vote txn would also not allow ADA holders to directly participate.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
| "674": { | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
| "msg": ["Response to survey: <Title of the survey>"], | ||
| "surveyResponse": { | ||
| "surveyTxId": "<Transaction ID of the survey definition>", | ||
| "selection": [ | ||
| "<User's selected option text>" | ||
| ] | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| | Key | Type | Required | Description | | ||
| | :--- | :--- | :--- | :--- | | ||
| | `surveyTxId` | String (hex) | Yes | The transaction ID of the survey definition. | | ||
| | `selection` | Array of Strings | Yes | List of selected option(s); must match survey definition. | | ||
|
|
||
| ### Casting a Response | ||
|
|
||
| - **Governance actors (DReps, SPOs, CCs):** | ||
| May include a survey response in the same transaction as a governance vote if referencing a related action. | ||
| - **Stakeholders:** | ||
| Submit a self-transaction including the survey response metadata. | ||
|
|
||
| ### Block Explorer & dApp Implementation Guide | ||
|
|
||
| 1. **Survey Discovery:** | ||
| Scan for transactions with label **674** containing `surveyDetails`. | ||
| Each survey is uniquely identified by the transaction ID of that transaction. | ||
|
|
||
| 2. **Response Linking:** | ||
| Find transactions containing `surveyResponse` and link via `surveyTxId`. | ||
|
|
||
| 3. **Governance Context (Optional):** | ||
| If `referenceAction` exists, display the survey as related to that governance action. | ||
|
|
||
| 4. **Voter Eligibility Verification:** | ||
| If `eligibility` is defined, validate that the respondent’s address matches the specified category. | ||
|
|
||
| 5. **Aggregation:** | ||
| - `"StakeBased"` → sum responses weighted by ADA stake. | ||
| - `"CredentialBased"` → one vote per valid credential. | ||
|
|
||
| 6. **Display:** | ||
| Present the survey’s question, description, options, and weighted results. | ||
|
|
||
| ### CDDL Schema | ||
|
|
||
| ```cddl | ||
| ; CIP-00XX On-chain Surveys (Version 1.0) | ||
|
|
||
| surveyDetails = { | ||
| specVersion: "1.0", | ||
| type: "single-choice" / "multi-select", | ||
| question: tstr, | ||
| description: tstr, | ||
| options: [+ tstr], | ||
| maxSelections: uint, | ||
| ? eligibility: [* "DRep" / "SPO" / "CC" / "Stakeholder" ], | ||
| ? voteWeighting: "StakeBased" / "CredentialBased", | ||
| ? referenceAction: { | ||
| transactionId: tstr, ; hex-encoded TxId of related governance action | ||
| actionIndex: uint | ||
| } | ||
| } | ||
|
|
||
| surveyResponse = { | ||
| surveyTxId: tstr, ; hex-encoded TxId of survey definition | ||
| selection: [+ tstr] | ||
| } | ||
|
|
||
| cip_00XX_root = { | ||
| "surveyDetails" => surveyDetails, | ||
| ? "msg" => [ + tstr ] | ||
| } / { | ||
| "surveyResponse" => surveyResponse, | ||
| ? "msg" => [ + tstr ] | ||
| } | ||
| ``` | ||
|
|
||
| ## Rationale: how does this CIP achieve its goals? | ||
|
|
||
| - **General-purpose:** | ||
| Works for any form of sentiment collection — governance-related or otherwise. | ||
| - **Lightweight & cheap:** | ||
| Pure metadata, no deposits or complex data structures. | ||
| - **Discoverable & linkable:** | ||
| Optional `referenceAction` preserves relational context. | ||
| - **Extensible:** | ||
| Future versions can add optional fields (e.g., categorization or free-text support) without breaking compatibility. | ||
|
|
||
| ### Design Evolution | ||
|
|
||
| Early drafts of this proposal used governance *Info Actions* as the carrier for survey metadata. Through review discussions, this approach was replaced with a **standalone metadata model** to remove deposit and lifetime requirements, simplify tooling integration, and broaden applicability beyond governance-specific use cases. The optional `referenceAction` field was introduced to maintain the ability to link surveys contextually to governance actions when relevant. | ||
|
|
||
| ## Path to Active | ||
|
|
||
| ### Acceptance Criteria | ||
|
|
||
| - At least one survey is published using this structure and correctly parsed by an explorer or wallet. | ||
| - At least one explorer implements proper discovery, linking, and aggregation logic. | ||
|
|
||
| ### Implementation Plan | ||
|
|
||
| - Gather feedback via CIP repository and governance forums. | ||
| - Build a reference implementation and indexer. | ||
| - Encourage integration into major wallets and governance dashboards. | ||
|
|
||
| ## Copyright | ||
|
|
||
| This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). | ||
Uh oh!
There was an error while loading. Please reload this page.