From 6a29713a51280fd144edce456ec8cfc193b51746 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Tue, 28 Oct 2025 22:19:15 +0100
Subject: [PATCH 01/17] Create README.md

---
 CIP-????/README.md | 187 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 187 insertions(+)
 create mode 100644 CIP-????/README.md

diff --git a/CIP-????/README.md b/CIP-????/README.md
new file mode 100644
index 0000000000..b8aca60351
--- /dev/null
+++ b/CIP-????/README.md
@@ -0,0 +1,187 @@
+---
+CIP: XXXX
+Title: A Standard for On-chain Survey via Info Action
+Category: Metadata
+Status: Proposed
+Authors:
+    - Thomas Lindseth <thomas.lindseth@intersectmbo.org>
+Implementors: []
+Discussions: To-be-added
+Created: 2025-10-28
+License: CC-BY-4.0
+---
+
+## Abstract
+
+This proposal defines a standardized metadata structure for creating and responding to simple, generalized on-chain polls or surveys. It leverages the Conway-era **"Info Action"** and the existing **CIP-0068** metadata standard (using the **674** label) to allow any entity to publish a poll in a machine-readable format. It defines a minimal corresponding structure for voters to use when casting their votes, ensuring that poll data can be reliably created, displayed, and aggregated by any wallet, explorer, or dApp in the Cardano ecosystem. This standard focuses on a simple question, a set of options, and clear aggregation rules, providing a basic, yet powerful, tool for gauging community sentiment.
+
+---
+
+## Motivation: why is this CIP necessary?
+
+While the Cardano governance system is robust for formal decision-making, its tertiary voting mechanism (Yes/No/Abstain) is inherently limited for general community consultation and detailed opinion gathering. This standard allows entities—from foundations and development projects to individual community members—to submit a governance **Info Action** to anchor a structured, multi-option poll on-chain.
+
+It is invaluable for the entire Cardano ecosystem to have a **single, standardized method** for gauging sentiment. This proposal enables the creation of a decentralized, on-chain tool for consultation, ensuring that sentiment and relevant contextual data can be consistently linked to on-chain identity.
+
+By establishing a simple, common standard, we move away from fragmented, off-chain surveys and provide a transparent, reliable signal for the entire community without requiring complex, use-case-specific data structures.
+
+---
+
+## Specification
+
+This specification leverages the **674** message tag for community-defined structured metadata, as established in CIP-0068. It defines two distinct, minimal metadata payloads.
+
+### 1. Poll Definition Payload
+
+This metadata is included in the transaction that creates a governance "**Info Action**" to announce and define the poll. The **674** metadata entry **MUST** contain a `pollDetails` object.
+
+```json
+{
+  "674": {
+    "msg": ["<Short, human-readable title of the poll>"],
+    "pollDetails": {
+      "specVersion": "1.0", 
+      "type": "single-choice",
+      "question": "<The full question to be displayed to voters>",
+      "description": "<A detailed explanation of the poll (supports markdown)>",
+      "options": [
+        "<Option 1 text>",
+        "<Option 2 text>",
+        "<Option N text>"
+      ],
+      "maxSelections": 1,
+      "eligibility": [
+        "Stakeholder"
+      ],
+      "voteWeighting": "StakeBased"
+    }
+  }
+}
+````
+
+| Key | Type | Required | Description |
+| :--- | :--- | :--- | :--- |
+| `specVersion` | String | Yes | The version of this polling specification. **MUST** be "1.0". |
+| `type` | String | Yes | The type of poll. Supported types are `"single-choice"` and `"multi-select"`. |
+| `question` | String | Yes | The primary poll question. Should be concise. |
+| `description` | String | Yes | A longer description providing context or rationale. Supports **markdown** for rich text rendering in client applications. |
+| `options` | Array of Strings | Yes | An ordered list of the choices available. Min 2 options. The order **MUST** be the order displayed in the UI. |
+| `maxSelections` | Positive Integer | Yes | The maximum number of options a user can select. For a `single-choice` poll, this **MUST** be 1. |
+| `eligibility` | Array of Strings | No | Defines who is eligible to vote. Valid options: `"DRep"`, `"SPO"`, `"CC"`, `"Stakeholder"` (any address with a registered stake key). If omitted, the poll is open to all stakeholders. |
+| `voteWeighting` | String | No | Defines how votes are counted. Options: `"StakeBased"` or `"CredentialBased"`. If omitted, the default is `"StakeBased"`. |
+
+### 2\. Poll Response Payload
+
+This metadata is included in the transaction a voter submits to cast their vote. The **674** metadata entry **MUST** contain a `voteFor` object.
+
+```json
+{
+  "674": {
+    "msg": ["Response to poll: <Title of the poll>"],
+    "voteFor": {
+        "actionTxId": "<The transaction ID of the Info Action that defined the poll>",
+        "selection": [
+            "<User's choice (matching option name)>"
+        ]
+    }
+  }
+}
+```
+
+| Key | Type | Required | Description |
+| :--- | :--- | :--- | :--- |
+| `actionTxId` | String (hex) | Yes | The transaction hash of the "Info Action" that created the poll. This provides an immutable link. |
+| `selection` | Array of Strings | Yes | A list of the user's selected options. For `single-choice` polls, this array **MUST** contain exactly one element. Values **MUST** match entries in the `options` array from the `pollDetails`. |
+
+### 3\. Casting a Vote
+
+The method for submitting a poll response depends on the user's role:
+
+  * **For Governance Bodies (DReps, SPOs, CC Members):** The poll response metadata, as defined above, should be included in the same transaction used to cast their formal governance vote (Yes/No/Abstain) on the Info Action.
+
+  * **For Stakeholders:** A stakeholder not casting a formal governance vote **MUST** create a new transaction (e.g., sending a minimal amount of ADA back to their own address) with the sole purpose of including the Poll Response Payload in the transaction's metadata.
+
+### Block Explorer Implementation Guide
+
+Cardano block explorers and other data aggregators should follow these steps to discover, parse, and display poll results:
+
+1.  **Poll Discovery:** Scan transactions for metadata entries with the top-level key **674** containing a `pollDetails` object. The transaction ID of this action is the poll's unique identifier.
+
+2.  **Response Discovery & Linking:** Scan for metadata entries with **674** containing a `voteFor` object, linking them via the `actionTxId` field.
+
+3.  **Voter Eligibility Verification:** If the `eligibility` field is present, verify the credentials of the address that submitted the voting transaction.
+
+4.  **Aggregating Results:** Check the `voteWeighting` field.
+
+      * **If `voteWeighting` is "StakeBased" (or omitted):** For each valid vote, query the on-chain state to determine the voting power (in ADA) associated with the voter's credential at the time of the vote. This ADA value is added to the total for the selected option(s).
+
+      * **If `voteWeighting` is "CredentialBased":** For every valid vote, a weight of **1** (one credential/voter) is added to the total for the selected option(s).
+
+5.  **Displaying Results:** Display the poll's question, description, options, and the total vote count for each option (either in ADA or by credential count).
+
+### CDDL Schema
+
+To ensure unambiguous, machine-readable validation, proposals that define on-chain data structures **MUST** include a CDDL schema.
+
+```cddl
+; CIP-00XX On-chain Polls (Version 1.0)
+
+pollDetails = {
+  specVersion: "1.0",
+  type: "single-choice" / "multi-select",
+  question: tstr,
+  description: tstr,
+  options: [+ tstr],
+  maxSelections: uint,
+  ? eligibility: [* "DRep" / "SPO" / "CC" / "Stakeholder" ],
+  ? voteWeighting: "StakeBased" / "CredentialBased",
+}
+
+voteFor = {
+  actionTxId: tstr, ; hex-encoded transaction ID of the Info Action
+  selection: [+ tstr], ; List of user's selected options
+}
+
+; This structure is the content of the CIP-0068 `674` label
+cip_00XX_root = {
+    "pollDetails" => pollDetails,
+    ? "msg" => [ + tstr ],
+} / {
+    "voteFor" => voteFor,
+    ? "msg" => [ + tstr ],
+}
+```
+
+-----
+
+## Rationale: how does this CIP achieve its goals?
+
+  * **General Purpose:** By removing complex, nested data structures, the metadata payload remains small, cheap to submit, and applicable to any simple question or sentiment check.
+  * **Leveraging Existing Standards:** Using CIP-0068 and the Info Action minimizes the need for new on-chain logic, maximizing discoverability and adoption.
+  * **Flexible Vote Weighting:** The inclusion of both "StakeBased" and "CredentialBased" weighting makes the standard immediately useful for different contexts, from governance-adjacent questions to simple community temperature checks.
+
+-----
+
+## Path to Active
+
+### Acceptance Criteria
+
+This CIP will be considered Active when the following criteria are met:
+
+  * **Initial Adoption:** At least one poll has been successfully created (via an Info Action) and its details and results are correctly discovered, parsed, and displayed by at least one major Cardano block explorer.
+  * **Explorer Support:** At least one major Cardano block explorer has implemented support for discovering, displaying, and correctly aggregating poll results according to the defined `voteWeighting` rules.
+
+### Implementation Plan
+
+  * Gather Community Feedback on this draft via the CIPs repository pull request and Cardano forums.
+  * Develop a minimal reference implementation to demonstrate the creation and aggregation of poll data.
+  * Encourage Adoption among wallet, explorer, and dApp development teams.
+
+-----
+
+## Copyright
+
+This CIP is licensed under CC-BY-4.0.
+
+```
+```

From 52293a7bb923ca02c3963fbe8623b99d3fdb1639 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Tue, 28 Oct 2025 22:30:30 +0100
Subject: [PATCH 02/17] Update README.md

---
 CIP-????/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index b8aca60351..fd3875c083 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -6,7 +6,7 @@ Status: Proposed
 Authors:
     - Thomas Lindseth <thomas.lindseth@intersectmbo.org>
 Implementors: []
-Discussions: To-be-added
+Discussions: 'https://github.com/cardano-foundation/CIPs/pull/1107'
 Created: 2025-10-28
 License: CC-BY-4.0
 ---

From 8cfc59d6321f9c500a05b2046a80ea54358e5ac5 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Wed, 29 Oct 2025 08:33:00 +0100
Subject: [PATCH 03/17] Update CIP-????/README.md

Co-authored-by: Ryan <ryan.williams@intersectmbo.org>
---
 CIP-????/README.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index fd3875c083..0873b0d1aa 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -15,7 +15,6 @@ License: CC-BY-4.0
 
 This proposal defines a standardized metadata structure for creating and responding to simple, generalized on-chain polls or surveys. It leverages the Conway-era **"Info Action"** and the existing **CIP-0068** metadata standard (using the **674** label) to allow any entity to publish a poll in a machine-readable format. It defines a minimal corresponding structure for voters to use when casting their votes, ensuring that poll data can be reliably created, displayed, and aggregated by any wallet, explorer, or dApp in the Cardano ecosystem. This standard focuses on a simple question, a set of options, and clear aggregation rules, providing a basic, yet powerful, tool for gauging community sentiment.
 
----
 
 ## Motivation: why is this CIP necessary?
 

From 9fe1c4ca5e2739f26851412c48b0dddd9353f39f Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Wed, 29 Oct 2025 18:42:48 +0100
Subject: [PATCH 04/17] Update CIP-????/README.md

Co-authored-by: Ryan <ryan.williams@intersectmbo.org>
---
 CIP-????/README.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index 0873b0d1aa..ba5a3ed579 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -78,7 +78,6 @@ This metadata is included in the transaction a voter submits to cast their vote.
   "674": {
     "msg": ["Response to poll: <Title of the poll>"],
     "voteFor": {
-        "actionTxId": "<The transaction ID of the Info Action that defined the poll>",
         "selection": [
             "<User's choice (matching option name)>"
         ]

From 317318f68f3bc1a2ee9f7f635b4eb32845074579 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Thu, 30 Oct 2025 15:12:10 +0100
Subject: [PATCH 05/17] Update CIP-????/README.md

Co-authored-by: Ryan <ryan.williams@intersectmbo.org>
---
 CIP-????/README.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index ba5a3ed579..e0403f4ee5 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -24,7 +24,6 @@ It is invaluable for the entire Cardano ecosystem to have a **single, standardiz
 
 By establishing a simple, common standard, we move away from fragmented, off-chain surveys and provide a transparent, reliable signal for the entire community without requiring complex, use-case-specific data structures.
 
----
 
 ## Specification
 

From a779f0763e90dc4ee4205212fe2fee9b7da71092 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Wed, 5 Nov 2025 20:25:52 +0100
Subject: [PATCH 06/17] Reworked as standalone metadata standard

Key updates:

Reworked the structure to no longer depend on the governance Info Action, surveys can now exist independently.

Added an optional referenceAction field (transactionId, actionIndex) to link a survey to a governance action when relevant.

Updated rationale, examples, and CDDL schema to align with the new standalone approach.

This version aims to make the standard simpler, cheaper to use, and more flexible, while still allowing contextual linkage to governance actions when desired.
---
 CIP-????/README.md | 185 +++++++++++++++++++++++++--------------------
 1 file changed, 105 insertions(+), 80 deletions(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index e0403f4ee5..7e8d8a2bd7 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -1,6 +1,6 @@
 ---
 CIP: XXXX
-Title: A Standard for On-chain Survey via Info Action
+Title: A Standard for On-Chain Surveys and Polls
 Category: Metadata
 Status: Proposed
 Authors:
@@ -13,35 +13,49 @@ License: CC-BY-4.0
 
 ## Abstract
 
-This proposal defines a standardized metadata structure for creating and responding to simple, generalized on-chain polls or surveys. It leverages the Conway-era **"Info Action"** and the existing **CIP-0068** metadata standard (using the **674** label) to allow any entity to publish a poll in a machine-readable format. It defines a minimal corresponding structure for voters to use when casting their votes, ensuring that poll data can be reliably created, displayed, and aggregated by any wallet, explorer, or dApp in the Cardano ecosystem. This standard focuses on a simple question, a set of options, and clear aggregation rules, providing a basic, yet powerful, tool for gauging community sentiment.
+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?
 
-While the Cardano governance system is robust for formal decision-making, its tertiary voting mechanism (Yes/No/Abstain) is inherently limited for general community consultation and detailed opinion gathering. This standard allows entities—from foundations and development projects to individual community members—to submit a governance **Info Action** to anchor a structured, multi-option poll on-chain.
+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.  
 
-It is invaluable for the entire Cardano ecosystem to have a **single, standardized method** for gauging sentiment. This proposal enables the creation of a decentralized, on-chain tool for consultation, ensuring that sentiment and relevant contextual data can be consistently linked to on-chain identity.
+This CIP proposes a **unified, lightweight survey metadata format** that can be used by:
+- Projects and community groups to collect feedback.  
+- Delegated representatives (DReps) or governance actors to gauge sentiment.  
+- Explorers and dashboards to display aggregated results.  
 
-By establishing a simple, common standard, we move away from fragmented, off-chain surveys and provide a transparent, reliable signal for the entire community without requiring complex, use-case-specific data structures.
+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 leverages the **674** message tag for community-defined structured metadata, as established in CIP-0068. It defines two distinct, minimal metadata payloads.
+This specification uses **CIP-0068** label **674** and defines two payload types:  
+`surveyDetails` (definition) and `surveyResponse` (vote).
 
-### 1. Poll Definition Payload
+### 1. Survey Definition Payload
 
-This metadata is included in the transaction that creates a governance "**Info Action**" to announce and define the poll. The **674** metadata entry **MUST** contain a `pollDetails` object.
+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 poll>"],
-    "pollDetails": {
-      "specVersion": "1.0", 
+    "msg": ["<Short, human-readable title of the survey>"],
+    "surveyDetails": {
+      "specVersion": "1.0",
       "type": "single-choice",
-      "question": "<The full question to be displayed to voters>",
-      "description": "<A detailed explanation of the poll (supports markdown)>",
+      "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>",
@@ -51,35 +65,41 @@ This metadata is included in the transaction that creates a governance "**Info A
       "eligibility": [
         "Stakeholder"
       ],
-      "voteWeighting": "StakeBased"
+      "voteWeighting": "StakeBased",
+      "referenceAction": {
+        "transactionId": "<optional governance action TxId>",
+        "actionIndex": 0
+      }
     }
   }
 }
-````
+```
 
 | Key | Type | Required | Description |
 | :--- | :--- | :--- | :--- |
-| `specVersion` | String | Yes | The version of this polling specification. **MUST** be "1.0". |
-| `type` | String | Yes | The type of poll. Supported types are `"single-choice"` and `"multi-select"`. |
-| `question` | String | Yes | The primary poll question. Should be concise. |
-| `description` | String | Yes | A longer description providing context or rationale. Supports **markdown** for rich text rendering in client applications. |
-| `options` | Array of Strings | Yes | An ordered list of the choices available. Min 2 options. The order **MUST** be the order displayed in the UI. |
-| `maxSelections` | Positive Integer | Yes | The maximum number of options a user can select. For a `single-choice` poll, this **MUST** be 1. |
-| `eligibility` | Array of Strings | No | Defines who is eligible to vote. Valid options: `"DRep"`, `"SPO"`, `"CC"`, `"Stakeholder"` (any address with a registered stake key). If omitted, the poll is open to all stakeholders. |
-| `voteWeighting` | String | No | Defines how votes are counted. Options: `"StakeBased"` or `"CredentialBased"`. If omitted, the default is `"StakeBased"`. |
+| `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). |
 
-### 2\. Poll Response Payload
+### 2. Survey Response Payload
 
-This metadata is included in the transaction a voter submits to cast their vote. The **674** metadata entry **MUST** contain a `voteFor` object.
+This metadata is included in the transaction a user submits to cast a response.
 
 ```json
 {
   "674": {
-    "msg": ["Response to poll: <Title of the poll>"],
-    "voteFor": {
-        "selection": [
-            "<User's choice (matching option name)>"
-        ]
+    "msg": ["Response to survey: <Title of the survey>"],
+    "surveyResponse": {
+      "surveyTxId": "<Transaction ID of the survey definition>",
+      "selection": [
+        "<User's selected option text>"
+      ]
     }
   }
 }
@@ -87,43 +107,44 @@ This metadata is included in the transaction a voter submits to cast their vote.
 
 | Key | Type | Required | Description |
 | :--- | :--- | :--- | :--- |
-| `actionTxId` | String (hex) | Yes | The transaction hash of the "Info Action" that created the poll. This provides an immutable link. |
-| `selection` | Array of Strings | Yes | A list of the user's selected options. For `single-choice` polls, this array **MUST** contain exactly one element. Values **MUST** match entries in the `options` array from the `pollDetails`. |
-
-### 3\. Casting a Vote
-
-The method for submitting a poll response depends on the user's role:
+| `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. |
 
-  * **For Governance Bodies (DReps, SPOs, CC Members):** The poll response metadata, as defined above, should be included in the same transaction used to cast their formal governance vote (Yes/No/Abstain) on the Info Action.
+### 3. Casting a Response
 
-  * **For Stakeholders:** A stakeholder not casting a formal governance vote **MUST** create a new transaction (e.g., sending a minimal amount of ADA back to their own address) with the sole purpose of including the Poll Response Payload in the transaction's metadata.
+- **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 Implementation Guide
+### 4. Block Explorer & dApp Implementation Guide
 
-Cardano block explorers and other data aggregators should follow these steps to discover, parse, and display poll results:
+1. **Survey Discovery:**  
+   Scan for transactions with label **674** containing `surveyDetails`.  
+   Each survey is uniquely identified by the transaction ID of that transaction.
 
-1.  **Poll Discovery:** Scan transactions for metadata entries with the top-level key **674** containing a `pollDetails` object. The transaction ID of this action is the poll's unique identifier.
+2. **Response Linking:**  
+   Find transactions containing `surveyResponse` and link via `surveyTxId`.
 
-2.  **Response Discovery & Linking:** Scan for metadata entries with **674** containing a `voteFor` object, linking them via the `actionTxId` field.
+3. **Governance Context (Optional):**  
+   If `referenceAction` exists, display the survey as related to that governance action.
 
-3.  **Voter Eligibility Verification:** If the `eligibility` field is present, verify the credentials of the address that submitted the voting transaction.
+4. **Voter Eligibility Verification:**  
+   If `eligibility` is defined, validate that the respondent’s address matches the specified category.
 
-4.  **Aggregating Results:** Check the `voteWeighting` field.
+5. **Aggregation:**  
+   - `"StakeBased"` → sum responses weighted by ADA stake.  
+   - `"CredentialBased"` → one vote per valid credential.
 
-      * **If `voteWeighting` is "StakeBased" (or omitted):** For each valid vote, query the on-chain state to determine the voting power (in ADA) associated with the voter's credential at the time of the vote. This ADA value is added to the total for the selected option(s).
+6. **Display:**  
+   Present the survey’s question, description, options, and weighted results.
 
-      * **If `voteWeighting` is "CredentialBased":** For every valid vote, a weight of **1** (one credential/voter) is added to the total for the selected option(s).
-
-5.  **Displaying Results:** Display the poll's question, description, options, and the total vote count for each option (either in ADA or by credential count).
-
-### CDDL Schema
-
-To ensure unambiguous, machine-readable validation, proposals that define on-chain data structures **MUST** include a CDDL schema.
+### 5. CDDL Schema
 
 ```cddl
-; CIP-00XX On-chain Polls (Version 1.0)
+; CIP-00XX On-chain Surveys (Version 1.0)
 
-pollDetails = {
+surveyDetails = {
   specVersion: "1.0",
   type: "single-choice" / "multi-select",
   question: tstr,
@@ -132,53 +153,57 @@ pollDetails = {
   maxSelections: uint,
   ? eligibility: [* "DRep" / "SPO" / "CC" / "Stakeholder" ],
   ? voteWeighting: "StakeBased" / "CredentialBased",
+  ? referenceAction: {
+      transactionId: tstr,  ; hex-encoded TxId of related governance action
+      actionIndex: uint
+  }
 }
 
-voteFor = {
-  actionTxId: tstr, ; hex-encoded transaction ID of the Info Action
-  selection: [+ tstr], ; List of user's selected options
+surveyResponse = {
+  surveyTxId: tstr,  ; hex-encoded TxId of survey definition
+  selection: [+ tstr]
 }
 
-; This structure is the content of the CIP-0068 `674` label
 cip_00XX_root = {
-    "pollDetails" => pollDetails,
-    ? "msg" => [ + tstr ],
+    "surveyDetails" => surveyDetails,
+    ? "msg" => [ + tstr ]
 } / {
-    "voteFor" => voteFor,
-    ? "msg" => [ + tstr ],
+    "surveyResponse" => surveyResponse,
+    ? "msg" => [ + tstr ]
 }
 ```
 
------
-
 ## Rationale: how does this CIP achieve its goals?
 
-  * **General Purpose:** By removing complex, nested data structures, the metadata payload remains small, cheap to submit, and applicable to any simple question or sentiment check.
-  * **Leveraging Existing Standards:** Using CIP-0068 and the Info Action minimizes the need for new on-chain logic, maximizing discoverability and adoption.
-  * **Flexible Vote Weighting:** The inclusion of both "StakeBased" and "CredentialBased" weighting makes the standard immediately useful for different contexts, from governance-adjacent questions to simple community temperature checks.
-
------
+- **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.
 
 ## Path to Active
 
 ### Acceptance Criteria
 
-This CIP will be considered Active when the following criteria are met:
-
-  * **Initial Adoption:** At least one poll has been successfully created (via an Info Action) and its details and results are correctly discovered, parsed, and displayed by at least one major Cardano block explorer.
-  * **Explorer Support:** At least one major Cardano block explorer has implemented support for discovering, displaying, and correctly aggregating poll results according to the defined `voteWeighting` rules.
+- 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 Community Feedback on this draft via the CIPs repository pull request and Cardano forums.
-  * Develop a minimal reference implementation to demonstrate the creation and aggregation of poll data.
-  * Encourage Adoption among wallet, explorer, and dApp development teams.
-
------
+- 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.
 
-```
-```
+## Revision History
+
+| Version | Date | Description |
+|----------|------|-------------|
+| 1.0 | 2025-10-28 | Initial version using Info Actions |
+| 1.1 | 2025-11-05 | Reworked as standalone metadata standard |

From d56af247b2a2e8e63b80f9492079c2c2ad67b559 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Thu, 6 Nov 2025 02:09:41 +0100
Subject: [PATCH 07/17] minor wording tweaks

---
 CIP-????/README.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index 7e8d8a2bd7..65ae0a45ad 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -23,10 +23,10 @@ Optionally, a survey may **reference a governance action** by transaction ID and
 
 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:
-- Projects and community groups to collect feedback.  
-- Delegated representatives (DReps) or governance actors to gauge sentiment.  
-- Explorers and dashboards to display aggregated results.  
+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).  

From 3927fba83f3cc98d710cdb2fbdc0779ce97cc74a Mon Sep 17 00:00:00 2001
From: Robert Phair <rphair@cosd.com>
Date: Thu, 6 Nov 2025 12:22:50 +0545
Subject: [PATCH 08/17] fix `Discussion:` syntax

---
 CIP-????/README.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index 65ae0a45ad..270cffef37 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -6,7 +6,8 @@ Status: Proposed
 Authors:
     - Thomas Lindseth <thomas.lindseth@intersectmbo.org>
 Implementors: []
-Discussions: 'https://github.com/cardano-foundation/CIPs/pull/1107'
+Discussions:
+    - https://github.com/cardano-foundation/CIPs/pull/1107
 Created: 2025-10-28
 License: CC-BY-4.0
 ---

From 743e4d2012b0f3205331535cbc82288fe47cb449 Mon Sep 17 00:00:00 2001
From: Robert Phair <rphair@cosd.com>
Date: Thu, 6 Nov 2025 12:23:17 +0545
Subject: [PATCH 09/17] add license link

---
 CIP-????/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index 270cffef37..24d1af96b1 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -200,7 +200,7 @@ cip_00XX_root = {
 
 ## Copyright
 
-This CIP is licensed under CC-BY-4.0.
+This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).
 
 ## Revision History
 

From 85f0c0bf579be3c6c68deaed2634779ddbb487b2 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Thu, 6 Nov 2025 11:16:38 +0100
Subject: [PATCH 10/17] Update README.md

---
 CIP-????/README.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index 24d1af96b1..517d6a05cc 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -43,7 +43,7 @@ This separation of concerns provides:
 This specification uses **CIP-0068** label **674** and defines two payload types:  
 `surveyDetails` (definition) and `surveyResponse` (vote).
 
-### 1. Survey Definition Payload
+### 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.
@@ -88,7 +88,7 @@ It can be completely independent or optionally reference an existing governance
 | `voteWeighting` | String | No | `"StakeBased"` (default) or `"CredentialBased"`. |
 | `referenceAction` | Object | No | Optional link to a governance action. Contains `transactionId` (hex string) and `actionIndex` (integer). |
 
-### 2. Survey Response Payload
+### Survey Response Payload
 
 This metadata is included in the transaction a user submits to cast a response.
 
@@ -111,14 +111,14 @@ This metadata is included in the transaction a user submits to cast a response.
 | `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. |
 
-### 3. Casting a Response
+### 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.
 
-### 4. Block Explorer & dApp Implementation Guide
+### Block Explorer & dApp Implementation Guide
 
 1. **Survey Discovery:**  
    Scan for transactions with label **674** containing `surveyDetails`.  
@@ -140,7 +140,7 @@ This metadata is included in the transaction a user submits to cast a response.
 6. **Display:**  
    Present the survey’s question, description, options, and weighted results.
 
-### 5. CDDL Schema
+### CDDL Schema
 
 ```cddl
 ; CIP-00XX On-chain Surveys (Version 1.0)

From 04ef1cc57eb08560c143c2a4832218a726903672 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Thu, 6 Nov 2025 11:20:54 +0100
Subject: [PATCH 11/17] Update README.md

Removed revision history section and moved summary of design evolution into Rationale
---
 CIP-????/README.md | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index 517d6a05cc..393391003d 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -185,6 +185,12 @@ cip_00XX_root = {
 - **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
@@ -201,10 +207,3 @@ cip_00XX_root = {
 ## Copyright
 
 This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).
-
-## Revision History
-
-| Version | Date | Description |
-|----------|------|-------------|
-| 1.0 | 2025-10-28 | Initial version using Info Actions |
-| 1.1 | 2025-11-05 | Reworked as standalone metadata standard |

From e07b0a979ba1af1163ad04301894abcbb66287c5 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Thu, 6 Nov 2025 11:42:16 +0100
Subject: [PATCH 12/17] Update CIP-????/README.md

Co-authored-by: Robert Phair <rphair@cosd.com>
---
 CIP-????/README.md | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index 393391003d..e411cbcb08 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -187,9 +187,7 @@ cip_00XX_root = {
 
 ### 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.
+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
 

From 339e1e605ddf775d0267674c8a7ba83b5d4e7665 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Sat, 8 Nov 2025 13:42:02 +0100
Subject: [PATCH 13/17] Update CIP-????/README.md

Co-authored-by: Robert Phair <rphair@cosd.com>
---
 CIP-????/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index e411cbcb08..2b8605a98f 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -1,6 +1,6 @@
 ---
 CIP: XXXX
-Title: A Standard for On-Chain Surveys and Polls
+Title: On-Chain Surveys and Polls
 Category: Metadata
 Status: Proposed
 Authors:

From 449e320082f78f1007910b3f997c9fb2804fbae5 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Thu, 27 Nov 2025 16:57:42 +0100
Subject: [PATCH 14/17] Update survey CIP to use metadata label 0017 and clean
 up abstract
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Update the survey CIP to use metadata label 0017 and revise the abstract accordingly. All references to metadata label 674 have been replaced with 0017 throughout the specification, including in surveyDetails, surveyResponse, examples, and explorer guidance. Incorrect references to CIP-0068 “via 674” and any implied dependency on CIP-20 have been removed. The abstract has been updated to clarify that surveys use a dedicated metadata label, and a rationale has been added explaining the choice of 0017, referencing the Roman census of 17 BC as an early example of structured population data collection. No other structural or semantic changes have been made. Using a dedicated metadata label avoids congestion in CIP-20’s reserved space and provides a clear, unambiguous channel for survey metadata.
---
 CIP-????/README.md | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index 2b8605a98f..ad8eac4ab8 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -14,7 +14,9 @@ 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.  
+This proposal defines a generic, standardized transaction metadata structure for creating and responding to on-chain surveys and polls.
+
+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.  
 
 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.  
 
@@ -40,7 +42,7 @@ This separation of concerns provides:
 
 ## Specification
 
-This specification uses **CIP-0068** label **674** and defines two payload types:  
+This specification uses metadata label 0017 and defines two payload types:
 `surveyDetails` (definition) and `surveyResponse` (vote).
 
 ### Survey Definition Payload
@@ -50,7 +52,7 @@ It can be completely independent or optionally reference an existing governance
 
 ```json
 {
-  "674": {
+  "0017": {
     "msg": ["<Short, human-readable title of the survey>"],
     "surveyDetails": {
       "specVersion": "1.0",
@@ -94,7 +96,7 @@ This metadata is included in the transaction a user submits to cast a response.
 
 ```json
 {
-  "674": {
+  "0017": {
     "msg": ["Response to survey: <Title of the survey>"],
     "surveyResponse": {
       "surveyTxId": "<Transaction ID of the survey definition>",
@@ -121,7 +123,7 @@ This metadata is included in the transaction a user submits to cast a response.
 ### Block Explorer & dApp Implementation Guide
 
 1. **Survey Discovery:**  
-   Scan for transactions with label **674** containing `surveyDetails`.  
+   Scan for transactions with label **0017** containing `surveyDetails`.  
    Each survey is uniquely identified by the transaction ID of that transaction.
 
 2. **Response Linking:**  

From 5d19db4ded6638d51eae739b2d2fb3a661f70e3a Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Wed, 10 Dec 2025 00:35:33 +0100
Subject: [PATCH 15/17] Update CIP-????/README.md

Co-authored-by: Robert Phair <rphair@cosd.com>
---
 CIP-????/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index ad8eac4ab8..28cf5eb979 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -16,7 +16,7 @@ License: CC-BY-4.0
 
 This proposal defines a generic, standardized transaction metadata structure for creating and responding to on-chain surveys and polls.
 
-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.  
 
 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.  
 

From 49d67939e85d92e4ef0432f842296a5a42eb5c17 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Wed, 10 Dec 2025 00:35:59 +0100
Subject: [PATCH 16/17] Update CIP-????/README.md

Co-authored-by: Robert Phair <rphair@cosd.com>
---
 CIP-????/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index 28cf5eb979..0498d7ec11 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -42,7 +42,7 @@ This separation of concerns provides:
 
 ## Specification
 
-This specification uses metadata label 0017 and defines two payload types:
+This specification uses metadata label `17` and defines two payload types:
 `surveyDetails` (definition) and `surveyResponse` (vote).
 
 ### Survey Definition Payload

From 53e27f188928d3983861da8cc4fdb9434d87ce50 Mon Sep 17 00:00:00 2001
From: Thomas <thomas@kryptolabs.no>
Date: Wed, 10 Dec 2025 00:38:25 +0100
Subject: [PATCH 17/17] Update README.md

Changed metadatatag from 0017 to 17
---
 CIP-????/README.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/CIP-????/README.md b/CIP-????/README.md
index 0498d7ec11..f63aeb720c 100644
--- a/CIP-????/README.md
+++ b/CIP-????/README.md
@@ -52,7 +52,7 @@ It can be completely independent or optionally reference an existing governance
 
 ```json
 {
-  "0017": {
+  "17": {
     "msg": ["<Short, human-readable title of the survey>"],
     "surveyDetails": {
       "specVersion": "1.0",
@@ -96,7 +96,7 @@ This metadata is included in the transaction a user submits to cast a response.
 
 ```json
 {
-  "0017": {
+  "17": {
     "msg": ["Response to survey: <Title of the survey>"],
     "surveyResponse": {
       "surveyTxId": "<Transaction ID of the survey definition>",
@@ -123,7 +123,7 @@ This metadata is included in the transaction a user submits to cast a response.
 ### Block Explorer & dApp Implementation Guide
 
 1. **Survey Discovery:**  
-   Scan for transactions with label **0017** containing `surveyDetails`.  
+   Scan for transactions with label **17** containing `surveyDetails`.  
    Each survey is uniquely identified by the transaction ID of that transaction.
 
 2. **Response Linking:**